Pengaturan Lingkungan untuk Aplikasi Modern

Kamu telah mengirimkan rilis, menandatangani biner native, dan melihat peluncuran produksi berjalan normal. Lalu, tim dukungan melaporkan bahwa pengguna tidak bisa menyelesaikan pembelian. Log crash terlihat tidak terkait, jadi kamu menghabiskan beberapa jam untuk menelusuri permintaan, inisialisasi plugin, dan perubahan JavaScript terbaru. Penyebabnya ternyata adalah URL staging API yang ditinggalkan dalam rilis produksi yang terburu-buru.

Kegagalan seperti itu tidaklah aneh. Konfigurasi Lingkungan adalah disiplin untuk menjaga pengaturan spesifik untuk pengiriman, seperti API endpoint, flag fitur, kredential database, dan kunci pihak ketiga, terpisah dari aplikasi code. Pada aplikasi Capacitor dan Electron, pemisahan menjadi lebih sulit karena aset web dibundel dalam kontainer native, sehingga kesalahan konfigurasi dapat menjadi bagian dari artefak yang ditandatangani daripada nilai yang dapat diubah di server.

Masalah yang lebih dalam adalah drift konfigurasiPerubahan yang berkelanjutan antara pengembangan, pengujian, dan produksi. Seorang pengembang melakukan pembaruan pada satu .env file, a release engineer changes a CI variable, and a mobile build preserves an older value inside its bundle. The app still compiles, but the environments no longer represent the same system. Teams that understand the perbedaan antara pengembangan dan produksi di aplikasi Capacitor Bisa menghindari beberapa kesalahan yang jelas, tetapi drift memerlukan model operasional, bukan hanya konvensi penamaan file yang lebih baik.

Masalah praktisnya sederhana: bagaimana Anda mengirimkan kodebasis yang sama ke berbagai lingkungan tanpa harus membangun, menandatangani ulang, atau mengirimkan aplikasi native untuk setiap perubahan konfigurasi?

Isi Kandungan

• Mengapa Konfigurasi Lingkungan Mengganggu Aplikasi Produksi
  • Drift dimulai dengan kesalahan kecil
  • Konfigurasi Waktu Pembangunan Membuat Botol Rilis
• Menggambarkan Empat Pola Konfigurasi Utama
  • Pola satu, variabel lingkungan 12-Faktor
  • Pola dua, pembangunan per-lingkungan
  • Pola tiga, konfigurasi waktu eksekusi
  • Pola empat, pengelolaan rahasia khusus
• Dampak Keamanan dan CI/CD yang Tidak Boleh Dilupakan
  • Dimana Pipa Pipa Konfigurasi Mengalir
  • Keamanan harus ada bersamaan dengan kecepatan rilis
• Mengimplementasikan Konfigurasi Lingkungan di Capacitor dan Electron
  • Definisi dan validasi satu kontrak
  • Konfigurasi Capacitor asli
  • Electron memerlukan batasan proses
• Mengurangi Pembaruan Target dan Rollback dengan Capgo
  • Saluran membuat kepemilikan konfigurasi lingkungan eksplisit
• Daftar Periksa Audit Konfigurasi Lingkungan Anda

Mengapa Konfigurasi Lingkungan Menghancurkan Aplikasi Produksi

Masalah konfigurasi paling mahal jarang terlihat seperti masalah konfigurasi. URL dasar API yang salah dapat muncul sebagai gagal autentikasi, layar akun kosong, kesalahan pembayaran, atau crash plugin native. Saat insiden mencapai insinyur yang bertanggung jawab atas pipeline pembangunan, kesalahan asli mungkin telah disembunyikan di bawah beberapa komit dan pengiriman toko yang sukses.

Aplikasi hybrid memiliki pola kegagalan tertentu. Capacitor mengompilasi aplikasi web dan menempatkan asetnya di dalam proyek iOS atau Android. Electron mengemas renderer dan proses utama code menjadi aplikasi desktop. Jika endpoint atau flag fitur diresolusi selama pembangunan, nilai yang dihasilkan akan berjalan bersama dengan artefak. Mengubahnya kemudian biasanya berarti menghasilkan bundle baru, menandatangani lagi, dan mendistribusikan melalui saluran yang relevan.

Drift dimulai dengan kecuali kecil

Drift konfigurasi tumbuh dari singkatkan logika yang masuk akal:

