Jenis Pembangunan: Dari Lokal ke 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. Kemudian seseorang berkata, “Buatlah pembangunan tahap pengujian untuk klien sebelum akhir hari.” Jika Anda seorang pengembang perangkat seluler menengah, permintaan tersebut seringkali terasa sangat kabur. Konfigurasi mana? Identitas tanda tangan mana? Backend mana? Jalur distribusi mana?

That kebingungan 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.

A 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 rendah.

Jika setup lokal Anda masih terasa tidak stabil sebelum hal-hal tersebut dimulai, pastikan Anda mengaturnya terlebih dahulu dengan setup lingkungan lokal yang tepat. CapacitorKemudahan berpikir tentang kompleksitas build menjadi lebih mudah ketika alat dasar Anda dapat diprediksi.

Tabel Konten

• Mengurai Dunia Build Perangkat Lunak
• Spektrum Build Lokal vs Build CI
  • Build Lokal
  • Build CI
• Rasa Build Utama Debug vs Release
  • Build debug
  • Rilis build
  • Mengapa tim masih melakukan kesalahan ini
• Peta Build ke Lingkungan Distribusi
  • Malam hari dan burung hantu
  • Staging dan beta
  • Build distribusi pribadi
  • Produksi
  • Jenis Build Perangkat Lunak dan Karakteristiknya
• Peran Kritis Code Signing
  • Apa yang dibuktikan oleh tanda tangan
  • Bagaimana tanda tangan berubah oleh tujuan
• Mengatur Rilis dengan CI/CD dan Saluran Perbarui
  • Pipeliner Anda adalah kontrak pembangunan
  • Saluran menambahkan kontrol setelah biner dikirim
• Praktik Terbaik untuk Arus Kerja Pembangunan Modern

Mengurai 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 “artefak QA yang dapat di-debug dengan pembayaran yang dimock.” Di yang ketiga, mungkin berarti “pembangunan yang ditandatangani produksi yang didistribusikan secara pribadi.”

Itulah mengapa tim menjadi terjebak. Label hanya berguna jika Anda memahami pekerjaan yang dilakukan oleh pembangunan tersebut.

Cara berguna untuk berpikir tentang jenis-jenis pembangunan adalah ini:

• Pembangunan lokal membantu seorang pengembang individu bergerak cepat.
• Pembangunan CI membuat sumber kebenaran bersama untuk tim.
• Rasa dan rasa produksi Bentukkan bagaimana aplikasi dikompilasi dan diinstrumentasi.
• Pembangunan distribusi Bentukkan siapa yang menerima aplikasi dan bagaimana.
• Pembangunan yang ditandatangani Tentukan apakah platform akan percaya pada artefak.
• Pembaruan berdasarkan saluran Tentukan bagaimana perubahan bergerak setelah instalasi.

Itu bukan kategori yang bersaing. Mereka menumpuk.

Sebuah “pembangunan tahap pengujian” jarang sekali merupakan satu hal. Biasanya merupakan kombinasi dari rasa, lingkungan, penandatangan, dan pilihan distribusi.

Itu mengapa dua tim dapat berbicara “kami membutuhkan pembangunan beta” dan berarti artefak yang berbeda.

Hal ini paling penting pada mobile karena setiap langkah menambahkan gesekan. Kompilasi asli, rahasia, pengaturan, aplikasi toko, akses tester, pengaturan lingkungan, dan rollback semua harus berbaris. Jika salah satu bagian longgar, proses rilis menjadi pengetahuan suku bangsa. Kemudian seorang insinyur pergi berlibur dan tidak ada yang dapat mengirimkan dengan jelas.

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 Lokal vs Bangunan CI

Bangunan lokal adalah versi yang dibuat untuk diri sendiri. Bangunan CI adalah versi yang tim dapat percayai.

Itu terdengar jelas, tapi banyak rasa sakit bangunan dimulai ketika tim mengaburkan dua hal tersebut. Seseorang membuktikan “itu berfungsi pada mesin saya,” lalu cabang gagal di CI karena lingkungan lokal secara implisit bergantung pada dependensi yang disimpan di cache, file yang diedit secara manual, atau aset tanda tangan yang tidak pernah masuk ke otomatisasi.

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 memilih kecepatan atas upacara. Mereka sering kali termasuk pengecekan yang lebih longgar, log yang lebih rinci, 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 sukses mengompilasi pada satu laptop.

