Configurazione dell'ambiente per le app moderne

Avete rilasciato la versione, firmato il binario nativo e guardato il rollout di produzione iniziare normalmente. Poi i supporti segnalano che gli utenti non possono completare un acquisto. Il log di crash sembra non avere nulla a che fare, quindi trascorrete ore a seguire le richieste, l'inizializzazione dei plugin e i recenti cambiamenti JavaScript. La causa si rivela essere una URL di staging API lasciata in un rilascio di produzione affrettato.

Quella fallita non è insolita. La configurazione dell'ambiente è la disciplina di mantenere impostazioni specifiche per la distribuzione, come API endpoint, flag di feature, credenziali del database e chiavi di terze parti, separate dall'applicazione code. In applicazioni Capacitor e Electron, la separazione è più difficile perché gli asset web sono bundlati all'interno di contenitori nativi, quindi un errore di configurazione può diventare parte di un artefatto firmato piuttosto che un valore che si può modificare sul server.

Il problema più profondo è la deriva di configurazioneLa graduale divergenza tra sviluppo, staging e produzione. Un sviluppatore aggiorna un .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 differenze tra sviluppo e produzione nei Capacitor app evitare alcuni errori evidenti, ma il drift richiede un modello operativo, non solo una convenzione di denominazione dei file migliore.

La domanda pratica è semplice: come si può inviare lo stesso codicebase in più ambienti senza dover ricostruire, riassegno o inviare un'app nativa per ogni cambiamento di configurazione?

Indice dei contenuti

Perché la configurazione dell'ambiente rompe le app di produzione
- Il drift inizia con eccezioni innocenti
- Configurazione di build-time crea un punto di bottiglia di rilascio
La comparazione dei quattro modelli di configurazione principali
Implicazioni di sicurezza e CI/CD che non si possono ignorare
- Dove i pipeline perdono la configurazione
- La sicurezza deve coesistere con la velocità di rilascio
Implementazione della configurazione dell'ambiente in Capacitor e Electron
Semplificare Aggiornamenti e Rollback mirati con Capgo
- I canali rendono esplicita la proprietà dell'ambiente
Elenco di controllo di audit della configurazione dell'ambiente

Perché la configurazione dell'ambiente rompe le applicazioni di produzione

I bug di configurazione più costosi sono raramente bug di configurazione. Una URL di base API sbagliata può manifestarsi come un errore di autenticazione, uno schermo account vuoto, un errore di pagamento o un crash di plugin nativo. Al momento in cui l'incidente raggiunge l'ingegnere che gestisce la pipeline di costruzione, l'errore originale può essere nascosto sotto più commit e una pubblicazione di store riuscita.

Gli applicativi ibridi hanno un particolare schema di fallimento. Capacitor compila un'applicazione web e colloca i suoi asset all'interno di un progetto iOS o Android. Electron pacchetta il renderer e il processo principale code in un'applicazione desktop. Se un endpoint o un flag di feature viene risolto durante quel build, il valore risultante viaggia con l'artefatto. Modificarlo in seguito significa produrre un nuovo bundle, firmarlo nuovamente e distribuirlo attraverso il canale applicabile.

Il drift inizia con eccezioni innocue

La deriva della configurazione cresce dalle scorciatoie ragionevoli:

Un sovrascrittura locale: Un sviluppatore immette un endpoint di test hardcoded per sbloccare una funzione e dimentica di rimuoverlo.
Una variabile di pipeline separata: CI utilizza un valore di produzione che non corrisponde alla configurazione documentata del repository.
Una impostazione nativa solo: Android, iOS e Electron ricevono identificatori di plugin o impostazioni di callback diversi.
Una flag non documentata: L'operazioni cambia un flag di funzione direttamente in un sistema di distribuzione, mentre la fase di staging continua ad utilizzare il comportamento vecchio.