• A override lokal: Seorang pengembang mengkodekan endpoint uji secara manual untuk mengaktifkan fitur dan lupa menghapusnya.
• A variabel pipeline terpisah: CI menggunakan nilai produksi yang tidak sesuai dengan konfigurasi yang terdokumentasi di repository.
• A pengaturan native saja: Android, iOS, dan Electron menerima identifikasi plugin atau pengaturan panggilan yang berbeda.
• A flag yang tidak terdokumentasi: Tim operasional mengubah flag fitur secara langsung di sistem pengiriman, sementara staging terus menggunakan perilaku lama.

Setiap pilihan dapat berjalan sendiri. Masalah dimulai ketika tidak ada yang bisa menjawab nilai mana yang otoritatif, lingkungan mana yang menggunakannya, dan kapan terakhir kali berubah.

Aturan praktis: Jika nilai konfigurasi dapat berubah secara independen dari logika aplikasi, tatalah sebagai input pengiriman, bukan sebagai sumber code.

A lingkungan pengembangan harus menyerupai produksi dengan cukup dekat untuk mengungkapkan masalah integrasi, sementara masih menggunakan endpoint terisolasi, kredit, dan data. Ketika lingkungan berubah, pengujian tidak lagi berguna. Rilis dapat melewati setiap tes terhadap satu set asumsi dan gagal segera terhadap yang lain.

Konfigurasi waktu pembangunan menciptakan bottleneck rilis

Konfigurasi waktu pembangunan masih berguna. Nilai publik waktu kompilasi, identifier spesifik platform, dan pengaturan yang diperlukan oleh alat bawaan asli seringkali perlu ada sebelum aplikasi dikemas. Masalahnya adalah menggunakan injeksi waktu pembangunan untuk nilai-nilai yang operasi mungkin perlu ubah setelah rilis.

Anggaplah sebuah produksi API berpindah ke endpoint baru. Dengan alur kerja tradisional Capacitor, tim mengubah nilai, membangun aset web, menyinkronkan proyek native, menandatangani aplikasi, dan mendistribusikan melalui proses rilis platform. Tim Electron menghadapi siklus yang sama ketika nilai yang berubah berada di dalam aplikasi yang dikemas.

Alur kerja tersebut dapat diterima untuk rilis produk yang sengaja. Namun, itu adalah respons yang buruk terhadap perubahan konfigurasi darurat. Aplikasi mungkin sehat, JavaScript mungkin tidak berubah, dan namun sebuah string saja dapat memaksa siklus pengiriman lengkap.

Desain yang lebih aman memisahkan tiga lapisan:

1. Logika aplikasiyang harus tetap sama di semua lingkungan.
2. Konfigurasi lingkunganyang memilih endpoint, flag, dan perilaku waktu eksekusi yang tidak sensitif.
3. Bahan rahasiayang harus disimpan dengan kontrol dan hanya diinjeksikan ketika diperlukan.

Perbedaan tersebut membuat perubahan terlihat. Ini juga memberikan tim jawaban yang jelas ketika produksi berperilaku berbeda: bandingkan input konfigurasi sebelum menyalahkan code.

Menggambarkan Empat Pola Konfigurasi Utama

Tidak ada satu pola konfigurasi yang sesuai untuk setiap bagian aplikasi hybrid. Backend dapat membaca variabel lingkungan proses pada startup, sementara renderer Capacitor mungkin tidak memiliki proses server tradisional. Electron menambahkan batasan lain antara proses utama dan renderer. Pilihan yang tepat tergantung pada apakah nilai tersebut publik, sensitif, dapat berubah setelah rilis, atau diperlukan oleh alat pembangunan native.

Pola satu, variabel lingkungan 12-Faktor

Model 12-Faktor menganggap konfigurasi sebagai input spesifik lingkungan daripada nilai aplikasi yang dihardcode. Hal tersebut berlaku secara alami untuk proses server, kontainer, dan pekerjaan CI. Layanan dapat membaca nilai-nilainya pada startup dan menggunakan artefak yang sama dalam beberapa penggunaan.

Aplikasi klien memperumit model tersebut. Nilai yang dirujuk oleh JavaScript browser harus tersedia pada akhirnya ke klien, sehingga tidak boleh dianggap sebagai rahasia hanya karena tiba melalui variabel lingkungan. Asal API publik atau flag fitur dapat menggunakan penggantian waktu pembangunan, tetapi kredential dengan hak istimewa yang berarti tidak boleh dikirim ke dalam bundle klien yang dapat dibalik.

