Jenis-Jenis Build: Dari Lokal Sampai Produksi

Anda membuka proyek dan melihat build:ios:dev, build:android:qa, build:staging, build:release, build:prod, plus beberapa skrip shell yang tidak ingin disentuh. Lalu seseorang berkata, “Buatlah build staging untuk klien sebelum akhir hari.” Jika Anda seorang pengembang mobile menengah, permintaan tersebut seringkali terasa sangat kabur. Konfigurasi mana? Identitas signing mana? Backend mana? Jalur distribusi mana?

Ketidakpastian biasanya berasal dari menganggap jenis build sebagai daftar yang rata. Mereka tidak. Mereka adalah alur kerja. Setiap build ada untuk menyelesaikan masalah tertentu pada titik tertentu antara laptop Anda dan perangkat pengguna.

Build bukan hanya aplikasi yang dikompilasi. Ini adalah versi aplikasi Anda yang disusun untuk tujuan, audiens, dan lingkungan tertentu. Beberapa build ada untuk membantu Anda debug. Beberapa ada untuk membantu QA memecahkan hal-hal dengan aman. Beberapa ada agar tim rilis dapat menghasilkan artefak yang dapat dipercaya. Beberapa ada agar tim produk dapat mengirimkan perubahan dengan risiko yang lebih kecil.

Jika setup lokal Anda masih terasa tidak stabil sebelum hal-hal tersebut dimulai, pastikan Anda mengaturnya terlebih dahulu dengan setup lingkungan lokal yang tepat Capacitor setup lingkungan lokal yang tepatDaftar Isi

Menemukan Dunia Build Perangkat Lunak

• Spektrum Build Lokal vs Build CI
• Build Lokal
  • Build CI
  • Rasa Build Utama Debug vs Release
• Build Debug
  • Build Debug
  • Rilis build
  • Mengapa tim masih melakukan ini salah
• Peta Build ke Lingkungan Distribusi
  • Nightly dan Canary
  • Staging dan Beta
  • Build distribusi pribadi
  • Produksi
  • Jenis Build Perangkat Lunak dan Karakteristiknya
• Peran Kritis dari Code Signing
  • Apa yang dibuktikan oleh tanda tangan
  • Bagaimana tanda tangan berubah tergantung pada tujuan
• Mengatur Rilis dengan CI/CD dan Saluran Perbarui
  • Alur kerja pipa Anda adalah kontrak pembangunan
  • Saluran menambahkan kontrol setelah biner dikirim
• Praktik Terbaik untuk Alur Kerja Pembangunan Modern

Menyingkap Dunia Pembangunan Perangkat Lunak

Kesalahan paling umum yang saya lihat adalah asumsi nama pembangunan memberitahu seluruh cerita. Mereka tidak. staging Mungkin berarti “rasa rilis yang ditujukan ke API produksi.” Di repositori lain, mungkin berarti “artifact QA yang dapat diperiksa dengan pembayaran yang dimock.” Di yang ketiga, mungkin berarti “pembangunan yang ditandatangani produksi yang didistribusikan secara pribadi.”

Oleh karena itu, tim menjadi terjebak. Label hanya berguna jika Anda memahami pekerjaan yang dilakukan oleh pembangunan tersebut.

Cara berguna untuk berpikir tentang jenis-jenis pembangunan adalah sebagai berikut:

• Pembangunan lokal membantu seorang pengembang individu bergerak cepat.
• Pembangunan CI membuat sumber kebenaran bersama untuk tim.
• Flavor debug dan rilis Mengatur bagaimana aplikasi dikompilasi dan diinstrumentasi.
• Build distribusi Mengatur siapa yang menerima aplikasi dan bagaimana.
• Build yang ditandatangani Mengatur apakah platform akan mempercayai artefak.
• Pembaruan berdasarkan saluran Mengatur bagaimana perubahan bergerak setelah instalasi.

Kategori-kategori tersebut tidak bersaing. Mereka bertumpuk.

Build 'staging' jarang merupakan satu hal. Biasanya merupakan kombinasi dari rasa, lingkungan, tanda tangan, dan pilihan distribusi.

Oleh karena itu, dua tim dapat berbicara 'kami membutuhkan build beta' dan berarti artefak yang berbeda.