Ogni scelta può funzionare in isolamento. Il problema inizia quando nessuno può rispondere quale valore è autoritativo, quale ambiente lo possiede e quando è stato modificato.

Regola pratica: Se un valore di configurazione può cambiare indipendentemente dalla logica dell'applicazione, trattalo come un input di distribuzione, non come una sorgente code.

Ambiente di staging dovrebbe assomigliare abbastanza a quello di produzione per esporre i problemi di integrazione, mentre utilizza ancora endpoint isolati, credenziali e dati. Quando gli ambienti si allontanano, lo staging smette di essere un utile allenamento. Una rilascio può superare ogni test contro un insieme di assunzioni e fallire immediatamente contro un altro.

La configurazione di build-time crea un bottleneccio di rilascio

La configurazione di build-time rimane utile. I valori di compilazione pubblici, gli identificatori specifici della piattaforma e le impostazioni richieste da strumenti nativi spesso devono esistere prima che l'applicazione sia pacchettizzata. Il problema è utilizzare l'iniezione di build-time per valori che le operazioni possono dover cambiare dopo il rilascio.

Supponga che un prodotto API di produzione si sposti su un nuovo endpoint. Con un flusso di lavoro tradizionale Capacitor, il team cambia il valore, costruisce gli asset web, sincronizza i progetti nativi, firma l'applicazione e la distribuisce attraverso il processo di rilascio della piattaforma. Gli team di Electron affrontano un ciclo simile quando il valore modificato appartiene all'interno dell'applicazione pacchettizzata.

Quel flusso di lavoro è accettabile per un rilascio di prodotto deliberato. È una risposta povera a una correzione di configurazione urgente. Il binario può essere sano, il JavaScript può essere invariato eppure una singola stringa può forzare un ciclo di distribuzione completo.

La progettazione più sicura separa tre layer:

Logica di applicazioneche dovrebbe rimanere identica across ambienti.
Configurazione dell'ambienteche seleziona endpoint, flag e comportamento di runtime non sensibili.
Materiali segretiche appartiene allo storage controllato e dovrebbe essere iniettato solo quando necessario.

Quella separazione rende visibile il drift. Inoltre, dà alla squadra una risposta chiara quando il prodotto si comporta in modo diverso: confronta gli input di configurazione prima di incolpare il code.

Comparare i quattro modelli di configurazione principali

Non esiste un modello di configurazione unico che si adatti a ogni parte di un'applicazione ibrida. Un backend può leggere le variabili di ambiente del processo al startup, mentre un Capacitor renderer può non avere un processo di server tradizionale. Electron aggiunge un'altra barriera tra il processo principale e il renderer. La scelta giusta dipende dal fatto che un valore sia pubblico, sensibile, mutabile dopo la rilascio o richiesto da strumenti di build nativi.

Modello uno, le variabili di ambiente 12-Fattori

Il modello 12-Fattori considera la configurazione come input specifico dell'ambiente piuttosto che come stato di applicazione hardcoded. Funziona naturalmente per i processi di server, i contenitori e i job di CI. Un servizio può leggere i suoi valori al startup e utilizzare lo stesso artefatto in più deployment.

Client-side apps complicate the model. A value referenced by browser JavaScript must eventually be available to the client, so it shouldn’t be treated as a secret merely because it arrived through an environment variable. A public API origin or feature flag can use build-time substitution, but credentials with meaningful privileges must not be shipped into a reversible client bundle.

Per il Capacitor e Electron, questo modello è il migliore per l'orchestrazione di build e la configurazione pubblicaNon è destinato alla protezione dei segreti. Ha un basso overhead concettuale, ma la mutabilità in esecuzione è limitata a meno che non esista un'altra layer di consegna.

Pattern due, costruzioni per ambiente

I team mantengono spesso profili di costruzione di sviluppo, di staging e di produzione. Ogni profilo seleziona il proprio endpoint, l'identificatore dell'applicazione, i file di servizio nativi e le bandiere delle funzionalità. L'approccio è facile da spiegare e funziona con le richieste della piattaforma.

