Dopo aver illustrato i vantaggi di un repository maven aziendale, veniamo ora alla sua gestione e configurazione ottimale.

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

In questo articolo useremo come riferimento Artifactory di Jfrog, ma tutte le attività svolte possono essere comunque applicate a qualsiasi altra soluzione semi-free come Nexus o Archiva. (vedi articolo precedente per il confronto tra questi tools)

Visto che vorrei concentrarmi sugli argomenti di gestione, demanderemo i passaggi per l’installazione base alla guida ufficiale, vi consiglio se possibile di appoggiarvi alla installazione a pacchetti RPM o analoghi per facilitare successivi aggiornamenti e di installare un apache di frontend per gestire meglio l’accesso al server.

Una volta installato il server, colleghiamoci via web come amministratori e iniziamo a configurare il nostro repository remoto.

Il primo passo consiste nel creare i nostri repository locali.
Parlo al plurale perchè il mio consiglio è di crearne almeno tre:

• mycompany-releases : questo repo conterrà tutte le versioni stabili dei vostri progetti, come vedremo più avanti solo i tool di build automatica dovrebbero poter uploadare artefatti su questo repository, nessun intervento manuale dovrebbe essere consentito, in modo da garantire la totale riproducibilità di quanto disponibile.
• mycompany-snapshots: questo repository è la controparte di sviluppo del precedente. Qui verranno ospitate solo le versioni SNAPSHOT ancora in sviluppo, e in quanto tali, su questo repository può essere consentito l’upload direttamente da parte dei team in modo da agevolare lo sharing di librerie all’interno dei progetti.
• mycompany-thirdpaties: questo terzo repository conterrà tutte le librerie terze parti che dovrete caricare manualmente per renderle disponibile a maven. Una problematica comune è infatti l’assenza di alcune librerie sui repository maven pubblici: in questo caso per rendere l’artifact disponibile all’interno del processo di build, non si può fare a meno si effettuare un caricamento manuale. Ovviamente avendo un repository aziendale non lo faremo sulla nostra installazione locale ma su quella sharata in modo da rendere la libreria disponibile globalmente. Il vantaggio di utilizzare un repository a parte sta nel rendere più semplice individuare e organizzare queste librerie, in modo da poterle facilmente rimuovere una volta disponibili su repository maven
  Attenzione: un errore comune è abusare di questo repository per pigrizia, caricando qualsiasi libreria terze parti sia necessaria al team.
  Ricordatevi sempre che qualsiasi libreria caricata a mano necessiterà di manutenzione e di nuovi upload al rilascio di nuove versioni. Molto meglio perdere un paio d’ore a ricercare su internet un repository maven che esponga quanto ci serve (e le sue future versioni) e aggiungerlo come repository remoto, piuttosto che fare un upload frettoloso e sobbarcarsi la sua manutenzione nei mesi a venire.

Per impostare la gestione di snapshot piuttosto che release configurate opportunamente le opzioni del repository locale impostando handle release piuttosto che handle snaphots a seconda dei casi. Per il third parties potete anche consentire entrambe le opzioni visto che comunque sarete voi a caricare quello che serve manualmente.

Una volta configurati i repository locali possiamo aggiungere a piacere i repository remoti, per i quali il nostro repository aziendale farà da proxy. Tutti i più noti repository sono già presenti nell’installazione base, ma come anticipavo prima, l’aggiunta di repository remoti è una pratica comune per rendere disponibili ulteriori librerie terze parti che non vogliamo caricare manualmente sul nostro repository.

Il comportamento di base di artifactory sarà quello di richiedere l’artifact al repository remoto, memorizzarlo localmente e inoltrare l’oggetto scaricato al client che lo ha richiesto. Se avete problemi di spazio e non volete che l’artifact venga memorizzato sul vostro server, ma richiesto ogni volta (ricordatevi che comunque verrà cacheato anche sul repository locale del client richiedente) vi basta abilitare l’opzione Do not Store Artifacts Locally

Ora che abbiamo completato la configurazione dei repository, passiamo alla configurazione delle utenze.

Innanzitutto analizziamo cosa vogliamo ottenere:

• Qualsiasi utente collegato deve poter navigare il repository in sola lettura, manualmente o tramite search. Si suppone che il repository non sia pubblico ma accessibile solo in intranet, in caso contrario una simile utenza è sconsigliata per motivi di sicurezza.
• Gli sviluppatori devono poter caricare il loro lavoro solo in versione snapshot, ma non devono poter caricare o sovrascrivere gli artifacts una volta in versione release.
• Viceversa il nostro strumento di build automation deve essere in grado di deployare sia stabili che snapshot indifferentemente.
• Infine ci server un amministratore che possa gestire l’upload di artifact terze parti (nel nostro caso supporremo che sia anche l’amministratore di artifactory)

Per il primo punto la questione è abbastanza semplice, in quanto l’utente anonymous è già disponibile all’interno del sistema.

Per quanto riguarda gli sviluppatori potreste prendere in considerazione la reazione di account personali: sia Artifactory che Nexus si possono infatti interfacciare ad una directory LDAP anche se la versione free non consente di gestire i gruppi, rendendo il tutto più oneroso a livello di maintainance (senza gruppi dovrete assegnare i permessi ai singoli utenti).
Sinceramente, a meno che non abbiate esigenze di audit puntuale su chi carica i diversi artefatti, un’unica utenza di sviluppo comune a tutto il team è più che sufficiente ad ottenere l’effetto desiderato, quindi creeremo un singolo utente developer.

Al nostro tool di build automation riserveremo invece un account dedicato, in questo caso per non essere troppo originali lo chiameremo col nome del tool stesso: bamboo

Creiamo anche alcuni gruppi per raggruppare i permessi. Visto l’esiguo numero di utenti non sarebbe davvero necessario, ma cerchiamo sempre di ragionare con un occhio al futuro: assegnare i permessi sui gruppi è nettamente più veloce e flessibile che doverlo fare sulle singole utenze.
Creiamo quindi un gruppo per gli utenti che possono accedere in sola lettura (readers) e uno per chi avrà i privilegi per uploadare artefatti snaphsots (devel).
Visto che invece l’unico a uploadare su releases sarà sempre e solo bamboo, possiamo fare a meno di creare un gruppo anche per lui.

Ora che abbiamo gli utenti e i gruppi che ci servono, passiamo a creare e assegnare i permessi per realizzare quello che ci serve:

Come potete vedere abbiamo creato un set di permessi per ciascun repository, piu uno globale che comprende tutti i repository remoti.

Ora leghiamo i permessi ai gruppi e ai singoli utenti: assegneremo il permesso di deploy su release e snapshot puntualmente all’utente applicativo, mentre per gli altri due permessi ci appoggeremo ai gruppi per un eventuale ampliamento delle utenze in futuro:

Una volta ripetuta la stessa operazione sui diversi target avremo completato anche la configurazione dei permessi e il nostro repository è pronto per essere utilizzato.

Nel prossimo post vedremo infine come configurare le impostazioni di maven da distribuire agli sviluppatori, da caricare sulla macchina di build automation e da applicare all’interno dei progetti che vogliamo deployare.

A presto!