Hal ini paling penting pada perangkat mobile karena setiap langkah menambahkan gesekan. Pengompilan asli, rahasia, pengaturan, track aplikasi toko, akses tester, pengaturan lingkungan, dan rollback semua harus berbaris. Jika salah satu bagian longgar, proses rilis menjadi pengetahuan suku.

Tim yang mengelola ini dengan baik tidak mengingat lebih banyak skrip. Mereka mendefinisikan jenis bangunan sebagai pintu kualitas. Setiap pintu menurunkan jenis risiko yang berbeda: bangunan yang rusak code, konfigurasi yang salah, tanda tangan yang buruk, peluncuran yang buruk, atau pemulihan yang buruk.

Spektrum Bangunan vs Bangunan CI

Bangunan Lokal

Bangunan CI

Bangunan Lokal

Bangunan lokal adalah pribadi, cepat, dan dapat dibuang. Anda menggunakan mereka untuk menjawab pertanyaan segera.

Apakah layar dapat menampilkan? Apakah plugin native dapat diinisialisasi? Apakah perubahan Gradle atau Xcode menghancurkan kompilasi? Apakah Anda dapat mereproduksi crash dengan logging yang ditingkatkan?

Bangunan lokal yang baik lebih memilih kecepatan daripada upacara. Mereka sering kali termasuk pengecekan yang lebih longgar, log yang lebih berbicara, pengaturan pengembang, dan instrumen sementara. Itu tidak apa-apa. Tugasnya adalah memberikan feedback yang cepat.

Yang tidak berfungsi adalah mempromosikan bangunan lokal menjadi sesuatu yang lebih penting daripada itu. Bangunan lokal tidak boleh menjadi artefak rilis karena telah terkompilasi dengan sukses di satu laptop.

Bangunan CI

Build CI lebih lambat karena alasan tertentu. Mereka menghilangkan keadaan mesin pribadi dari persamaan dan membuat proses build dapat diulang kembali.

Mengapa CI sehat sangat penting:

• Membangun ulang dari awal: Membuktikan proyek dapat dikompilasi tanpa asumsi lokal yang disembunyikan.
• Menggunakan periksa tim: Unit test, pemeriksaan lint, dan aturan pengemasan terjadi di tempat yang sama setiap kali.
• Menghasilkan artefak yang dapat dilihat: Tim dapat menghubungkan build ke komit, cabang, dan jalur pipeline.

Alasan mengapa saya menyukai analogi workshop versus pabrik. Laptop Anda adalah meja kerja tempat Anda melakukan iterasi. CI adalah jalur produksi yang membuktikan proses nyata.

Jika tim Anda masih secara manual menentukan skrip mana yang dijalankan di mana, sentralisasi logika tersebut dalam otomatisasi. Referensi yang berguna adalah panduan ini tentang mengelola build dev dan prod dengan __CAPGO_KEEP_0__ Actions managing dev and prod builds with GitHub Actions.

protectedTokens Jika QA, produk, atau dukungan membutuhkan artefak, maka harus berasal dari CI, bukan dari mesin pengembang.

Setelah Anda menerima itu, maka sisa siklus pembangunan menjadi lebih mudah. Pemilihan rasa, penandatangan, penginjeksian lingkungan, dan distribusi semua termasuk dalam pipa yang dapat diperiksa oleh siapa saja di tim.

Flavor Pembangunan Utama Debug vs Release

Banyak label yang digunakan untuk pembangunan, tetapi di bawah semua nama itu, dua rasa biasanya yang paling penting: debug dan release.

Mereka ada karena pengembang dan pengguna akhir membutuhkan hal yang berlawanan.

Pembangunan Debug

Pembangunan debug bertujuan untuk membantu manusia memeriksa perilaku. Biasanya, pembangunan debug menyimpan lebih banyak metadata, membuat troubleshooting lebih mudah, dan menghindari optimasi yang agresif yang dapat menyembunyikan masalah.