La sua debolezza è la divergenza degli artefatti. Tre costruzioni possono contenere diverso comportamento, non solo impostazioni diverse, soprattutto quando la compilazione condizionale o i script specifici della piattaforma si infiltrano nella pipeline. Ogni cambiamento di configurazione crea un'altra costruzione e può attivare la firma, la notarizzazione, il trattamento della store o la coordinazione della rilascio manuale.

La rollback è anche legata alla distribuzione degli artefatti. Puoi tornare a un binario più vecchio, ma gli utenti possono già avere versioni diverse installate, e il percorso di rollback dipende dal canale di distribuzione.

Pattern tre, configurazione in esecuzione

La configurazione in esecuzione sposta i valori mutabili fuori dall'artefatto nativo. L'applicazione recupera un documento di configurazione al lancio o legge un documento memorizzato localmente che è stato consegnato precedentemente. Ciò consente ai team di correggere gli endpoint e le bandiere senza modificare l'applicazione code.

La scelta è una nuova dipendenza di avvio. Se il servizio di configurazione remota non è disponibile, l'app necessita di un cache sicuro, un timeout limitato e una politica di fallback nota. La politica di fallback non deve mai puntare all'ambiente sbagliato. Verifica lo schema del documento, autentica la sua fonte quando necessario e registra la versione di configurazione applicata dall'app.

Per le app ibride, questo è il modello più flessibile per i valori non segreti. Richiede però un comportamento offline attento perché gli utenti mobili possono avviare un'app senza connessione di rete.

Modello quattro, gestione dei segreti dedicata

Il software come HashiCorp Vault e AWS Secrets Manager sono progettati per controllare materiali backend sensibili. Supportano politiche di accesso, tracce di audit, crittografia e flussi di rotazione dei segreti. Ciò li rende adatti per i servizi server che possono autenticarsi nel magazzino dei segreti senza esporre le credenziali agli utenti.

Non risolvono il problema dei segreti client. Un segreto consegnato a un client mobile o desktop può essere di solito ispezionato dalla persona che possiede il dispositivo. Le applicazioni client dovrebbero ricevere solo valori che sono sicuri da rivelare, mentre le operazioni privilegiate rimangono dietro un backend.

Modello	Complessità di costruzione	Ripristino della sottoscrizione necessario	Velocità del rollback	Miglior per
Variabili 12 fattori	Bassa per i server, moderata per le costruzioni ibride	Di solito, per i valori del client aggregati	Moderato	Servizi backend e input di costruzione pubblici
Costruzioni per ambiente	Alto a causa dell'aumento degli ambienti	Sì, quando cambiano i valori aggregati	Lento a moderato	Piccoli team con rilasci sporadici
Configurazione di runtime	Moderato	No per le modifiche compatibili al layer web	Veloci, con payload versionate	Endpointi mutabili, flag, e comportamento del client
Piattaforme di gestione dei segreti	Moderato ad alto	No per i segreti backend-only	Veloci per i consumatori server	Crediti backend privilegiati

Gli squadre che lavorano su un'applicazione singola con rilasci occasionali possono iniziare con costruzioni per ambiente plus validazione rigorosa. Una squadra in crescita con lavoro di staging e produzione parallelo ha bisogno di un layer di esecuzione per ridurre la divergenza degli artefatti. Una squadra ad alta cadenza dovrebbe combinare bundle di applicazione immutabili, configurazione di runtime, e un gestore di segreti per i crediti backend. Il guida di implementazione delle feature flag per Capacitor si adatta in quel layer di esecuzione, se le flag sono scolate, auditate, e sicure da esporre al client.

Sicurezza e implicazioni CI/CD che non puoi ignorare

Un valore di configurazione non è automaticamente sicuro perché è arrivato da CI. Il momento in cui un valore entra in un bundle del client, in un risorsa nativa, in un archivio Electron, in un file di log, in un rapporto di crash, o in un backup del dispositivo, assume che qualcuno con accesso a quell'artefatto possa esaminarlo.