Untuk Capacitor dan Electron, pola ini paling baik untuk pengaturan konfigurasi publik dan pengaturan orkestrasi bangunJangan untuk melindungi rahasia. Ini memiliki konsep overhead yang rendah, tetapi mutabilitas waktu eksekusi terbatas kecuali lapisan pengiriman lainnya ada.

Polanya dua, pembangunan per lingkungan

Tim sering menjaga profil pembangunan, pengujian, dan produksi. Profil masing-masing memilih endpoint, identifier aplikasi, file layanan native, dan flag fitur. Pendekatan ini mudah dijelaskan dan berfungsi dengan persyaratan platform.

Kekurangannya adalah divergensi artefak. Tiga pembangunan dapat berisi perilaku yang berbeda, bukan hanya pengaturan yang berbeda, terutama ketika kompilasi kondisional atau skrip spesifik platform masuk ke dalam pipa. Setiap perubahan konfigurasi menciptakan pembangunan lain dan mungkin memicu tanda tangan, notarisasi, proses toko, atau koordinasi rilis manual.

Rollback juga terkait dengan distribusi artefak. Anda dapat kembali ke binary yang lebih tua, tetapi pengguna mungkin sudah memiliki versi yang berbeda, dan jalur rollback tergantung pada saluran distribusi.

Polanya tiga, konfigurasi waktu eksekusi

Konfigurasi waktu eksekusi memindahkan nilai yang dapat berubah ke luar artefak native. Aplikasi mengambil dokumen konfigurasi pada saat peluncuran atau membaca dokumen yang disimpan secara lokal yang sebelumnya dikirimkan. Ini memungkinkan tim memperbaiki endpoint dan flag tanpa mengubah aplikasi code.

Perbandingan adalah dependensi baru startup. Jika layanan konfigurasi remote tidak tersedia, aplikasi membutuhkan cache aman, waktu tunggu terbatas, dan kebijakan fallback yang diketahui. Fallback tidak boleh menunjuk ke lingkungan yang salah. Validasi skema dokumen, autentikasikan sumbernya jika perlu, dan catat versi konfigurasi yang digunakan aplikasi.

Untuk aplikasi hybrid, pola ini biasanya paling fleksibel untuk nilai non-rahasia. Namun, ini memerlukan perilaku offline yang hati-hati karena pengguna mobile dapat menjalankan aplikasi tanpa koneksi jaringan.

Pola keempat, manajemen rahasia yang spesifik

Platform seperti HashiCorp Vault dan AWS Secrets Manager dirancang untuk mengontrol material backend sensitif. Mereka mendukung kebijakan akses, jejak audit, enkripsi, dan alur kerja rotasi. Hal ini membuat mereka cocok untuk layanan server-side yang dapat autentikasi ke penyimpanan rahasia tanpa mengekspos kredential kepada pengguna.

Mereka tidak menyelesaikan masalah klien-rahasia. Rahasia yang dikirimkan ke klien mobile atau desktop biasanya dapat diperiksa oleh orang yang memiliki perangkat. Aplikasi klien hanya menerima nilai yang aman untuk dibocorkan, sementara operasi berkecukupan tetap di balik backend.

Tim yang bekerja pada aplikasi tunggal dengan perilisan yang jarang dapat memulai dengan bangun per-environment plus validasi yang ketat. Tim yang berkembang dengan pekerjaan staging dan produksi parallel memerlukan lapisan waktu untuk mengurangi divergensi artefak. Tim dengan frekuensi tinggi harus menggabungkan paket aplikasi yang tidak dapat diubah, konfigurasi waktu, dan pengelola rahasia untuk kredensial backend. The Petunjuk implementasi flag fitur untuk Capacitor cocok ke dalam lapisan waktu tersebut, asalkan flag difungsikan, diawasi, dan aman untuk menampilkan ke klien.

Implikasi Keamanan dan CI/CD yang Tidak Boleh Dilupakan

Nilai konfigurasi tidak otomatis aman karena berasal dari CI. Saat nilai masuk ke dalam paket klien, sumber daya native, arsip Electron, file log, laporan kegagalan, atau cadangan perangkat, asumsikan seseorang dengan akses ke artefak tersebut mungkin memeriksa nilai tersebut.