Bangunan CI

Bangunan CI lebih lambat karena alasan tertentu. Mereka menghilangkan keadaan mesin pribadi dari persamaan dan membuat proses bangunan berulang.

Ketika CI sehat, itu melakukan tiga hal dengan baik:

• Membangun 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 bangunan kembali ke komit, cabang, dan jalur pipa.

Alasan itu saya menyukai analogi workshop-versus-factory. Laptop Anda adalah meja kerja di mana Anda beriterasi. CI adalah jalur produksi yang membuktikan proses nyata.

Jika tim Anda masih secara manual memutuskan skrip mana yang dijalankan di mana, sentralisasi logika itu dalam otomatisasi. Referensi yang praktis adalah panduan ini tentang mengelola bangunan dev dan prod dengan GitHub Actions.

Aturan praktis: If QA, product, atau dukungan membutuhkan artefak, maka harus berasal dari CI, bukan dari mesin pengembang.

Setelah Anda menerima hal itu, maka siklus bangun lainnya menjadi lebih mudah. Pemilihan rasa, tanda tangan, penginjilan lingkungan, dan distribusi semua termasuk dalam pipa yang dapat diperiksa oleh siapa saja di tim.

Flavor Bangun Utama Debug vs Release

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

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

Bangun Debug

Bangun debug bertujuan untuk membantu manusia memeriksa perilaku. Biasanya, bangun 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 preskriptif, kinerja, milik sendiri, dan standar referensi jenis, dan sebuah konstruksi debug maps dengan rapi ke sebuah preskriptif pendekatan karena menentukan alat-alat dan metode yang tepat untuk analisis, sementara sebuah konstruksi rilis maps ke sebuah kinerja pendekatan yang fokus pada hasil yang diperlukan, sebagaimana diuraikan dalam pembongkaran ini dari jenis spesifikasi konstruksi.

Dalam prakteknya, sebuah konstruksi debug adalah di mana Anda ingin hal-hal seperti:

• Diagnostics yang dapat dibaca: lacak stack, keluaran 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 fraksi 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 luar. 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 diambil 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 kesalahan ini

Sumber besar kebingungan adalah mencampur “lingkungan” dengan “rasa.”

Sebuah build dapat bekerja pada flavor rilis yang mengarah ke layanan staging. Hal ini umum digunakan untuk QA karena Anda ingin perilaku produksi dengan data non-produksi. Sebuah build juga dapat flavor debug yang mengarah ke layanan pengembangan untuk kegiatan coding sehari-hari. Mereka adalah bidang yang berbeda.

Banyaknya penyebaran skrip berasal dari tim yang mengkode setiap kombinasi yang mungkin dalam nama paket alih-alih mendokumentasikan matrix.

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

Hal itu satu aturan yang menghilangkan banyak kompleksitas yang tidak sengaja.

Peta Build ke Lingkungan Distribusi

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

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

Alur kerja build yang praktis biasanya melalui beberapa lingkungan, masing-masing dengan audiens yang berbeda dan toleransi risiko yang berbeda. Jika Anda bekerja pada aplikasi Capacitor, juga membantu untuk menjaga pemisahan mental yang bersih antara pengembangan dan perilaku aplikasi produksi di CapacitorKarena banyak

masalah build

sebenarnya adalah kesalahan peta lingkungan.

Nightly dan Canary

Build malam dan burung hantu

• Build malam ini biasanya dibuat secara terjadwal atau dari kondisi cabang utama terbaru. Build burung hantu sengaja dipamerkan kepada audiens yang terbatas sebelum peluncuran yang lebih luas. Saya menganggapnya sebagai alat belajar, bukan sebagai janji kestabilan.
• Mereka berguna ketika Anda perlu menjawab pertanyaan seperti:
• Apakah cabang terintegrasi dengan bersih di antara modul?

Apakah pembaruan dependensi native memecahkan keluarga perangkat tertentu?