Identificatori pubblici e impostazioni client-side sono diversi dai segreti. Una chiave mobile API che identifica solo un'applicazione può essere accettabile in un bundle se il provider lo aspetta e ne limita l'uso. Un credenziale di database, un segreto di firma, un token privilegiato o un credenziale di servizio non limitato non è sicuro nello stesso posto. OWASP SAMM raccomanda di separare le responsabilità o di cifrare i segreti di produzione, impedendo ai segreti non protetti di entrare nei repository e gestendo il loro ciclo di vita piuttosto che aspettare un incidente.

Un diagramma che illustra tre fasi di rischi di sicurezza legati a segreti hardcoded nei flussi CI/CD e di distribuzione.

Dove i flussi di lavoro perdono la configurazione

Il sistema CI/CD fallisce in modi banali. Una riga di comando del shell stampa una variabile espansa, un build fallito include un segreto in un'eccezione o un passaggio di debug archivia un dump di ambiente. Un .env.production il file può anche entrare nel controllo versione perché un repository ha ereditato uno stato incompleto .gitignore.

Usa un archivio sicuro per valori sensibili e mantieni le autorizzazioni del pipeline strette. Il job di costruzione dovrebbe ricevere solo i valori richiesti per quel target e i log dovrebbero mascherarli. Verifica i JavaScript generati, le risorse native, gli archivi di Electron e le mappe di origine per l'inclusione accidentale. Un checksum o una firma su un payload di configurazione remotamente inviato può aiutare a rilevare la manipolazione, ma non trasforma un valore visibile dal client in un segreto.

Gli squadri che gestiscono analisi o dati sensibili possono utilizzare una risorsa separata come quella di ELECTE documento di sicurezza per l'analisi AI Quando si esamina una maggiore responsabilità di protezione dei dati. Si integra, piuttosto che sostituire, i controlli di configurazione specifici dell'applicazione.

La sicurezza deve coesistere con la velocità di rilascio

il modello sicuro per un segreto di produzione è lo storage controllato, l'encryption in transito e in stato di riposo, l'accesso con privilegi minimi e la rotazione. Per un endpoint pubblico mutabile, il modello sicuro è diverso. L'endpoint può essere consegnato attraverso un documento di runtime versionato, validato prima dell'uso e limitato in modo che un valore danneggiato fallisca chiuso.

Non inserire credenziali privilegiate in Capacitor o Electron code per evitare un giro di ritorno backend. Non si fidi dell'obfuscation, della minificazione o di una variabile renderer nascosta. Queste tecniche rendono l'ispezione casuale più difficile, ma non cambiano il modello di fiducia di un dispositivo client.

Un pipeline pratico separa le responsabilità:

Controllo sorgente: Inserisci schemi di configurazione e esempi sicuri, mai segreti in tempo reale.
Fase di costruzione: Inietta solo i valori richiesti per produrre l'artefatto e prevenire l'espansione dei segreti nei log.
Fase di consegna: Applica bundle di runtime specifici dell'ambiente attraverso un canale autenticato e osservabile.
Stadio di rotazione: Revoca e sostituzione dei credenziali del backend su un orario definito, con un percorso di incidente per l'invalidazione immediata.

Il Pratiche di gestione dei segreti CI/CD per i team Capacitor sono più utili quando vengono utilizzate in coppia con un inventario esplicito. Per ogni variabile, documentare se è pubblica o sensibile, chi ne è il proprietario, quali ambienti lo utilizzano e se modificandolo è necessario un rebuild nativo.

Implementazione di Environment Config in Capacitor e Electron

Un setup mantenibile inizia con un contratto di configurazione, non con una pila di condizionali specifiche del framework. Mantenere gli input di ambiente sicuri in file predittivi, caricarli attraverso il sistema di build e esporli all'applicazione code attraverso un piccolo servizio tipizzato.

