Artifact revolution: la rivoluzione del processo di build

Come il processo di build automation ha trasformato il deploy delle librerie e dei package

L’evoluzione degli strumenti di build automation ha reso molto più facile gestire in maniera strutturata il processo di build e release. Per chi aveva la fortuna di lavorare in progetti grandi, su clienti importanti, queste metodologie sono lo standard da molti anni. Il punto è che, fino ad oggi, la complessità del setup degli strumenti e il loro costo limitavano l’impiego in progetti più piccolo. Oggi, con l’avvento di strumenti SaaS come visualstudio online o gitlab si riesce ad avere tutto il necessario al solo costo del repository di codice sorgente. Permettetemi quindi di parlare di artifact repository anche se, in realtà, stiamo soltanto impiegando i risultati degli ultimi anni di sviluppo tecnologico!

Poniamo l’attenzione sugli artefatti,  un aspetto che spesso è trascurato, soprattutto per colpa di questi nuovi e potentissimi strumenti che con la loro automazione nascondono le complessità di processo.

In principio era la pubblicazione

A lavoro finito lo sviluppatore pubblica in produzione, generando sul proprio pc locare i file che servono. In alcuni casi deve ricordarsi di modificare qualche file, tipo quello di properties o di cancellare dei file da non sovrascrivere. Quando lo sviluppatore è particolarmente lungimirante pubblica prima in test e poi in produzione. Facendo due passaggi distinti, il rischio di sbagliare a  fare la pubblicazione in produzione e quindi rompere qualcosa a fronte di un test andato bene è concreto.

Esempio di Deploy fatto alla "vecchia maniera"

Esempio di deploy fatto male: dal pc alla produzione senza passare per CI

Problemi:

  • replicabilità : ogni volta che fai il processo puoi fare cose diverse (che magari solo tu sai)
  • dipendenza dall’ambiente dello specifico sviluppatore “preposto” alla pubblicazione : forse col computer di un altro qualcosa non funziona!
  • operazione manuale =>
    • possibilità di errore,
    • arriva domani mattina presto al lavoro per pubblicare quando il cliente non  usa l’applicativo
    • mi raccomando non ti ammalare… e se hai un incidente cerca di salvare le mani

 

Poi è arrivata la CI \ CD

Grazie agli strumenti sopra citati abbiamo automatizzato buona parte del processo e (in molti casi…) imposto un processo di lavoro.

Miglioramenti:

  • possibilità di automazione
  • replicabilità del processo
  • indipendenza dall’ambiente in cui si fa build

Benefici:

  • il programmatore non deve fare niente, quindi non sbaglia
  • il programmatore la mattina presto può starsene sotto le coperte, tanto l’operazione pianificata di release procede da sola, senza errori umani.
  • se il programmatore rovescia una tazza di caffè sul pc e lo rompe le pubblicazioni si fanno lo stesso
  • il programmatore può anche rompersi le mani, il mondo andrà avanti lo stesso (basta che committi prima pero! 🙂 )

WOW!

Artifact : definizione

Proviamo a dare una definizione fantozziana del termine.

Dicesi artifact qualunque output del processo di build. 

 

Gli artifact e il processo di CI\CD

 

Processo di Generazione dell'Artifact

Come si genera l’artefatto a a partire dal codice sorgente

 

Il processo di CI compila automaticamente ad ogni commit e produce artifatti.

Il processo di release prende gli artifact così prodotti e li deploya nel posto giusto, avevendo cura di attualizzare alcune parti che dipendono dall’ambiente (per evitare di moltiplicare il numero di artefatti prodotti) (CD) (esempio: cambio parametri di connessione al db in base all’ambiente). Per vari motivi potremmo volere che il processo di deploy non sia automatico (o che lo sia solo in determinati ambienti). Es. “tu pubblica domani mattina alle 7.00” => separazione del processo di build da quello di release.

Ecco la soluzione!

Build automation: poi abbiamo capito che il problema era più ampio

Il focus principale era sul rilascio dell’applicazione sul server di destinazione. Però ci sono anche altri elementi che fanno parte del “rilascio”. Pensiamo alle librerie di progetto e le librerie comuni tra progetti. Queste dove vanno a finire? Per estensione devono seguire la stessa logica: produzione di artefatto ad ogni build e realease per “deployarle”. Dove vanno deployati?

Artifact:  la soluzione è dentro di noi!

Ogni “piattaforma” ha il suo artifact manager e il suo artifact repository ( e anche un differente concetto di artifact…)

 

Piattaforma Artifact Manager Repository
.net .dll Nuget.exe

Nuget Manager (VS)

nuget.com
java jar maven (mvn command)

IDE (wrap mvn)

maven central
php il codice sorgente… composer packagist
js il codice sorgente npm client npm
python il codice sorgente pip ?

 

La soluzione

Pubblicare le nostre librerie sui repository pubblici!

Vantaggi:

 

  • No costi
  • Visibilità ( i clienti e le aziende scoprono quanto siamo fichi!)
  • Tutto già pronto
  • possibilità di creare “prodotti” dietro una libreria (community e maintainers)

 

Però:

  • siamo sicuri che vogliamo condividere con il mondo la libreria che contiene l’algoritmo che mi farà vincere il premio nobel? I lavori ad altro contenuto intellettivo \ proprietari non possono essere resi pubblici!
  • siamo sicuri di voler condividere col mondo la mia libreria super innovativa che funziona solo se chi la chiama ha invertito l’ago con il pagliaio e applicato quattro walk-around per evitare che si squagli la cpu? Non sempre i nostri lavori sono così maturi da essere diffondibili

 

Svantaggi:

  • Visibilità == possibilità di fare bella figura ma anche di fare figure…. meno belle!
  • creare prodotti dietro librerie => senza un investimento serio è difficile, per fare cose belle ci vuole tempo e denaro. Orma il mercato è “saturo” ed è difficile fare qualcosa che non ci sia  già. Rimangono solo spiragli in applicazioni di nicchia (= poco interesse, pochi supporters)
  • Rischio di perdita di valore intellettuale \ vantaggio competitivo

 

La soluzione per le aziende

Utilizzare repository privati. Installando presso le nostre strutture repository privati possiamo beneficiare dei vantaggi del repository, decidendo cosa vale la pena mettere dentro o fuori.

Piattaforma Repository privato
.net nuget privato \ nexus
java Artifactory \ nexus
php packagist (Saas), oppure giocare con i raw repository di nexus
js Artifactory \ nexus

 

Nexus => free su onpremise, supporta: docker, .net, java, npm, raw repository (zip). Rimane fuori solo il povero PHP (che cambia l’ago col pagliaio) …

Riassumendo

  • La CI\CD è essenziale per creare processi che funzionano (bene)
  • Se vogliamo gestire librerie comuni dobbiamo passare per un artifact repository
  • Se abbiamo materiale che vogliamo divulgare possiamo usare repository pubblici
  • Se abbiamo materiale che è bene rimanga interno dobbiamo installare un repository privato  on-premise (ad esempio nexus) oppure acquistare servizi Saas.
danielefontani

Actually CTO in Sintra Consulting s.r.l, I'm senior developer and architect specialized on portals, intranets, and others business applications. Particularly interested in Agile developing and open source projects, I worked on some of this as project manager and developer. My experience include: Frameworks \Technlogies: .NET Framework (C# & VB), ASP.NET, Java, php, Spring Client languages: XML, HTML, CSS, JavaScript, Angular.js,Angular. jQuery Platforms: Sharepoint,Liferay, Drupal Databases: MSSQL, ORACLE, MYSQL, Postgres