Identifikasi publik dan pengaturan sisi klien berbeda dari rahasia. Kunci API ponsel yang hanya mengidentifikasi aplikasi mungkin dapat diterima dalam bundle jika penyedia mengharapkannya ada dan membatasi penggunaannya. Kredensial basis data, rahasia tanda tangan, token berwenang, atau kredensial layanan tidak terbatas tidak aman di tempat yang sama. OWASP SAMM merekomendasikan memisahkan tugas atau mengenkripsi rahasia produksi, mencegah rahasia tidak terlindungi masuk ke repositori, dan mengelola siklus hidupnya daripada menunggu insiden.

Dimana pipa pengiriman mengalirkan konfigurasi

CI/CD systems fail in mundane ways. A shell command prints an expanded variable, a failed build includes a secret in an exception, or a debugging step archives an environment dump. A .env.production file mungkin juga masuk ke pengendalian versi karena sebuah repositori mewarisi yang tidak lengkap .gitignore.

Use a secure store for sensitive values and keep the pipeline’s permissions narrow. The build job should receive only the values required for that target, and logs should mask them. Review generated JavaScript, native resources, Electron archives, and source maps for accidental inclusion. A checksum or signature on a remotely delivered configuration payload can help detect tampering, but it doesn’t turn a client-visible value into a secret.

Tim yang mengelola analisis atau data sensitif lainnya dapat menggunakan sumber daya terpisah seperti ELECTE's makalah keamanan untuk analisis AI Mengulas tanggung jawab perlindungan data yang lebih luas. Ini melengkapi, bukan menggantikan, pengaturan kontrol konfigurasi aplikasi khusus.

Keamanan harus berada di samping kecepatan rilis

Polanya yang aman untuk rahasia produksi adalah penyimpanan yang dikendalikan, enkripsi dalam transit dan di tempat, akses dengan hak yang paling sedikit, dan rotasi. Untuk endpoint publik yang dapat berubah, polanya yang aman berbeda. Endpoint dapat disampaikan melalui dokumen runtime yang versi, divalidasi sebelum digunakan, dan dibatasi sehingga nilai yang rusak gagal tertutup.

Tidak masukkan kredential yang berkepentingan ke Capacitor atau Electron code untuk menghindari perjalanan balik backend. Jangan bergantung pada pengaburan, minifikasi, atau variabel renderer yang disembunyikan. Teknik-teknik tersebut membuat pemeriksaan kasual lebih sulit, tetapi tidak mengubah model kepercayaan perangkat klien.

Alur kerja yang praktis memisahkan tanggung jawab:

• Tata kelola sumber: Commit skema pengaturan konfigurasi dan contoh yang aman, tidak rahasia hidup.
• Langkah pembangunan: Inject hanya nilai yang diperlukan untuk menghasilkan artefak, dan mencegah ekspansi rahasia dalam log.
• Langkah pengiriman: Aplikasikan paket runtime yang spesifik lingkungan melalui saluran yang terotentifikasi dan dapat diamati.
• Stadium rotasi: Revoke dan ganti kembali kredential backend pada jadwal yang ditentukan, dengan jalur insiden untuk invalidasi segera.

The Praktik pengelolaan rahasia CI/CD untuk tim Capacitor paling berguna ketika dipasangkan dengan inventori eksplisit. Untuk setiap variabel, catat apakah itu publik atau sensitif, siapa yang menggunakannya, lingkungan mana yang menggunakan, dan apakah mengubahnya memerlukan rebuild asli.

Mengimplementasikan Konfigurasi Lingkungan di Capacitor dan Electron

Konfigurasi yang dapat dipertahankan dimulai dengan satu kontrak konfigurasi, bukan tumpukan kondisional spesifik framework. Simpan input lingkungan yang aman dalam file yang dapat diprediksi, muat melalui sistem bangun, dan terungkapkan ke aplikasi code melalui layanan kecil yang tipe.

Struktur repositori yang dapat berfungsi seperti ini:

.env
.env.staging
.env.production
.env.example
src/config/
  schema.ts
  config-service.ts
capacitor.config.ts
electron/
  main.ts
  preload.ts

Hanya .env.example yang harus berada di kontrol sumber. File lainnya harus diabaikan, dan CI harus menyediakan nilai untuk setiap target. File tersebut dapat berisi endpoint publik dan flag fitur, tetapi kredential backend sensitif harus tetap di gudang rahasia dan tidak pernah menjadi bagian dari paket klien.

Tentukan dan validasi satu kontrak