Ada analogi yang berguna dari spesifikasi konstruksi. Spesifikasi biasanya jatuh ke dalam Jenis-Jenis Konstruksi, performa, milik sendiri, dan standar referensi Jenis, dan sebuah konstruksi debug dapat diatur dengan baik ke sebuah preskriptif pendekatan karena menentukan alat-alat dan metode yang tepat untuk analisis, sementara sebuah konstruksi rilis dapat diarahkan ke sebuah performa pendekatan yang berfokus pada hasil yang diperlukan, seperti yang dijelaskan dalam pembagian spesifikasi konstruksi ini.

Jenis konstruksi debug adalah di mana Anda ingin hal-hal seperti:

• Diagnostik yang dapat dibaca: lacak stack, output konsol, dan simbol yang membantu Anda menemukan kesalahan.
• Kemudahan pengembang: toggle palsu, menu uji, dan switch fitur yang tidak pantas untuk pengguna akhir.
• Iterasi dengan kecepatan rendah: siklus instalasi dan menjalankan yang lebih cepat lebih penting daripada paket yang terpolish.

Build debug bukanlah “buruk.” Mereka dibuat dengan tujuan tertentu.

Build rilis

Build rilis dibuat untuk perangkat di lapangan. Hal ini mengubah prioritas segera.

Sekarang Anda peduli dengan integritas paket, perilaku startup, postur keamanan yang lebih ketat, payload yang lebih kecil, dan karakteristik waktu eksekusi yang dapat diprediksi. Anda juga ingin memiliki lebih sedikit titik masuk tidak sengaja untuk pemeriksaan atau penyalahgunaan.

Perubahan yang disederhanakan adalah sederhana. Semua yang membuat build debug lebih mudah untuk diperiksa cenderung membuat build rilis kurang pantas untuk produksi.

Batasan keputusan yang saya gunakan dengan tim:

Mengapa tim masih melakukan ini salah

Sumber utama kebingungan adalah mencampur "lingkungan" dengan "rasa."

Sebuah build dapat flavor rilis yang berorientasi pada layanan produksiNamun, itu adalah hal yang umum untuk QA karena Anda ingin perilaku produksi dengan data non-produksi. Sebuah build juga dapat untuk kegiatan coding sehari-hari. Itu adalah dua aspek yang berbeda.

Apa yang menyebabkan banyak script berantakan adalah tim yang mengkodekan kombinasi yang mungkin dalam nama paket alih-alih mendokumentasikan matrix.

Kirimkan flavor rilis ketika non-pengembang melakukan pengujian perilaku user-facing. Simpan flavor debug untuk pekerjaan engineering dan troubleshooting sengaja.

Aturan itu dapat menghilangkan banyak kompleksitas yang tidak sengaja.

Peta Build ke Lingkungan Distribusi

Banyak diskusi tentang jenis-jenis build berhenti terlalu awal. Mereka menjelaskan lokal, debug, dan rilis, lalu mengabaikan pertanyaan yang lebih sulit: di mana build ini akan pergi?

Tujuan itu berubah apa yang harus ada di build, bagaimana build harus ditandatangani, dan siapa yang akan menerima build tersebut.

Sebuah workflow build yang praktis biasanya bergerak melalui beberapa lingkungan, masing-masing dengan audiens yang berbeda dan toleransi risiko yang berbeda. Jika Anda bekerja pada aplikasi Capacitor, itu juga membantu untuk menjaga pemisahan mental yang jelas antara perilaku aplikasi pengembangan dan produksi di Capacitor development and production app behavior in CapacitorKarena banyak

masalah build

sebenarnya adalah kesalahan dalam pemetaan lingkungan.

Nightly dan canary

Build ini adalah peringatan dini. Mereka ,

• untuk insinyur, QA, atau kelompok internal kecil yang siap menerima sisi kasar.
• Build nightly biasanya dibuat secara terjadwal atau dari keadaan cabang utama terbaru. Build canary sengaja diberikan kepada audiens yang terbatas sebelum peluncuran yang lebih luas. Saya ,
• menggunakannya sebagai alat belajar, bukan sebagai janji kestabilan.

Mereka berguna ketika Anda perlu menjawab pertanyaan seperti:

Apakah cabang terintegrasi dengan baik di antara modul?

Apakah pembaruan dependensi native ,

menghancurkan keluarga perangkat tertentu?

Penonton berpindah di sini:

