Il treno di rilascio di Salesforce: un approccio pratico alla gestione dei rilasci

La gestione del rilascio, come suggerisce il nome, è il processo di gestione, pianificazione, programmazione e controllo di una build software attraverso diverse fasi e ambienti; compreso il test e la distribuzione di versioni software (Humble & Farley, 2011).

È un argomento piuttosto ampio in sé e può essere perfezionato nel tempo solo provando diverse iterazioni con i team di sviluppo e soddisfacendo le esigenze aziendali o le versioni di funzionalità. Cercheremo di coprire le pratiche del settore della gestione dei metadati, della creazione di CI e della gestione della sandbox per la gestione del treno di rilascio di un'organizzazione.

Ma cos'è un treno di rilascio?

Un treno di rilascio è una tecnica di distribuzione delle funzionalità incrementale e prevedibile. Richiede allo sviluppatore di impostare un processo formale per prendere tutte le modifiche apportate nell'ambiente di sviluppo e distribuirle alla produzione.

Un treno di rilascio può essere sostanzialmente suddiviso in tre segmenti:

• Gestione dei metadati
• Costruzione di integrazione continua
• Gestione sandbox

Gestione dei metadati

I metadati sono dati che forniscono informazioni su altri dati. Salesforce fornisce un modello di metadati ricco e potente tramite la sua API di metadati . I metadati dell'applicazione descrivono e comprendono un insieme di metodi che forniscono l'accesso a livello di codice al codice sorgente e alla configurazione dell'organizzazione.

L'API dei metadati è il modo migliore per gestire le personalizzazioni in Salesforce. Supporta i metodi di create , read , update ed delete . Puoi utilizzare i set di modifiche, l'IDE Force.com e lo strumento di migrazione Ant per migrare i metadati da un'organizzazione all'altra, poiché tutti forniscono migrazioni tramite l'API.

Ogni strumento ha i suoi vantaggi e ci sono diverse cose da considerare quando ne scegli uno:

Tabella 1: confronto degli strumenti per la migrazione dei metadati

L'API dei metadati è ottima per svolgere il suo scopo durante lo sviluppo e la migrazione delle modifiche sulla piattaforma Force.com. Ma c'è un piccolo problema: non tutti i metadati di Salesforce sono supportati dall'API dei metadati. La documentazione ufficiale fornisce un elenco di componenti non supportati.

Se la tua organizzazione sta apportando modifiche non supportate dall'API dei metadati, devi assicurarti di replicare tali modifiche manualmente nell'organizzazione di destinazione. Il modo migliore per tenere traccia di queste modifiche è un foglio di calcolo. Se devi ricorrere a questo approccio, è sempre consigliabile che una sola persona apporti queste modifiche e le tenga traccia.

Questo sarebbe un buon elenco generale di colonne che è possibile utilizzare per tenere traccia di queste modifiche in un foglio di calcolo:

• Nome del componente
• Tipo di componente
• Cambiare proprietario
• Descrizione della funzionalità
• Mappatura delle capacità
• Dipendenza con altri componenti
• Nome recensito/revisore
• URL
• Nome/ID organizzazione
• Altri commenti

Controllo della versione e integrazione continua

La migrazione delle modifiche alla produzione dovrebbe essere un processo agevole, poiché è solo una ripetizione dell'applicazione delle modifiche nell'ambiente di test e staging. Tuttavia, c'è sempre la possibilità che le cose vadano male, e quindi hai bisogno di un piano di ripiego. È molto importante mantenere il backup dei metadati dell'organizzazione ed è a questo che servono il controllo della versione e la build CI .

Il controllo della versione è un must assoluto per qualsiasi organizzazione. Consente agli sviluppatori di lavorare in modo collaborativo, efficiente e sicuro. La gestione dello sviluppo e della migrazione del codice multi-sviluppatore e multi-sandbox è una sfida in Salesforce. Salesforce ha anche una propria pianificazione per i rilasci e la manutenzione. Questi aggiornamenti offrono nuove funzionalità, ma potrebbero introdurre una modifica nell'API dei metadati che potrebbe interrompere la build del CI. Quindi, a parte le situazioni in cui gli sviluppatori sovrascrivono le modifiche reciproche, il controllo della versione ti aiuta a costruire una strategia di rollback. Avere una strategia di rollback è un must quando l'applicazione viene eseguita su Force.com.

Il diagramma di flusso seguente illustra una struttura pratica per Controllo versione e CI. Cercheremo di darti una breve descrizione di cosa rappresenta il diagramma.

1. Uno sviluppatore verificherebbe la modifica nel sistema di controllo della versione.
2. Il server CI/Jenkins distribuirà la build più recente nella sandbox CI ed eseguirà classi di test.
3. Se la distribuzione nel passaggio 2 ha esito positivo, le modifiche vengono unite nel ramo QA.
4. CI distribuirà quindi l'ultimo commit dal ramo QA alla sandbox QA.
5. Se il QA rifiuta le modifiche a causa di test non riusciti, i passaggi da 1 a 3 devono essere eseguiti di nuovo fino a quando il QA non cancella le modifiche.
6. Dopo che le modifiche hanno superato il test in QA, le modifiche vengono unite nel ramo Master.
7. Le ultime modifiche dal ramo Master vengono distribuite nella sandbox Master.

Si può scegliere di aggiungere più filiali a seconda delle esigenze dell'organizzazione. Ma la struttura di cui sopra funziona bene per le strutture di sviluppo di livello medio-impresa.

Gestione sandbox

Per ottenere il massimo dal processo DevOps della tua organizzazione, è molto importante configurare la struttura sandbox. Prima di approfondire l'argomento, discutiamo dei diversi tipi di sandbox che Salesforce ci offre.

