Organizzazione di Jenkins attorno alle filiali SVN e agli ambienti di distribuzione

Naviga le tue risposte
2

Impostazione corrente

Al momento disponiamo di un server Jenkins che automatizza le distribuzioni per circa 15 diverse applicazioni Web Java. Ogni applicazione ha tre ambienti di distribuzione su box Linux separati.

  1. sviluppo
  2. Prova
  3. Produzione

In Jenkins ogni applicazione ha la sua "vista". All'interno di ogni vista c'è un lavoro per ogni ramo. Questi lavori semplicemente creano un file di guerra e lo posizionano sul server Jenkins. Quindi, per implementare una persona DevOps, SSH verrà inserito nell'ambiente di distribuzione (sia esso dev, test, prod) per una particolare applicazione ed eseguirà uno script SCP che sposta il file war dal server Jenkins all'ambiente di distribuzione (di solito in una cartella webapps di Tomcat per la distribuzione).

Pubblicazioni

Ovviamente questo è un processo molto sciocco. Voglio avere un processo di distribuzione Jenkins che distribuisca effettivamente l'applicazione (quindi nessuno ha bisogno di SSH in una scatola ed eseguire uno script di shell SCP). Ho ottenuto questo processo di lavoro per alcune delle nostre applicazioni più piccole, ma sto riscontrando due problemi.

  1. Non conosco il modo migliore per organizzare i miei lavori
  2. Alcuni colleghi sono preoccupati di quanto sarebbe facile spingere accidentalmente un build di produzione.

Explained further

Sul numero 1 - Un modo ovvio per forzare la forza bruta consisterebbe nel creare un lavoro per ogni ambiente di distribuzione. Tuttavia, in quel caso non so come farlo in modo che il lavoro "Test environment di distribuzione" possa contenere come parametro il ramo che desidero distribuire. Non voglio dover creare tre lavori per ogni nuovo ramo (uno per ogni ambiente di distribuzione). Inoltre, potrei creare un lavoro per ogni ramo, ma poi non so come inviare l'ambiente di distribuzione come parametro? Non voglio dover riconfigurare questi lavori per ogni build, che è l'unico modo che ho trovato fino ad ora.

Sul numero 2 - Esiste un tipo di plug-in o una strategia generalmente utilizzata per la protezione da distribuzioni di produzione nefaste? Mi rendo conto che questa domanda potrebbe essere strongmente basata sulla mia risposta alla domanda n. 1. L'avere un account separato appositamente per la produzione crea un modo efficace per proteggersi da questo?

    
posta Chris Maggiulli 15.09.2017 - 16:21
fonte

1 risposta

2

Ti suggerisco di passare a un sistema leggermente più complesso ma molto più flessibile. Fondamentalmente, ti consiglio di spostarti dai rami SVN collegati agli ambienti. Lo usammo per diversi anni e non abbiamo avuto problemi seri.

  • Se non ne hai già uno, installa un prodotto di repository come Nexus.
  • Scrivi i processi di distribuzione per Jenkins che distribuiscono una versione numerata a Nexus, ma non distribuire agli host DEV, UAT o PROD. Questo lavoro contrassegnerà tutti i file con il numero di versione e inserirà il file .war versione in Nexus. Supponendo che tu usi Maven o Gradle come strumento di costruzione, questa è una funzionalità fuori dal comune per Jenkins.
  • Scrivi i lavori di distribuzione per Jenkins che richiedono all'utente un numero di versione e un host di destinazione. Questi sono semplicemente lavori che usano checkout SVN aumentati da script di bash che verranno eseguiti da Jenkins. Dovrai aggiungere alcuni plugin Jenkins per semplificarti la vita (ad es. Setenv per impostare le variabili visibili per l'intero lavoro)
  • Installa una seconda istanza di Jenkins per l'uso di DEVOPS. Questo ospiterà lavori che distribuiranno una particolare versione agli ambienti più alti. Questo è principalmente per la sicurezza se agli sviluppatori non è consentito effettuare distribuzioni in alcuni ambienti.
  • Il tuo uso di SVN cambierà. Abbiamo semplicemente utilizzato il trunk per lo sviluppo e i rami per ogni versione distribuita. Hai solo bisogno di creare rami di versione su richiesta (ramo dal tag). Generalmente creerai anche un ramo occasionale per provare una nuova funzionalità.
  • Crea una lavagna bianca in una posizione prominente che elenchi le versioni attualmente presenti in ciascun ambiente.

Quindi cosa ti darà questo?

  • Non è necessario eseguire l'unione dei codici quando ci si sposta tra gli ambienti, poiché i rami non sono più collegati agli ambienti.
  • Puoi rapidamente regredire qualsiasi ambiente a una versione diversa. Questo è ottimo per inseguire bug oscuri.
  • Insistere che i rapporti sui difetti includano il numero di versione. Ciò fornisce una buona tracciabilità di quando il difetto è stato rilevato dal pugno.

Ci sono alcuni ami da pesca.

  • Il tuo codice deve essere scritto in modo che lo stesso file .war possa essere eseguito in qualsiasi ambiente. Ciò significa che tutti i dati di configurazione devono essere memorizzati come variabili di ambiente e / o variabili JNDI. È inoltre possibile utilizzare i file di configurazione che sono controllati e messi in versione separatamente (in genere da DEVOPS). La posizione effettiva di questi file sarà specificata da un ambiente o variabile JNDI.
  • Sarà necessario impostare l'attendibilità basata su certificato tra Jenkins e le macchine di distribuzione di destinazione. Ciò è necessario per poter utilizzare SSH per spostare i file negli host di destinazione ed eseguire i comandi sull'host di destinazione. SSH non supporta l'autenticazione nome utente / password da uno script.

Mi rendo conto che potrebbe essere un bel cambiamento per la tua squadra, quindi buona fortuna!

    
risposta data 16.09.2017 - 00:43
fonte

Leggi altre domande sui tag

Animazioni e Reazione - è una cattiva pratica mescolarle? Quali sono le tecniche per eseguire i test di accettazione in un'app cloud senza inquinare l'ambiente con i dati di test?