Con questo articolo voglio finalmente addentrarmi nel mondo di Maven e della Build automation e voglio cominciare dall’introduzione di uno strumento fondamentale per qualunque team di sviluppo che voglia affrontare l’argomento in maniera professionale: approntare un repository remoto per gli artifact (e non solo).

Attenzione: questo articolo è disponibile anche in lingua inglese: qui.

Come tutti sappiamo Maven permette di automatizzare le generazione di librerie e altri pacchetti (jar, war, ear, zip etc..) genericamente definiti artifact.
Oltre alla semplice generazione del formato compilato, maven permette di memorizzare lo stesso in un repository locale, facendo sì che sia immediatamente disponibile a qualsiasi altra build effettuata sullo stessa macchina che lo richieda come dipendenza, diretta o transitiva.
Allo stesso modo qualsiasi altra dipendenza “terze parti” viene automaticamente ricercata dal processo di build, dapprima sul repository locale (qualora fosse già stata scaricata e cacheata) ed in seguito su tutti i repository remoti impostati nelle configurazioni (maven contiene di default il repository remoto maven central) o nel pom stesso.

In tutto questo quali possono essere i vantaggi della creazione di un nuovo repository remoto dedicato alle nostre build?

Ci sono diversi pro (e ovviamente anche qualche piccolo contro), cerchiamo di analizzarli uno per uno:

• Distribuzione degli artifact interni al team: fermandosi al livello di repository locale infatti non è possibile condividere le librerie prodotte col resto del team. Ciascun membro dovrebbe mantenere allineato il codice di tutte le librerie e premurarsi di buildare sempre l’intero set per assicurarsi di avere l’ultima versione sul suo repository locale.
  Salvo rare eccezioni, nessun repository remoto terze parti vi consentirebbe di uplodare il vostro codice per usi personali (e immagino che, a meno di progetti Open Source, pochissimi sarebbero disposti a renderlo pubblicamente disponibile su internet). Si rende pertanto necessario avere una propria installazione (di team o addirittura aziendale) su cui gli sviluppatori possano caricare i prodotti delle proprie build e dal quale possano recuperare il lavoro dei colleghi. In questo modo il ciascun sviluppatore può preoccuparsi solo del codice che gli compete, scaricando le dipendenze aggiuntive direttamente dal repository, senza piu perdere tempo a ribuildare tutto.
• Efficace distinzioni di artifact ancora in fase di sviluppo e di rilascio: permettendo la distinzione tra artefatti SNAPSHOT (ovvero ancora aperti allo sviluppo) e versioni “release” è immediatamente chiaro se l’artefatto che si sta utilizzando come dipendenza all’interno del proprio lavoro sia una versione stabile o ancora soggetta a modifiche da parte dell’autore. Inoltre le versioni stabili sono tipicamente inalterabili una volta caricate sul repository, quindi si ha anche la garanzia che il codice di una release non cambierà nel tempo, mentre nel caso delle snapshot si può richiedere all’owner di effettuale eventuali modifiche.
• Centralizzazione della gestione delle librerie: oltre a ospitare gli artefatti prodotti dai team di sviluppo, il nostro repository aziendali può infatti funzionare da proxy centralizzato per tutti i repository maven presenti su internet. Il vantaggio di questo approccio è che ogni “cliente” parla con un solo archivio globale, e non c’è il rischio che diversi elementi dei team facciano affidamento su repository differenti, o se ne aggiungano a loro volta altri, non disponibili al resto del gruppo, causando problemi di compatibilità e/o compilazione una volta che si condividono i progetti.
  Avendo invece un interlocutore unico (che si fa carico di interrogare a sua volta i repository remoti secondo una priorità ben definita) abbiamo la garanzia che gli artifact scaricati da ciascuno sviluppatore di ogni team saranno sempre gli stessi, senza possibilità di anomalie, in quanto ogni nuovo repository non potrà più essere aggiunto a livello individuale, ma andrà configurato sul repository aziendale e quindi immediatamente sharato a tutti.
• Come mi è stato suggerito da Richard Duncan su Linkedin, un altro grosso vantaggio per chi lavora nel mondo dell’open source è dato dal fatto che un repository aziendale permette anche di tener monitorata la tipologia delle librerie terze parti che si utilizzano nei propri progetti, evitando cosi di introdurre elementi non compliant con le policy aziendali (librerie con licenze non Open Souce, librerie considerate non sicure, etc.).
  Utilizzando il proprio repository come proxy verso altri repository esterni e sfruttando opportunamente i pattern di include/exclude è infatti possibile regolare ed eventualmente filtrare le librerie alle quali le build possono accedere, escludendo quelle indesiderate.

Tra i contro (c’è sempre un “contro”) c’è ovviamente l’elemento di single point of failure che state introducendo all’interno della vostra catena di build. Se il repository è unico ovviamente un suo eventuale disservizio bloccherebbe tutto il processo. Quindi fate molta attenzione al tipo di macchina che sceglierete per l’installazione in quanto dovrà sopportare il carico di tutte le richieste di artifact di tutti i vostri team e avere abbastanza spazio a disposizione per memorizzare diverse migliaia di librerie (ricordatevi che per ogni libreria ci saranno diverse versioni, siano esse SNAPSHOT o stabili)

Passiamo ora agli aspetti più pratici, quali sono i tool tra cui scegliere? Restando in ambito semi-gratuito ci sono tre alternative principali: Artifactory di Jfrog, Nexus di Sonatype (gli autori di Maven stesso) e Archiva di Apache, per un efficace confronto vi rimando a questa ottima matrice di comparazione

JFrog’s Artifactory

Sonatype’s Nexus

Apache’s Archiva

Archiva viene rilasciato sotto licenza (ovviamente) apache, mente Nexus e Artifactory hanno entrambi una versione free con funzionalità limitate (ma comunque più che sufficienti per i nostri scopi) affiancata da una versione pro a pagamento.

Personalmente ho avuto modo di lavorare con gli ultimi due e in entrambi i casi li ho trovati degli ottimi prodotti, quindi vi consiglierei di spulciare la matrice e scegliere in base alle vostre reali necessità.

Giusto per fare un esempio ho sempre optato per Artifactory per la semplice possibilità di mostrare direttamente da interfaccia web il codice sorgente contenuto negli artifact, funzionalità che in Nexus è riservata alla versione Pro, ma che ho trovato sempre utilissima per fare del troubleshooting in caso di dubbi su cosa fosse stato effettivamente rilasciato nel pacchetto.

Nexus per contro ha un grosso punto di forza nella gestione di numerosi repository, siano essi locali (ovvero installati su nexus stesso), remoti ( per i quali il repo agisce da proxy) o virtuali (ovvero una sorta di “vista aggregata” dei due precedenti da esporre come un unico repository).
La stessa funzionalità è ovviamente presente anche su Artifactory, ma l’interfaccia ExtJs/Sencha di Nexus rende l’amministrazione decisamente più semplice e intuitiva.

Con la teoria fermiamoci qui, nel prossimo post ci addentreremo negli aspetti pratici della configurazione e amministrazione utilizzando Artifactory come strumenti di riferimento.