Perché Jenkins sta diventando il motore dei devops

Tendenze come sviluppo agile, devops e integrazione continua parlano della necessità dell'azienda moderna di creare software in modo iper-efficiente e, se necessario, di accendere un centesimo.

Quest'ultima manovra è il modo in cui CloudBees è diventata l'azienda che è oggi. Un tempo fornitore indipendente di cloud pubblico PaaS per programmatori Java (valutato molto positivamente da Andrew Oliver in "Quale fottuto PaaS dovrei usare?"), 18 mesi fa CloudBees ha compiuto una svolta decisiva per rilanciare come fornitore leader di Jenkins, un open molto popolare strumento sorgente per la gestione del processo di sviluppo del software.

Secondo il CEO Sasha Labourey, come fornitore di Java PaaS CloudBees "stava crescendo bene", ma "molti dei ragazzi più grandi con i controlli più grandi" erano riluttanti a impegnarsi in un mercato PaaS volatile che mancava di standardizzazione. Allo stesso tempo, Jenkins stava decollando come un razzo e Labourey ha visto una grande opportunità, soprattutto perché CloudBees stava già offrendo Jenkins come servizio e aveva già assunto Kohsuke Kawaguchi, il creatore di Jenkins. Il contorno Jenkins è diventato il piatto principale.

Il colosso Jenkins

Cosa c'è dietro la popolarità di Jenkins? In poche parole, Jenkins è diventato lo standard open source per la gestione del lato sviluppatore dei devops, dalla gestione del codice sorgente alla consegna del codice alla produzione. Secondo Labourey, "La comunità vede Jenkins come un motore di orchestrazione e automazione ... Penso che il motivo per cui Jenkins è diventato il motore di fatto sia perché è estremamente collegabile". È emerso un ecosistema di oltre 1.100 plug-in, che consente ai clienti di aggiungere tutti i tipi di funzionalità e integrare Jenkins con qualsiasi cosa, da Active Directory a GitHub a OpenShift PaaS.

Jenkins è una soluzione di integrazione continua (CI) e distribuzione continua (CD). L'idea di CI è di fondere il codice dei singoli sviluppatori in un progetto più volte al giorno e di testarlo continuamente per evitare problemi a valle. CD fa un ulteriore passo avanti per garantire che tutto il codice unito sia sempre in uno stato pronto per la produzione. Jenkins consente agli sviluppatori di automatizzare questo processo il più possibile, fino al punto di distribuzione. Labourey fornisce un esempio:

Supponiamo che un'azienda stia utilizzando Chef o Puppet per la distribuzione su AWS. Jenkins non lo sostituirà. Jenkins chiamerà Puppet per farlo - OK, ecco i bit, quindi chiamiamo questo script Puppet e vediamo come funziona. E l'output dell'esecuzione di Puppet sarà importante per Jenkins perché potrebbe decidere di srotolare la distribuzione e intraprendere ulteriori azioni. Lo chiamiamo "il gasdotto". È davvero questa serie di passaggi. Potrebbero essere cinque passaggi o 50 passaggi.

Jenkins funge da motore del flusso di lavoro per gestire questa pipeline CI / CD dall'origine alla consegna, afferma Labourey, ma lungo il percorso potrebbero essere richiesti molti strumenti diversi per eseguire funzioni diverse.

Docker è uno di questi strumenti e Docker insieme a Jenkins sta avendo un profondo effetto sui team di sviluppo. Tutti sanno che Docker semplifica lo sviluppo e rende la distribuzione molto più semplice, ma Labourey osserva che aiuta anche a mantenere gli sviluppatori onesti: non possono più incolpare di errori di configurazione dell'ambiente di sviluppo quando una build si blocca e si brucia. Su una macchina fisica, l'ambiente di sviluppo viene gradualmente danneggiato, causando inavvertitamente l'interruzione delle build. Ma quando stai codificando su un'immagine Docker incontaminata, hai solo il tuo codice difettoso da incolpare quando le build non vengono eseguite.

Insieme, Jenkins e il suo ecosistema integrato forniscono l'infrastruttura software di coordinamento per lo sviluppo agile e, più in generale, costituiscono "il nucleo dell'iniziativa devops", afferma Labourey.

Arrivarci da qui

Tutta questa automazione e l'efficienza del devops suonano alla grande, ma che dire delle organizzazioni che hanno a malapena avvolto la testa attorno allo sviluppo agile? Labourey offre consigli per guadare in CI / CD:

Penso che il modo migliore per farlo sia iniziare in piccolo. Scegli un progetto. Non dire "OK, ora siamo un negozio di consegne continue, va tutto in questo modo". Inizia con un team disponibile, forse più flessibile di altri team, forse membri del team più recenti, meno radicati nel modo esistente di fare le cose. Scegli un progetto facile. Non cercare di usarlo come un modo per dire che se funziona, funzionerà tutto. Non provare a fallire; prova ad avere successo. Scegli una squadra disponibile, scegli un progetto facile, arrivaci. Questo team diventerà il tuo miglior venditore perché ora puoi dimostrare che funziona. Possono parlare di come il loro lavoro sia migliorato perché, francamente, la vecchia maniera è noiosa.

Parte del processo, osserva Labourey, è "estrarre la conoscenza che si trova tranquillamente nel cervello delle persone e metterla nella pipeline come logica". Non succede dall'oggi al domani. Spesso, le organizzazioni di sviluppo iniziano elaborando CI e si fanno strada nel tempo verso il CD.

Le organizzazioni di sviluppo tendono ad avere requisiti molto vari e altamente specifici. Quindi CloudBees offre sia una versione SaaS generica, basata su abbonamento, gestita da CloudBees, sia una versione "SaaS privata", che i clienti possono implementare su AWS o Azure (o localmente su OpenStack) e personalizzarla a proprio piacimento.

È difficile sopravvalutare l'importanza di orchestrare, automatizzare e snellire il processo di sviluppo. CI / CD è fondamentale per devops e un'implementazione di devops di successo ha a sua volta implicazioni che vanno oltre l'IT fino al business stesso. Il miglioramento continuo del software migliora continuamente prodotti e servizi. Tesla, ad esempio, ha avuto una grave battuta d'arresto con uno dei suoi modelli che ha preso fuoco e il lancio di un aggiornamento software ha risolto il problema dall'oggi al domani.

"È interessante se ottieni il 10% di efficienza in più; se spendi $ 100 milioni all'anno in IT, beh, benissimo: hai $ 10 milioni che puoi spendere altrove", afferma Labourey. "Ma il vero vantaggio è quando l'azienda si rende conto che sfruttando quegli strumenti e quel modo di fare le cose, possono aumentare le vendite del 10%".