Un layout di repository funzionale assomiglia a questo:

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

Solo .env.example deve essere presente nel controllo di versione. Gli altri file dovrebbero essere ignorati e il CI dovrebbe fornire i valori per ogni target. I file possono contenere endpoint pubblici e flag di feature, ma le credenziali backend sensibili dovrebbero rimanere in un archivio di segreti dedicato e non diventare mai parte del pacchetto del client.

Definisci e valuta un contratto

Con Vite, le variabili esposte al client normalmente utilizzano il VITE_ prefix. Questo prefisso è un segnale di visibilità, non un confine di sicurezza.

// 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'],
  }
}

Chiama loadConfig() Durante l'avvio dell'applicazione. Un valore mancante dovrebbe produrre un errore chiaro piuttosto che selezionare un endpoint locale. Quella sola decisione prevenirebbe una vasta classe di bug di routing in produzione.

Per il lavoro locale, Vite può selezionare il file appropriato con il suo modo. Un build di staging può utilizzare .env.stagingmentre un build di produzione utilizza .env.production. Il lavoro di CI dovrebbe impostare il modo esplicitamente anziché ereditare ciò che un sviluppatore ha utilizzato localmente.

Capacitor configurazione nativa

Progetti nativi spesso richiedono identificatori, file di servizio o impostazioni plugin specifici per l'ambiente. Mantieni quei valori in capacitor.config.tsma evita di collocare le credenziali private lì.

// 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

I file di Firebase, i certificati di notifica push e gli identificatori di piattaforma dovrebbero essere selezionati dal pipeline di costruzione nativa e archiviati con controlli di accesso appropriati. L'applicazione di produzione non dovrebbe mai riutilizzare le credenziali di servizio di staging perché entrambi i build vengono compilati.

La Capacitor guida di configurazione dell'ambiente locale può aiutare le squadre a standardizzare i modi locali, ma il repository richiede ancora un contratto esplicito e una validazione CI.

Richiede un confine di processo

Il renderer di Electron non è lo stesso del processo principale di Node.js. In un'applicazione protetta, process.env potrebbe essere disponibile nel processo principale ma indefinito o intenzionalmente non disponibile nel renderer. Passa solo la configurazione sicura attraverso un ponte di caricamento predefinito.

// 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))
  }),
})

Verifica nuovamente l'oggetto nel renderer. Il ponte dovrebbe esporre solo valori runtime pubblici, mai un token di archiviazione segreta o una capacità di filesystem privilegiata.

Aspetto	Capacitor	Electron
Configurazione di confine principale	Progetto nativo e asset web incorporati	Processo principale, caricamento pre, e renderer
Valori client sicuri	Punti di accesso pubblici e flag	Punti di accesso pubblici e flag passati attraverso preload
Credenziali sensibili	Tienile fuori dal pacchetto dell'app	Tienile fuori dall'archivio del pacchetto
Fallimento comune	Valori di build obsoleti dopo sincronizzazione nativa	`process.env` non disponibile nel renderer
Percorso di aggiornamento in esecuzione	Bundle web firmato o configurazione remota	Bundle web firmato o aggiornamento dell'applicazione controllato

L'errore di implementazione più comune è l'assunzione .env i file sono automaticamente privati. Un bundler può includere i loro valori nel JavaScript generato, e un passaggio di packaging può includere i file stessi. Ispeziona l'artefatto finale, non solo la directory dei sorgenti.

Semplificare Aggiornamenti e Rollback mirati con Capgo

Even a disciplined build-time setup leaves a hard operational gap. If a public endpoint changes after release, the native application may still contain the old value. Rebuilding and distributing a new binary is excessive when the required change affects only the web layer.