Apakah tester internal dapat mengidentifikasi regresi sebelum pengungkapan beta yang lebih luas?

Apa yang tidak berfungsi adalah memberikan build burung hantu kepada orang-orang yang mengharapkan perangkat lunak yang terpolish. Anda akan mendapatkan feedback yang berisik, dan audiens yang salah akan menganggap perubahan normal sebagai masalah peluncuran.

Staging dan beta

The audiens berpindah di sini:

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

Kesalahan di sini adalah menganggap beta sebagai “debug build lainnya.” Jika tester Anda mengevaluasi alur pengguna nyata, mereka membutuhkan kondisi rilis seperti biasanya.

Rilis distribusi pribadi

Beberapa aplikasi membutuhkan rilis yang tidak pernah mencapai audiens toko publik sama sekali, atau perlu mencapai kelompok yang lebih sempit terlebih dahulu.

Termasuk rilis klien spesifik, aplikasi internal karyawan, alur kerja yang diatur, alat operasional lapangan, dan distribusi enterprise-only. Mereka seringkali memerlukan kontrol yang lebih ketat atas siapa yang dapat menginstal aplikasi dan backend mana yang diakses.

Ini juga di mana nama menjadi berbahaya. Tim seringkali mengatakan “rilis enterprise” ketika mereka sebenarnya berarti salah satu hal yang berbeda:

• rilis aplikasi internal yang ditandatangani secara pribadi
• rilis aplikasi yang didistribusikan di toko dengan kontrol akses internal saja
• suatu artefak khusus pelanggan
• kandidat rilis pra-produksi untuk tinjauan stakeholder

Itu 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.

Pada titik ini, rilis harus membosankan. Itu adalah pujian.

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

Berikut adalah versi ringkasan.

Jenis Rilis Perangkat Lunak dan Karakteristiknya

Jenis build yang tepat adalah yang sesuai dengan toleransi risiko audiens. Kesalahan rilis paling sering terjadi ketika tim melewatkan alihan itu.

Peran Kritis Code Signing

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

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

Apa yang sebenarnya dibuktikan oleh signing

Untuk tim mobile, code signing melakukan tiga pekerjaan.

• Autentikasi: mengikat aplikasi ke pengembang atau organisasi yang menghasilkannya.
• Integritas: It membantu membuktikan bahwa artefak tersebut belum dimanipulasi sejak ditandatangani.
• Autorisasi: Pada platform Apple terutama, itu juga mengontrol di mana dan bagaimana aplikasi diizinkan untuk berjalan.

Titik ketiga itu yang membingungkan banyak pengembang. Tanda tangan bukan hanya identitas. Itu juga izin.

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

Bagaimana tanda tangan berubah tergantung pada tujuan

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

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

Itulah mengapa

adalah permintaan yang jarang kecil. Saat tanda tangan berubah, tujuan yang diizinkan untuk artefak juga dapat berubah.

• Konfigurasi yang disiplin biasanya mencakup: Not pada laptop pribadi.
• Pemisahan jelas oleh target: Pengembangan, pengujian pribadi, bisnis, rilis toko.
• Pengaturan rotasi dan kontrol akses: Terutama ketika kontraktor atau tim produk berbagi infrastruktur.
• Auditabilitas: 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 keamanan akhir-ke-akhir untuk __CAPGO_KEEP_1__ tanda tangan pembaruan. 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 alur bangun yang menyembunyikan identitas mana yang digunakan.

Tangani bahan tanda tangan seperti infrastruktur produksi, karena itu apa yang dia adalah.

Pengaturan rotasi dan kontrol akses: khususnya ketika kontraktor atau tim produk berbagi infrastruktur.

Mengatur Rilis dengan CI/CD dan Saluran Perbarui

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

Koordinasi tersebut harus ada di CI/CD.

Aliran pipa Anda adalah kontrak bangun

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

• apa tujuan bangun ini
• apa rasa yang digunakan
• nilai-nilai lingkungan apa yang diterima
• tes apa yang harus dilalui
• identitas tanda tangan apa yang berlaku
• di mana hasil artefak 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 petunjuk spesifikasi teknis ini. Disiplin yang sama membuat CI/CD lebih mudah dipahami karena pipeline tidak lagi menjadi kantong skrip dan menjadi kebijakan peluncuran yang dapat dieksekusi.

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 direkod.