Dengan Vite, variabel yang terbuka ke klien biasanya menggunakan VITE_ prefix. Itu prefix adalah signal visibilitas, bukan batas keamanan.

// src/config/schema.ts
export type AppConfig = {
  apiBaseUrl: string
  enableNewCheckout: boolean
  environment: 'development' | 'staging' | 'production'
}

function required(name: string, value: string | undefined): string {
  if (!value) {
    throw new Error(`Missing required configuration: ${name}`)
  }
  return value
}

export function loadConfig(): AppConfig {
  const environment = required('VITE_APP_ENV', import.meta.env.VITE_APP_ENV)

  if (!['development', 'staging', 'production'].includes(environment)) {
    throw new Error(`Unsupported environment: ${environment}`)
  }

  return {
    apiBaseUrl: required('VITE_API_BASE_URL', import.meta.env.VITE_API_BASE_URL),
    enableNewCheckout: import.meta.env.VITE_ENABLE_NEW_CHECKOUT === 'true',
    environment: environment as AppConfig['environment'],
  }
}

Call loadConfig() during application startup. A missing value should produce a clear error rather than selecting a local endpoint. That single decision prevents a large class of production misrouting bugs.

Untuk pekerjaan lokal, Vite dapat memilih file yang tepat dengan mode-nya. Sebuah build tahap dapat menggunakan .env.stagingSedangkan sebuah build produksi menggunakan .env.productionPekerjaan CI harus menetapkan mode secara eksplisit bukan mewarisi apa yang pengembang gunakan secara lokal.

Capacitor native configuration

Proyek asli sering memerlukan identifikasi lingkungan spesifik, file layanan, atau pengaturan plugin. Simpan nilai-nilai tersebut di capacitor.config.ts,tapi hindari menempatkan kredit pribadi di sana.

// capacitor.config.ts
import type { CapacitorConfig } from '@capacitor/cli'

const isProduction = process.env.APP_ENV === 'production'

const config: CapacitorConfig = {
  appId: isProduction ? 'com.example.app' : 'com.example.app.staging',
  appName: isProduction ? 'Example' : 'Example Staging',
  webDir: 'dist',
  plugins: {
    PushNotifications: {
      presentationOptions: ['badge', 'sound', 'alert'],
    },
  },
}

export default config

Firebase files, push notification certificates, and platform identifiers should be selected by the native build pipeline and stored with appropriate access controls. The production app should never reuse staging service credentials because both builds happen to compile.

The The Capacitor panduan pengaturan lingkungan lokal bisa membantu tim standarisasi mode lokal, tetapi repositori masih memerlukan kontrak eksplisit dan validasi CI.

Electron memerlukan batasan proses

Electron's renderer bukanlah sama dengan proses utama Node.js. Dalam aplikasi yang diperkuat, process.env mungkin tersedia di proses utama tetapi tidak terdefinisi atau tidak tersedia secara sengaja di renderer. Kirimkan hanya konfigurasi yang aman melalui jembatan preload.

// electron/main.ts
import { app, BrowserWindow } from 'electron'
import path from 'node:path'

function createWindow() {
  const window = new BrowserWindow({
    webPreferences: {
      preload: path.join(__dirname, 'preload.js'),
      contextIsolation: true,
      nodeIntegration: false,
    },
  })

  const safeConfig = {
    apiBaseUrl: process.env.API_BASE_URL,
    environment: process.env.APP_ENV,
  }

  window.webContents.on('did-finish-load', () => {
    window.webContents.send('app-config', safeConfig)
  })

  return window
}

app.whenReady().then(createWindow)

// electron/preload.ts
import { contextBridge, ipcRenderer } from 'electron'

contextBridge.exposeInMainWorld('appConfig', {
  get: () => new Promise((resolve) => {
    ipcRenderer.once('app-config', (_event, config) => resolve(config))
  }),
})

Validasi objek lagi di renderer. Jembatan harus menampilkan hanya nilai runtime publik, tidak pernah token penyimpanan rahasia atau kemampuan filesystem yang berkepentingan.

Kesalahan implementasi yang paling umum adalah menganggap .env File-file otomatis privat. Sebuah bundler dapat menyertakan nilai-nilainya dalam JavaScript yang dihasilkan, dan langkah pengemasan dapat menyertakan file-file itu sendiri. Periksa artefak akhir, bukan hanya pohon sumber.

Simplifikasi Perbaruan dan Rollback yang Ditargetkan dengan Capgo

