Il Deployment Continuo è un approccio particolare nello sviluppo software, utilizzato per l'implementazione rapida, sicura ed efficiente di varie funzionalità nel software.
L'idea principale è quella di creare un processo automatizzato affidabile che consenta agli sviluppatori di fornire rapidamente un prodotto finito agli utenti. In questo contesto, vengono apportate modifiche costanti in produzione, un processo noto come CD Pipeline (conveyor di consegna continua).
Skillbox consiglia: Corso pratico .
Ricordiamo: per tutti i lettori di «Habr» — sconto di 10.000 rubli per l'iscrizione a qualsiasi corso Skillbox con il codice promozionale «Habr».
Per gestire il flusso, si possono utilizzare una vasta gamma di strumenti, sia a pagamento che completamente gratuiti. In questo articolo vengono descritti tre delle soluzioni più popolari tra gli sviluppatori che possono risultare utili a ogni programmatore.
Jenkins
Un server di automazione completamente autonomo con codice sorgente aperto. È consigliato utilizzarlo per automatizzare tutti i tipi di attività legate a build, test, distribuzione o deployment del software.
Requisiti minimi del PC:
- 256 MB di RAM, 1 GB di spazio su disco.
Ottimale:
- 1 GB di RAM, 50 GB su disco rigido.
Per il suo funzionamento, è necessario avere anche un software aggiuntivo: Java Runtime Environment (JRE) versione 8.
L'architettura (calcolo distribuito) si presenta come segue:
Jenkins Server — l'installazione responsabile dell'hosting della GUI e dell'organizzazione e dell'esecuzione di tutte le build.
Jenkins Node/Slave/Build Server — dispositivi che possono essere configurati per eseguire il lavoro di build per conto del Master (nodo principale).
Installazione per Linux
Prima di tutto, è necessario aggiungere il repository Jenkins al sistema:
cd /tmp && wget -q -O — | sudo apt-key add — echo 'deb binary/' | sudo tee -a /etc/apt/sources.list.d/je
Aggiornare il repository dei pacchetti:
sudo apt update
Installare Jenkins:
sudo apt install jenkins
Dopo ciò, Jenkins sarà disponibile nel sistema sulla porta predefinita 8080.
Per verificare il funzionamento, aprire nel browser l'indirizzo :8080. Il sistema chiederà quindi di inserire la password iniziale dell'utente con diritti di root. Questa password si trova nel file /var/lib/jenkins/secrets/initialAdminPassword.
Ora tutto è pronto per lavorare, si può procedere alla creazione dei flussi CI/CD. L'interfaccia grafica dell'ambiente di lavoro si presenta come segue:
Punti di forza di Jenkins:
- scalabilità offerta dall'architettura Master/Slave;
- disponibilità di API REST XML/JSON;
- possibilità di connettere un gran numero di estensioni tramite plugin;
- una comunità attiva e in continua evoluzione.
Contro:
- assenza di un modulo analitico;
- interfaccia non molto intuitiva.
TeamCity
Sviluppo commerciale da JetBrains. Il server ha una configurazione semplice e un'interfaccia eccellente. Nella configurazione predefinita ci sono molte funzionalità e il numero di plugin disponibili è in continua crescita.
È necessaria la versione 8 del Java Runtime Environment (JRE).
I requisiti hardware del server sono non critici:
- RAM — 3,2 GB;
- processore — dual-core, 3,2 GHz;
- canale di comunicazione con larghezza di banda di 1 Gb/s.
Il server consente di ottenere elevate prestazioni:
- 60 progetti con 300 configurazioni di build;
- allocazione di 2 MB per il log di build;
- 50 agenti di build;
- possibilità di utilizzo di 50 utenti nella versione web e 30 utenti nell'IDE;
- 100 connessioni a un VCS esterno, tipicamente Perforce e Subversion. Tempo medio di modifica — 120 secondi;
- oltre 150 modifiche al giorno;
- operazioni con DB su un unico server;
- impostazioni del processo server JVM: -Xmx1100m -XX:MaxPermSize=120m.
I requisiti per l'agente sono determinati dalle build in esecuzione. La funzione principale del server è monitorare tutti gli agenti connessi e distribuire le build dalla coda a questi agenti sulla base dei requisiti di compatibilità, comunicando i risultati. Gli agenti operano su diverse piattaforme e sistemi operativi, oltre a una configurazione preimpostata.
Tutte le informazioni sui risultati delle build sono memorizzate nel database. Si tratta principalmente della cronologia e di altri dati simili, delle modifiche al VCS, degli agenti, delle code di build, degli account e delle autorizzazioni degli utenti. Solo i registri di build e gli artefatti non sono inclusi nel database.
Installazione per Linux
Per l'installazione manuale di TeamCity con un contenitore servlet Tomcat, è necessario utilizzare l'archivio TeamCity: TeamCity .tar.gz. Scarica .
tar -xfz TeamCity.tar.gz
/bin /runAll. sh [start|stop]
All'avvio iniziale è necessario scegliere il tipo di DB in cui saranno memorizzati i dati di build.
La configurazione predefinita funziona su :8111/ con un agente di build registrato in esecuzione sulla stessa macchina.
Punti di forza di TeamCity:
- impostazione semplice;
- interfaccia user-friendly;
- grande numero di funzionalità integrate;
- servizio di supporto;
- disponibile RESTful API;
- buona documentazione;
- buona sicurezza.
Contro:
- integrazione limitata;
- è uno strumento a pagamento;
- piccola comunità (che, tuttavia, è in crescita).
GoCD
progetto open source che richiede Java Runtime Environment (JRE) versione 8 per l'installazione e il funzionamento.
Requisiti di sistema:
- RAM — almeno 1 GB, meglio di più;
- processore — dual-core, con frequenza di lavoro del nucleo di 2 GHz;
- disco rigido — almeno 1 GB di spazio libero.
Agente:
- RAM — almeno 128 MB, meglio di più;
- processore — almeno 2 GHz.
Il server gestisce gli agenti e offre un'interfaccia utente comoda:
Stages/Jobs/Tasks:
Installazione per Linux
echo “deb /” | sudo tee /etc/apt/sources.list.d/gocd.list
curl | sudo apt-key add —
add-apt-repository ppa:openjdk-r/ppa
apt-get update
apt-get install -y openjdk-8-jre
apt-get install go-server
apt-get install go-agent
/etc/init.d/go-server [start|stop|status|restart]
/etc/init.d/go-agent [start|stop|status|restart]
Per impostazione predefinita, GoCD funziona su :8153.
Punti di forza di GoCD:
- codice sorgente aperto;
- installazione e configurazione semplici;
- buona documentazione;
- ottima interfaccia utente:
- possibilità di visualizzare in modo step-by-step il percorso di distribuzione di GoCD in un'unica vista:
- ottima rappresentazione della struttura del pipeline:
- GoCD ottimizza il flusso di lavoro CD nei più richiesti ambienti cloud, inclusi Docker, AWS;
- questo strumento consente di correggere le problematiche nel pipeline, tracciando ogni modifica dal commit al deployment in tempo reale.
Contro:
- è necessario almeno un agente;
- non c'è una console per visualizzare tutti i compiti eseguiti;
- per eseguire ogni comando è necessario creare un compito per la configurazione del pipeline;
- per installare il plugin è necessario spostare il file .jar in /plugins/external e riavviare il server;
- una comunità relativamente piccola.
Come output
Ci sono solo tre strumenti, ma in realtà ce ne sono molti di più. È difficile scegliere, quindi è fondamentale prestare attenzione ad aspetti aggiuntivi.
Il codice sorgente aperto dello strumento consente di comprendere meglio di cosa si tratta e di aggiungere nuove funzionalità più rapidamente. Tuttavia, se qualcosa non funziona, bisogna fare affidamento solo su se stessi e sul supporto della community. Gli strumenti a pagamento offrono assistenza che può rivelarsi critticamente importante.
Se la sicurezza è la priorità assoluta, è meglio utilizzare uno strumento locale. Se non è così, è valida la scelta di una soluzione SaaS.
Infine, per garantire un processo di deployment continuo davvero efficace, è necessario definire criteri che restringano la scelta degli strumenti disponibili.
Skillbox consiglia:
- Corso pratico di due anni .
- Corso online .
- Corso pratico annuale .
Fonte: habr.com