Una sandbox è una copia quasi esatta dei propri metadati di produzione. Le sandbox vengono in genere utilizzate per scopi di sviluppo, test, gestione temporanea e formazione. Esistono quattro tipi di sandbox e uno dovrebbe tenere in debita considerazione quando si sceglie una sandbox. Le sandbox di copia completa potrebbero costare un sacco di soldi!

Di seguito è riportata la tabella dei limiti applicati da Salesforce per le diverse sandbox.

Tabella 2: Confronto dei limiti

Possiamo vedere che il prezzo non è l'unica differenza tra le sandbox.

La sandbox per sviluppatori ha un periodo di aggiornamento di un giorno, che la rende adatta allo sviluppo, ma può contenere solo 200 MB di dati e nessun dato di produzione. Al contrario, le sandbox a copia completa hanno una copia esatta dei dati di produzione; anche gli ID record sono gli stessi. Ciò potrebbe renderlo ottimo per i test e lo staging, ma il periodo di aggiornamento di 29 giorni rende difficile ottenere i metadati e i dati di produzione più recenti nella sandbox della copia completa.

La tabella seguente funge da regola pratica per la selezione delle sandbox:

Tabella 3: Casi d'uso per la selezione della sandbox

Di seguito è riportata la tipica struttura organizzativa adottata per progetti di medie dimensioni. Per i clienti di livello aziendale, la struttura dell'organizzazione diventa più complessa ma segue ampiamente il modello seguente.

Lo sviluppo di Salesforce viene solitamente eseguito nella sandbox per sviluppatori (rossa) e le modifiche vengono spostate nella sandbox di integrazione (verde), che di solito è una sandbox per sviluppatori professionisti o una sandbox con copia parziale. Quindi le modifiche da più sandbox di integrazione vengono spostate nella sandbox di rollup (gialla) che dovrebbe essere una sandbox di copia parziale.

Se la tua organizzazione ha integrazioni con il sistema di terze parti che richiedono l'esecuzione di test di integrazione e test di carico, è necessario disporre di un set di dati stabile che non cambi da un rilascio all'altro. Quindi, è meglio avere una copia completa o una sandbox di copia parziale per questo.

Queste modifiche vengono quindi spostate nella sandbox dei test di integrazione, dove vengono eseguiti i test. Quindi le modifiche vengono spostate nella sandbox di staging, che dovrebbe essere una sandbox di copia completa. Tutte le classi di test vengono eseguite prima della distribuzione. È necessario eseguire una convalida della distribuzione per assicurarsi che la distribuzione avvenga senza problemi.

Questo processo ci aiuta ad assicurarci che le modifiche passino attraverso più cicli di test e paia di occhi. Ha il pesante svantaggio di richiedere molto tempo per sviluppare, testare e distribuire le modifiche.

Molto spesso, è urgente eseguire correzioni di bug o patch. Per gestirli rapidamente, è necessario mantenere una sandbox per sviluppatori, che spingerebbe piccole patch direttamente nella sandbox di rollup.

Come accennato in precedenza, una sandbox è una replica quasi esatta dei metadati di produzione, ma non completamente. C'è un elenco ufficiale di componenti/funzionalità che sono disabilitati in una sandbox.

Un'altra cosa da considerare durante l'aggiornamento di una sandbox è che copia solo i metadati e i dati di produzione. Non c'è modo di copiare i metadati da una sandbox a un'altra, o anche di creare una sandbox vuota senza alcuna configurazione di metadati (come le organizzazioni di sviluppatori gratuite). Questo a volte diventa una sfida in situazioni di vita reale. Salesforce ha in programma di affrontare questo problema e questa funzionalità potrebbe presto diventare disponibile a livello generale.

Inoltre, se disponi di alcuni dati sensibili in produzione, a cui ritieni che il tuo team di sviluppo o test non dovrebbe avere accesso, puoi creare modelli sandbox per sandbox completamente e parzialmente copiati.

Cosa considerare quando si distribuisce

Abbiamo coperto le pratiche del settore della gestione del ciclo di vita delle applicazioni nell'ecosistema Salesforce. La gestione dei metadati e della sandbox gioca un ruolo molto importante nella creazione dei pacchetti di distribuzione e dei payload. Per le applicazioni Salesforce grandi e complesse, il controllo della versione aiuta a garantire che le modifiche ai metadati vengano tracciate, aiutando anche nella creazione di una strategia di rollback.

La gestione della sandbox è fondamentale per progetti grandi o complessi. Ma i Sandbox sono costosi nell'ecosistema Salesforce, sia in termini di risorse finanziarie che di tempo. La formulazione di una strategia per la gestione della sandbox è sempre fondamentale per il processo di gestione dei rilasci.

Ti lasciamo con alcuni punti extra che sarebbe bene tenere a mente durante la tua prossima distribuzione:

1. È possibile distribuire solo 10.000 file o un file ZIP da 39 MB in una volta sola. Naturalmente, se il carico utile è troppo grande, devi dividere il pacchetto in più parti e quindi eseguire la distribuzione.
2. Se la distribuzione non riesce a causa di un errore di request timeout , provare a rimuovere oggetti, campi personalizzati e profili dal pacchetto. Questi componenti richiedono più tempo per la distribuzione.
3. Se un tipo di campo viene modificato o sono state apportate modifiche alla gerarchia dei ruoli, potrebbero verificarsi lunghi ritardi dovuti al ricalcolo dei dati, che richiedono del tempo per il completamento.
4. Salesforce blocca qualsiasi componente attualmente utilizzato da un utente nel sistema. Se proviamo a eseguire la distribuzione in questo caso, la distribuzione avrà esito negativo.

Si spera che questa panoramica ti aiuti durante la tua prossima versione di Salesforce.

Fonti