DevOps aziendale enterprise-devops
La metodologia DevOps tratta i processi, i metodi e la comunicazione necessari per:
- Semplificare l’implementazione del software nei diversi ambienti.
- Semplificare la collaborazione tra i team di sviluppo, test e implementazione.
DevOps punta a evitare problemi come:
- Errori manuali
- Elementi dimenticati, come file e dettagli di configurazione
- Discrepanze, ad esempio tra l’ambiente locale di uno sviluppatore e altri ambienti
Ambienti environments
Un’implementazione di Adobe Experience Manager (AEM) in genere è costituita da più ambienti, utilizzati per scopi diversi a diversi livelli:
Sviluppo development
Gli sviluppatori sono responsabili dello sviluppo e della personalizzazione del progetto proposto (che si tratti di un sito web, applicazioni mobili, implementazione DAM, ecc.) con tutte le funzionalità richieste. Si occupano di:
- sviluppare e personalizzare gli elementi necessari, ad esempio modelli, componenti, flussi di lavoro, applicazioni;
- realizzare la progettazione;
- sviluppare i servizi e gli script necessari per implementare le funzionalità richieste.
La configurazione dell'ambiente sviluppo può dipendere da vari fattori, anche se è composta da:
- Un sistema di sviluppo integrato con controllo della versione per fornire una base di codice integrata. Viene utilizzato per unire e consolidare il codice dei singoli ambienti di sviluppo utilizzati da ogni sviluppatore.
- Un ambiente personale per ogni sviluppatore, di solito residente sulla sua macchina locale. A intervalli appropriati il codice viene sincronizzato con il sistema di controllo delle versioni
A seconda delle dimensioni del sistema, nell’ambiente di sviluppo possono essere presenti sia istanze di authoring che di pubblicazione.
Controllo qualità quality-assurance
Questo ambiente viene utilizzato dal team di controllo qualità per testare in modo completo il nuovo sistema, sia a livello di progettazione che di funzionalità. Deve disporre di ambienti di authoring e di pubblicazione con contenuti appropriati e fornire tutti i servizi necessari per abilitare una suite completa di test.
Staging staging
L’ambiente di staging deve riflettere l’ambiente di produzione, cioè la sua configurazione, il suo codice e il suo contenuto:
- Viene utilizzato per testare gli script impiegati per implementare la distribuzione effettiva.
- Può essere utilizzato per i test finali (progettazione, funzionalità e interfacce) prima dell’implementazione negli ambienti di produzione.
- Anche se non è sempre possibile che l’ambiente di staging sia identico a quello di produzione, dovrebbe essere il più simile possibile per consentire l’esecuzione di test delle prestazioni e del carico.
Produzione: authoring e pubblicazione production-author-and-publish
L’ambiente di produzione è costituito dagli ambienti necessari per effettuare l’authoring e pubblicare l’implementazione.
Un ambiente di produzione è costituito da almeno un’istanza di authoring e un’istanza di pubblicazione:
- Un’istanza di authoring per l’input dei contenuti.
- Un’istanza di pubblicazione per i contenuti resi disponibili ai visitatori o utenti.
A seconda delle dimensioni del progetto, è spesso costituito da diverse istanze di authoring, diverse istanze di pubblicazione o entrambe. A un livello inferiore, anche l’archivio può essere raggruppato in più istanze.
Autore author
Le istanze di authoring si trovano in genere dietro il firewall interno. Questo è l’ambiente in cui tu e i tuoi colleghi eseguite le attività di authoring, ad esempio:
- amministrare l’intero sistema
- immettere i contenuti
- configurare il layout e la progettazione dei contenuti
- attivare i contenuti nell’ambiente di pubblicazione
I contenuti attivati vengono inseriti in un pacchetto e posizionati nella coda di replica dell’ambiente di authoring. Il processo di replica trasferisce quindi tali contenuti all’ambiente di pubblicazione.
Per eseguire la replica inversa nell’ambiente di authoring dei dati generati in un ambiente di pubblicazione, un listener di replica nell’ambiente di authoring esegue il polling dell’ambiente di pubblicazione e recupera tali contenuti dalla casella in uscita della replica inversa dell’ambiente di pubblicazione.
Pubblicazione publish
Un ambiente di pubblicazione si trova nella zona demilitarizzata (DMZ). Questo è l’ambiente in cui i visitatori accedono al contenuto (ad esempio tramite un sito web o un’app mobile) e interagiscono con esso, sia esso pubblico o nella rete Intranet. Un ambiente di pubblicazione:
- ospita i contenuti replicati dall’ambiente di authoring;
- rende tali contenuti disponibili ai visitatori;
- memorizza i dati utente generati dai visitatori, ad esempio commenti o moduli inviati;
- può essere configurato per aggiungere tali dati utente a una casella in uscita per la replica inversa nell’ambiente di authoring.
L’ambiente di pubblicazione genera i contenuti in tempo reale e in modo dinamico e può essere personalizzato per ogni singolo utente.
Spostamento del codice code-movement
Proponi sempre il codice dal basso verso l’alto:
- il codice viene inizialmente sviluppato negli ambienti di sviluppo locali e poi integrati
- seguiti da approfonditi test negli ambienti di controllo qualità
- Quindi viene testato nuovamente negli ambienti di gestione temporanea.
- Solo a questo punto il codice può essere distribuito agli ambienti di produzione.
Il codice (ad esempio, funzionalità di applicazioni web personalizzate e modelli di progettazione) viene trasferito esportando e importando pacchetti tra i diversi archivi di contenuto. Se utile, questa replica può essere configurata come processo automatico.
I progetti AEM spesso attivano la distribuzione del codice:
- Automaticamente: per il trasferimento negli ambienti di sviluppo e di controllo qualità.
- Manualmente: le distribuzioni negli ambienti di staging e produzione sono effettuate in modo più controllato, spesso manuale, anche se l’automazione è possibile se necessaria.
Spostamento dei contenuti content-movement
I contenuti destinati alla produzione devono sempre essere creati nell’istanza di authoring di produzione.
I contenuti non devono seguire il codice che si sposta dagli ambienti inferiori a quelli superiori. È bene evitare che i contenuti vengano creati su computer locali o in ambienti inferiori e poi spostati nell’ambiente di produzione. Tale procedura non è infatti una buona prassi, in quanto suscettibile a errori e incoerenze.
I contenuti di produzione devono essere spostati dall’ambiente di produzione all’ambiente di staging per garantire che quest’ultimo fornisca un ambiente di test efficiente e accurato.
Il contenuto può essere trasferito:
- tra i diversi ambienti esportando e importando pacchetti;
- Tra istanze diverse tramite la replica diretta (Replica AEM) del contenuto (tramite una connessione HTTP o HTTPS).