• Tim QA memvalidasi regresi, alur kerja, dan kriteria penerimaan.
• Pengelola produk memeriksa perilaku di shell yang realistis.
• Pengujian eksternal memvalidasi kenyamanan pengguna, penutupan perangkat, dan kasus sampingan.
• Tim dukungan atau kesuksesan mungkin memperlihatkan perubahan yang akan datang.

Kesalahan di sini adalah menganggap beta sebagai “debug build lainnya.” Jika tester Anda menilai aliran pengguna yang nyata, mereka memerlukan kondisi rilis seperti itu.

Build distribusi pribadi

Beberapa aplikasi memerlukan build yang tidak pernah sampai ke audiens toko publik sama sekali, atau perlu mencapai kelompok yang lebih terbatas terlebih dahulu.

Termasuk build klien khusus, aplikasi karyawan internal, alur kerja yang diatur, alat operasional lapangan, dan distribusi hanya untuk perusahaan. Mereka sering memerlukan kontrol yang lebih ketat atas siapa yang dapat menginstal aplikasi dan mana backend yang diakses.

Ini juga di mana penamaan menjadi berbahaya. Tim sering mengatakan “build perusahaan” ketika mereka sebenarnya berarti salah satu hal yang berbeda:

• aplikasi internal yang ditandatangani secara pribadi
• aplikasi yang didistribusikan ke toko dengan kontrol akses internal saja
• Suatu artefak khusus pelanggan
• Kandidat rilis pra-produksi untuk tinjauan stakeholder

Mereka adalah model operasional yang berbeda. Jaga mereka terpisah dalam pipa dan penamaan Anda.

Produksi

Rilis produksi adalah komitmen publik. Mereka pergi ke App Store, Play Store, atau saluran yang disetujui yang setara untuk pengguna Anda.

Build ini seharusnya sudah membosankan. Itu sebuah pujian.

Anda ingin build produksi dapat direproduksi, ditandatangani dengan benar, diuji dalam kondisi rilis, dan terkait dengan rencana rollback. Anda tidak ingin revisi manual terakhir, hack spesifik mesin, atau 'kita akan memperbaikinya di build berikutnya' kompromi.

Versi ringkas ini.

Jenis Rilis Perangkat Lunak dan Karakteristiknya

Jenis build yang tepat adalah yang sesuai dengan toleransi risiko audiens. Kesalahan rilis paling banyak terjadi ketika tim melewatkan aliansi tersebut.

Peran Kritis Code Signing

File build sendiri tidak berarti banyak di mobile. Platform membutuhkan bukti bahwa itu berasal dari sumber yang dipercaya dan tidak ada yang mengubahnya setelah pembuatan. Bukti tersebut adalah code signing.

Jika Anda pernah memiliki build yang berhasil dikompilasi tetapi menolak untuk diinstal, diunggah, atau diluncurkan dengan benar, maka signing mungkin adalah masalahnya.

Apa yang dibuktikan oleh signing

Untuk tim mobile, code signing melakukan tiga hal.

• Autentikasi: mengikat aplikasi ke pengembang atau organisasi yang menghasilkannya.
• Integritas: membantu membuktikan bahwa artefak tersebut tidak telah dimanipulasi sejak ditandatangani.
• Otorisasi: terutama di platform Apple, hal ini juga mengontrol di mana dan bagaimana aplikasi diizinkan untuk berjalan.

Titik ketiga ini yang membingungkan banyak pengembang. Tanda tangan bukan hanya identitas. Tanda tangan juga adalah izin.

Jadi aplikasi yang sama code dapat memerlukan bahan tanda tangan yang berbeda tergantung apakah Anda ingin menjalankannya secara lokal di perangkat, mendistribusikannya kepada tes, mengirimkannya secara internal, atau mengirimkannya ke toko.

Bagaimana tanda tangan berubah tergantung tujuan

Ini adalah model mental yang menjaga proses tetap seimbang: tanda tangan mengikuti distribusi.

Pemasangan pengembang lokal menggunakan satu set identitas dan izin. Bangun beta yang dikirim melalui TestFlight menggunakan set lain. Jalur distribusi internal mungkin memerlukan profil yang berbeda lagi. Rilis publik ke toko memiliki harapan tanda tangan dan pengemasan yang dapat disetujui ulang.