Meskipun setup waktu pembangunan yang disiplin meninggalkan celah operasional yang keras. Jika endpoint publik berubah setelah rilis, aplikasi native mungkin masih mengandung nilai lama. Membangun dan mendistribusikan biner baru yang diperlukan adalah berlebihan ketika perubahan yang diperlukan hanya mempengaruhi layer web.

Capgo’s model pembaruan hidup mengatasi celah tersebut dengan saluran yang ditargetkan untuk tingkat penggunaan seperti pengembangan, pengujian, dan produksi. Sebuah tim dapat menerbitkan JavaScript yang ditandatangani, CSS, konfigurasi, atau bundle aset ke saluran yang sesuai dengan lingkungan yang terpengaruh. Kelonggaran shell native tetap terpasang sementara aplikasi menerapkan pembaruan yang kompatibel pada peluncuran berikutnya.

Pertimbangkan endpoint produksi API yang berubah secara tidak terduga. Tim dapat memperbarui sumber konfigurasi, membangun bundle web, dan menerbitkannya ke saluran produksi daripada menunggu rilis toko native. Batas penting tetap utuh: pendekatan ini tidak menghindari aturan platform untuk native code, dan tidak membuat rahasia aman untuk dikirim. Namun, pendekatan ini dapat mengurangi waktu yang dibutuhkan untuk memperbaiki konfigurasi layer web yang kompatibel.

Saluran membuat kepemilikan lingkungan eksplisit

A channel harus terkait dengan lingkungan, bukan dengan preferensi individu pengembang. Pengujian pengembang menerima konten pengembangan, pengguna staging menerima konten staging, dan pengguna produksi hanya menerima bundle yang disetujui untuk produksi. CI dapat menerbitkan bundle yang tepat setelah langkah-langkah build dan validasi yang terkait.

Rollback juga sangat penting. Jika konfigurasi baru mengarah ke layanan yang tidak sehat, operator rilis harus dapat memilih bundle yang sebelumnya baik untuk channel tersebut. Riwayat versi, pengamanan peluncuran, dan pelaporan perangkat membantu tim menentukan apakah masalah tersebut luas atau hanya terbatas pada segment peluncuran.

Hasilnya adalah jalur promosi yang lebih jelas:

1. Bangun dan validasi bundle untuk pengembangan.
2. Promosikan konten yang sama ke staging.
3. Setujui update channel produksi.
4. Monitor adopsi dan gagal.
5. Revert channel jika konfigurasi berperilaku tidak tepat.

Proses tersebut mengurangi keinginan untuk membuat build native darurat untuk setiap perbaikan endpoint. Versi kontrol dan alur rollback __CAPGO_KEEP_0__ Capgo version control and rollback workflow Pentingnya ini sangat relevan bagi tim yang memerlukan rilis yang spesifik untuk lingkungan tanpa kehilangan riwayat yang dapat diliacak.

Jalur Promosi yang Jelas: Pengembangan, Staging, Produksi

Jalankan audit ini sebelum setiap rilis besar dan setelah perubahan pipeline apa pun.

• Periksa artefak: Pastikan tidak ada rahasia yang muncul di file yang dikomit, JavaScript yang dihasilkan, sumber daya native, peta sumber, atau arsip Electron.
• Jalur lingkungan terpisah: Verifikasi bahwa pengembangan, pengujian, dan produksi menggunakan endpoint, identifikasi, dan kunci yang disetujui yang berbeda.
• Lindungi input: Periksa bahwa setiap .env varian diabaikan, sementara .env.example mendokumentasikan skema yang diperlukan.
• Ulas CI: Pastikan pipa injeksi nilai dari penyimpanan yang dikendalikan daripada bergantung pada mesin lokal seorang pengembang.
• Uji pemulihan: Konfigurasi runtime gagal dengan cepat ketika nilai yang diperlukan hilang dan bahwa pembaruan yang kompatibel dapat dibalik tanpa membangun kembali shell native.

Audit lengkap hanya ketika seseorang dapat mengidentifikasi pemilik, sumber, ruang lingkup, dan prosedur balik untuk setiap nilai konfigurasi produksi.

Capgo menyediakan pembaruan hidup yang ditandatangani untuk aplikasi CapacitorJS dan Electron, termasuk saluran yang ditargetkan dan balik ke versi yang kompatibel untuk perubahan JavaScript, CSS, konfigurasi, dan aset. Capgo dan evaluasikan bersama proses CI/CD yang ada Anda.