Yang berhasil:

• Intensi cabang: cabang utama, cabang rilis, dan tag memicu alur kerja yang berbeda.
• Pengidentifikasian 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 satu, di mana setiap orang melewati flag yang khusus dan berharap mereka sesuai dengan apa yang butik atau tester butuh.

Saluran menambahkan kontrol setelah binary berlayar

Pembangunan asli masih kasar. Setelah rilis masuk ke toko, mengubah konten web di dalam aplikasi Capacitor tidak selalu memerlukan binary yang baru sepenuhnya.

Itu di mana saluran pembaruan menjadi berguna. Mereka memungkinkan tim untuk mengarahkan pembaruan aset web ke bagian pengguna di dalam binary produksi yang terpasang. Untuk tim Capacitor , salah satu pilihan adalah Capgo, yang 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:

• Pembangunan binary di CI/CD: membuat, menandatangani, dan mendistribusikan aplikasi native.
• Pengaturan saluran: mengarahkan pengguna atau lingkungan ke aliran beta, pengembangan, produksi, atau aliran khusus pelanggan.
• Rollout selektif: Kirim perubahan web ke satu kelompok sebelum paparan yang lebih luas.
• Jalan kembali: Nonaktifkan atau kembalikan pembaruan yang buruk tanpa menunggu tinjauan toko.

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

Demo singkat membantu jika Anda belum melihat saluran dalam aksi:

Ini adalah perubahan strategis yang banyak tim mobile butuhkan. 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 improvisasi perilaku rilis.

Konfigurasi yang kuat yang saya kerjakan bersama memiliki beberapa kebiasaan:

• Terpisahkan antara sumbu dengan jelas: rasa, lingkungan, target tanda tangan, dan target distribusi tidak boleh dicampur menjadi satu label yang kabur.
• Biarkan CI menghasilkan artefak yang berhadapan tim: bangun lokal adalah untuk pengembangan, bukan untuk kepercayaan pihak yang berkepentingan.
• Uji dalam kondisi rilis seperti awal: QA dan tester beta harus melihat perilaku yang sesuai dengan aplikasi asli sejauh mungkin.
• Tahan aset tanda tangan di luar laptop: rahasia milik infrastruktur yang dikendalikan dengan akses yang sempit.
• Berikan nama artefak sehingga manusia dapat membacanya: jika seseorang tidak dapat mengidentifikasi apa itu file untuk dalam beberapa detik, penamaan itu buruk.
• Lebih baik promosi daripada rekreasi: sekali artefak telah diverifikasi, pindahkan ke depan melalui alur kerja daripada membangun manual kembali.
• Design rollback sebelum peluncuran: rollback toko adalah lambat dan berat secara operasional. Rollback layer web untuk Capacitor dapat lebih cepat, tetapi hanya jika Anda merencanakan saluran dan kebijakan terlebih dahulu.

Perubahan pikiran terbesar adalah ini: jangan bertanya “skrip build mana yang harus saya jalankan?” Tanyakan “apa risiko yang saya kelola pada tahap ini?” Pertanyaan itu menghasilkan sistem build yang lebih baik.

Jika alur kerja Anda menjawabnya dengan jelas, proses rilis Anda menjadi lebih mudah dioperasikan, lebih mudah diverifikasi, dan jauh lebih tidak bergantung pada satu insinyur senior yang mengingat incantasi yang tepat.

Jika tim Anda mengirimkan aplikasi Capacitor dan ingin memiliki kontrol yang lebih ketat atas alur kerja rilis, Capgo adalah layak untuk dievaluasi sebagai bagian dari stack tersebut. Ini menghandle pembaruan langsung yang sasaran untuk asset web di dalam aplikasi Capacitor , mendukung bundle yang ditandatangani, peluncuran saluran, dan kontrol rollback, yang membuatnya berguna ketika Anda membutuhkan perbaikan yang lebih cepat tanpa mengganti pipeline build asli.