Itulah mengapa 'hanya tandatangani bangun' jarang menjadi permintaan kecil. Saat tanda tangan berubah, tujuan yang diizinkan artefak dapat berubah bersamanya.

Konfigurasi yang disiplin biasanya mencakup:

• Simpan aset tanda tangan di CI: bukan di laptop pribadi.
• Penyebutan jelas berdasarkan target: pengembangan, pengujian pribadi, bisnis, rilis toko.
• Pengaturan rotasi dan kontrol akses: terutama ketika kontraktor atau tim produk yang berbeda berbagi infrastruktur.
• Keterbukaan audit: anda perlu tahu mana pipeline yang digunakan mana identitas tanda tangan.

Jika tim Anda mengirimkan pembaruan web di dalam aplikasi Capacitor, ada lapisan tanda tangan kedua yang perlu dipertimbangkan juga. Ringkasan ini tentang Capacitor updater __CAPGO_KEEP_1__ tanda tangan akhir-ke-akhirinya end-to-end security for Capacitor updater code signing Masalah tanda tangan biasanya tidak berasal dari kriptografi. Mereka berasal dari kepemilikan yang tidak jelas, penanganan manual, dan pipeline pembangunan yang menyembunyikan identitas mana yang diterapkan.

Tangani bahan tanda tangan seperti infrastruktur produksi, karena itu yang sebenarnya.

Perlu diingat bahwa masalah tanda tangan tidak biasanya berasal dari kriptografi. Mereka berasal dari kepemilikan yang tidak jelas, penanganan manual, dan pipeline pembangunan yang menyembunyikan identitas mana yang diterapkan.

Merayakan Rilis dengan CI/CD dan Saluran Perbarui

Ketika tim matang, tantangan bukanlah mengetahui jenis-jenis bangunan. Tantangan adalah mengkoordinasikannya tanpa perlu menebak secara manusiawi.

Koordinasi itu harus ada di CI/CD.

Aliran pipa Anda adalah kontrak bangunan

Aliran pipa yang dapat diandalkan harus menjawab pertanyaan-pertanyaan yang sama setiap kali:

• apa tujuan bangunan ini
• apa rasa yang digunakan
• nilai-nilai lingkungan apa yang diterima
• apa tes yang harus dilalui
• apa identitas tanda tangan yang berlaku
• di mana artefak itu dikirimkan

Struktur itu menggambarkan spesifikasi teknis yang baik. Spesifikasi yang terbentuk dengan baik harus mencakup tujuan dan ruang lingkup, persyaratan fungsional, persyaratan desain, standar teknis, persyaratan pengujian, persyaratan pengiriman, dan persyaratan dukungan atau perawatan, seperti yang dijelaskan dalam pedoman spesifikasi teknis ini. Disiplin yang sama membuat CI/CD lebih mudah dipahami karena pipeline tidak lagi menjadi kumpulan skrip dan menjadi kebijakan peluncuran yang dapat dieksekusi.

Ini berlaku dalam prakteknya, pipeline harus dapat memutuskan, bukan insinyur yang menjalankannya secara manual. Aturan cabang, tag, langkah persetujuan, konteks tanda tangan, dan target pengiriman harus semua direkodifikasi.

Yang berhasil:

• Intensi cabang yang dikendalikan: cabang utama, cabang rilis, dan tag memicu alur kerja yang berbeda.
• Pemberian nama artefak yang eksplisit: rasa, lingkungan, dan target dapat dilihat dalam hasil.
• Promosi bukanlah merekonstruksi secara manual: menggerakkan artefak yang telah diverifikasi maju daripada menciptakan mereka secara ad hoc.

Apa yang gagal secara konsisten adalah pendekatan skrip yang fleksibel di mana semua orang melewati flag yang disesuaikan dan berharap mereka sesuai dengan apa yang dibutuhkan oleh toko atau tester.

Saluran menambahkan kontrol setelah binary berlayar.

Build native masih kasar. Setelah rilis masuk ke toko, mengubah konten web di dalam aplikasi Capacitor tidak selalu memerlukan binary baru secara keseluruhan.