Il modello di aggiornamento in tempo reale di Capgo canali mirati per livelli di distribuzione come sviluppo, staging e produzione. Un team può pubblicare un pacchetto di JavaScript firmato, CSS, configurazione o asset nella canale che corrisponde all'ambiente interessato. La shell nativa rimane installata mentre l'applica l'aggiornamento compatibile alla sua prossima avviatura.

Un confronto tra le workflow di configurazione tradizionali delle app e gli aggiornamenti e i rollback istantanei utilizzando la piattaforma Capgo.

Considera un endpoint di produzione API che cambia inaspettatamente. Il team può aggiornare la fonte di configurazione, costruire il pacchetto web e pubblicarlo nel canale di produzione invece di attendere la rilascio di una store nativa. La importante barriera rimane intatta: questo approccio non bypassa le regole del platform per il code nativo, e non rende un segreto sicuro da spedire. Riduce comunque il tempo richiesto per correggere la configurazione compatibile del layer web.

I canali rendono l'ownership dell'ambiente esplicito

A un canale dovrebbe essere associato un ambiente, non alle preferenze individuali di un sviluppatore. I tester di sviluppo ricevono contenuti di sviluppo, gli utenti di staging ricevono contenuti di staging e gli utenti di produzione ricevono solo il bundle approvato per la produzione. Il CI può pubblicare il bundle appropriato dopo i passaggi di costruzione e validazione corrispondenti.

La rollback è altrettanto importante. Se la nuova configurazione punta a un servizio non salutare, l'operatore di rilascio dovrebbe poter selezionare il bundle precedente noto buono per quel canale. La versione storica, i guardiani di deploy e la segnalazione a livello di dispositivo aiutano la squadra a determinare se il problema è diffuso o limitato a un segmento di rilascio.

Il risultato è una promozione più chiara:

Costruisci e valuta il bundle per lo sviluppo.
Promuovi lo stesso contenuto testato a staging.
Approva l'aggiornamento del canale di produzione.
Monitora l'adozione e le fallite.
Reverti il canale se la configurazione comporta comportamenti scorretti.

Quel processo riduce l'impulso a creare build native di emergenza per ogni correzione di endpoint. Il Capgo controllo di versione e il workflow di rollback È particolarmente rilevante per le squadre che richiedono rilasci specifici per ambiente senza perdere la storia tracciabile.

La tua Checklist di audit della configurazione dell'ambiente

Eseguire questo audit prima di ogni rilascio importante e dopo qualsiasi cambiamento di pipeline.

Esegui l'ispezione degli artefatti: Non ci sono segreti nei file commessi, nei file JavaScript generati, nelle risorse native, nei mappe delle origini o negli archivi di Electron.
Esegui l'ispezione delle impostazioni ambiente: Verifica che i endpoint, gli identificatori e le chiavi approvate per lo sviluppo, la produzione e la produzione siano distinti.
Esegui l'ispezione delle impostazioni ambiente: Esegui l'ispezione delle impostazioni ambiente: .env Esegui l'ispezione delle impostazioni ambiente: .env.example Esegui l'ispezione delle impostazioni ambiente:
Valuta CI: Conferma i pipeline iniettano valori dai magazzini controllati piuttosto che affidarsi alla macchina locale del sviluppatore.
Esegui l'ispezione delle impostazioni ambiente: Verifica la configurazione runtime fallisce rapidamente quando manca un valore richiesto e che un aggiornamento compatibile può essere annullato senza ricostruire la shell nativa.

Una checklist infographic intitolata Checklist di audit della configurazione dell'ambiente con cinque passaggi per pratiche di distribuzione software sicure.

L'audit è completo solo quando qualcuno può identificare il proprietario, la fonte, lo scopo e la procedura di rollback per ogni valore di configurazione di produzione.

Capgo fornisce aggiornamenti live firmati per le applicazioni CapacitorJS e Electron, inclusi canali mirati e annullamenti versionati per modifiche JavaScript, CSS, configurazione e asset compatibili. Capgo e valuta insieme al tuo processo CI/CD esistente.