Itu di mana saluran pembaruan menjadi berguna. Mereka memungkinkan tim untuk mengarahkan pembaruan aset web ke subset pengguna di dalam binary produksi yang terpasang. Untuk tim Capacitor, salah satu pilihan adalah Capgoyang menerbitkan bundle web yang ditandatangani ke saluran yang ditargetkan sehingga Anda dapat mendorong perubahan JavaScript, CSS, salinan, konfigurasi, dan aset tanpa membangun shell native setiap kali.

Polanya yang praktis seperti ini:

• Build binary di CI/CD: membuat, menandatangani, dan mendistribusikan aplikasi native.
• Pengaturan saluran: mengatur pengguna atau lingkungan ke saluran beta, pengembangan, produksi, atau aliran khusus pelanggan.
• Rollout selektif: Kirim perubahan web ke satu kelompok sebelum penyebaran yang lebih luas.
• Jalur rollback: Mengaktifkan atau memulihkan pembaruan yang buruk tanpa menunggu tinjauan toko.

Jika Anda belum mengatur model tersebut, panduan ini pada membuat dan menghapus saluran pembaruan di Capacitor menjelaskan prinsipnya secara lebih konkrit.

Demo singkat membantu jika Anda belum melihat saluran dalam aksi:

Perubahan strategis yang dibutuhkan oleh banyak tim mobile. Tipe-tipe build bukan hanya artefak. Mereka adalah titik kontrol. CI/CD mengontrol bagaimana biner diproduksi. Saluran mengontrol bagaimana perubahan pasca-instal diungkapkan.

Praktik Terbaik untuk Arus Kerja Build Modern

Sistem build yang seimbang adalah opini. Dia tidak membiarkan setiap pengembang mengimprovisasi perilaku rilis.

Setelan yang paling kuat yang saya kerjakan bersama memiliki beberapa kebiasaan:

• Jelaskan sumbu secara jelas: Tidak ada label yang kabur, seperti rasa, lingkungan, target tanda tangan, dan target distribusi.
• Biarkan CI menghasilkan artefak yang berfokus pada tim: Pembangunan lokal adalah untuk pengembangan, bukan untuk kepercayaan pihak terkait.
• Uji dalam kondisi rilis seperti itu sejak awal: QA dan tes beta harus melihat perilaku yang sesuai dengan aplikasi asli sejauh mungkin.
• Jagalah aset tanda tangan tidak ada di laptop: Rahasia harus berada di infrastruktur yang dikendalikan dengan akses yang sempit.
• Berikan nama artefak sehingga manusia dapat membacanya: Jika seseorang tidak dapat mengidentifikasi apa itu file dalam beberapa detik, maka penamaan itu buruk.
• Lebih baik promosikan daripada mereproduksi: Saat artefak telah diverifikasi, pindahkan ke depan melalui alur kerja daripada membangun secara manual.
• Desain rollback sebelum peluncuran: Rollback toko adalah lambat dan berat operasional. Rollback layer web untuk pembaruan Capacitor dapat lebih cepat, tetapi hanya jika Anda merencanakan saluran dan kebijakan terlebih dahulu.

Pemikiran besar perubahan ini adalah ini: jangan bertanya "skrip pembangunan mana yang harus saya jalankan?" Tanyakan "apa risiko yang saya kelola pada tahap ini?" Pertanyaan itu menghasilkan sistem pembangunan yang lebih baik.

Jika alur kerja Anda menjawab hal itu dengan jelas, proses rilis Anda menjadi lebih mudah untuk dioperasikan, lebih mudah untuk diaudit, dan jauh lebih tidak bergantung pada satu insinyur senior yang mengingatkan incantasi yang tepat.

Jika tim Anda mengirimkan aplikasi Capacitor dan ingin memiliki kendali yang lebih ketat atas alur kerja rilis, Capgo bernilai untuk dievaluasi sebagai bagian dari stack tersebut. Ini menghandle pembaruan hidup yang sasaran untuk asset web di dalam aplikasi Capacitor , mendukung bundle yang ditandatangani, saluran berbasis rollout, dan kontrol rollback, yang membuatnya berguna ketika Anda membutuhkan perbaikan yang lebih cepat tanpa menggantikan pipa pembangunan asli.