Gestire le dipendenze di Maven durante il passaggio a Git

Tutte le nostre build sono salvate in Artifactory. Con SVN, utilizzavamo un repository di istantanee per conservare le ultime 2 build di snapshot, un archivio di staging per tutte le build di rilascio non ancora approvate e un repository di rilascio solo per le build che avevano la fortuna di essere messe in produzione. [1] Queste build sono numerate come ho descritto in precedenza e sono recuperabili mediante uno schema URL prevedibile basato sul repository e sulla versione.

Il flusso di lavoro principale per ogni sviluppatore consisteva nel creare un branch di funzionalità dal branch di sviluppo per il proprio lavoro, completarlo ed effettuare una pull request per riunire nuovamente tale lavoro nel branch di sviluppo. Per un singolo progetto, questo funziona per lo più senza problemi, ma vorrei illustrare il primo problema che abbiamo incontrato e che ci ha fatto riconsiderare seriamente l'intera migrazione:

Come ho detto prima, abbiamo più livelli di dipendenza tra i nostri progetti. Questo è dovuto a un ottimo motivo, sia storicamente che strategicamente, per i nostri prodotti. Abbiamo preso in considerazione architetture alternative per eliminare questo problema, ma queste introdurrebbero altre difficoltà. Possiamo semplificarci la vita (e l'abbiamo fatto, ma ne parleremo in un post successivo), ma per ora è di importanza strategica per noi mantenere la nostra struttura così com'è.

La sviluppatrice A, chiamiamola Angela, inizia a lavorare su una funzione di Jira. Ciò richiede due branch: uno dal nostro progetto comune e uno dal prodottoX. La versione del progetto comune è 2.1.0-SNAPSHOT. La versione del prodottoX è 2.4.0-SNAPSHOT. Angela lavora a livello locale per un po' e infine esegue il backup su Bitbucket Data Center. Bamboo raccoglie le modifiche, crea il pacchetto comune e carica common-2.1.0-SNAPSHOT in Artifactory, quindi crea il prodottoX con una dipendenza da common-2.1.0-SNAPSHOT, caricando anche prodottoX-2.4.0-SNAPSHOT. I test unitari vengono superati!

Lo sviluppatore B, chiamiamolo Bruce, inizia a lavorare su un'altra funzione di Jira, per un prodotto diverso: prodottoY. Anche questo richiede due branch: uno del nostro progetto comune e uno di prodottoY. La versione del progetto comune è, come prima, 2.1.0-SNAPSHOT. La versione del prodottoY è 2.7.0-SNAPSHOT. Bruce lavora a livello locale per un po' e infine salva le sue modifiche su Bitbucket Data Center. Bamboo raccoglie le modifiche, crea il pacchetto comune e carica common-2.1.0-SNAPSHOT in Artifactory, quindi crea il prodottoX con una dipendenza da common-2.1.0-SNAPSHOT, caricando anche prodottoX-2.4.0-SNAPSHOT. I test unitari vengono superati!

Angela, nel frattempo, trova un piccolo bug nel codice di prodottoX e scrive un unit test per convalidare la sua correzione. Lo gestisce a livello locale e il test ha esito positivo. Passa le sue modifiche a Bitbucket e Bamboo raccoglie le modifiche e crea prodottoX. La build ha successo, ma alcuni unit test hanno esito negativo. Non si tratta dei nuovi test appena compilati, ma dei primi, tratti dalle sue modifiche iniziali alla funzione. In qualche modo la build Bamboo ha trovato una regressione non rilevata dalla sua build locale? Come è possibile?

La sua dipendenza comune, quella che Bamboo ha rilevato quando ha creato prodottoX, non era più la sua copia. Bruce ha sovrascritto common-2.1.0-SNAPSHOT in Artifactory quando la build della sua funzionalità è stata completata. Non c'è stato conflitto con il codice sorgente: entrambi gli sviluppatori lavoravano isolatamente sui propri branch, ma la fonte della verità per il recupero degli artefatti di Maven era danneggiata.

Head. Incontro con i tecnici.

Per circa un mese dopo aver scoperto questo problema, abbiamo fatto di tutto per aggirarlo. Tramite il nostro TAM[2], abbiamo parlato con persone del team Bamboo che usano git-flow e abbiamo parlato con lo sviluppatore che gestisce git-flow, un'implementazione java di git-flow. Sono stati tutti molto utili, ma, a eccezione di un processo che richiedeva un elenco di passaggi manuali per ogni sviluppatore ogni volta che lavorava su una funzionalità, non siamo riusciti a trovare una risoluzione tollerabile.

Se sei curioso di sapere cosa abbiamo considerato, ecco tutto ciò che abbiamo provato:

1. Modifica del numero di versione al momento della creazione del branch o subito dopo.

• Possiamo farlo con mvn jgitflow:feature-start per creare il branch.
• Possiamo utilizzare un hook di Bitbucket Data Center o un githook locale.
• Possiamo eseguire l'impostazione manuale con mvn version:set-version dopo aver creato il branch.
• Possiamo automatizzare la modifica con il plugin [maven-version esterna].

2. Modificare il numero di versione quando si completa il branch ed eseguire nuovamente la fusione per svilupparlo.

• Possiamo farlo con mvn jgitflow:feature-finish per completare il branch.
• Usare un driver git merge per gestire i conflitti pom.
• Utilizza un hook post-ricezione asincrono in Bitbucket Data Center.

3. Fare tutto manualmente. (ovviamente non abbiamo considerato questa opzione molto a lungo).

Tenendo a mente questo concetto fondamentale e riflettendoci sopra, puoi comprendere che i sottomoduli (submodule) supportano bene alcuni flussi di lavoro e altri in modo meno ottimale. Esistono almeno tre scenari in cui i sottomoduli rappresentano una scelta corretta:

• Quando un componente o un sottoprogetto cambia troppo velocemente o le modifiche imminenti interromperanno l'API, puoi bloccare il codice su un commit specifico per ragioni di sicurezza.

• Quando c'è un componente che non viene aggiornato molto spesso e che desideri monitorare come dipendenza del fornitore. Io procedo così per i plugin vim, ad esempio.

• Quando deleghi una porzione del progetto a una terza parte e desideri integrare il suo lavoro in un momento o in un rilascio specifico. Ripeto: questo procedimento funziona quando gli aggiornamenti non sono troppo frequenti.

Ringrazio finch per le ottime spiegazioni degli scenari.

Ognuna di queste opzioni aveva una sorta di effetto collaterale negativo. Principalmente, si trattava di passaggi manuali per uno sviluppatore ogni volta che aveva bisogno di un branch di funzionalità. E volevamo che gli sviluppatori creassero continuamente branch di funzionalità. Inoltre, nella maggior parte dei casi non siamo riusciti a utilizzare efficacemente le pull request, il che è stato un problema.

Tutto questo ha divorato 1-2 persone per quasi due mesi fino a quando non abbiamo avuto una (strabiliante) rivelazione sul motivo per cui stavamo affrontando questo problema dalla direzione sbagliata.

Con il senno di poi, ora vedo chiaramente che il nostro errore più grande è stato quello di concentrare la nostra attenzione sugli strumenti git-flow piuttosto che utilizzare gli strumenti che avevamo già per implementare il flusso di lavoro che volevamo. Avevamo:

• Jira
• Bamboo Data Center
• Maven
• Artifactory Pro

A quanto pare, quelli erano tutti gli strumenti di cui avevamo bisogno.

Uno dei nostri ingegneri ha avuto la brillante idea che, poiché il problema non era la gestione della build in sé ma piuttosto la sovrascrittura degli artefatti, avremmo dovuto invece sistemare Artifactory. La sua idea era di utilizzare una proprietà Maven per impostare l'URL del repository di istantanee su un URL personalizzato che includesse l'ID del problema Jira, e poi scriverne gli artefatti in un repository creato dinamicamente in Artifactory con un modello personalizzato. Il risolutore di dipendenze di Maven troverà gli artefatti nel repository degli snapshot di sviluppo se non abbiamo avuto bisogno di ramificarli, ad esempio se stiamo lavorando solo su un prodotto che non è anche comune.

Abbiamo impostato quella piccola e utile variabile di proprietà nel nostro file delle impostazioni di build e abbiamo scritto un plugin Maven per popolarla durante la prima parte del ciclo di vita della build di Maven. Sulla carta, sembrava incredibile e ha spronato nuovamente il team a lavorare di più per risolvere questo problema. Il problema era che in realtà non potevamo farlo. La prima fase del ciclo di vita di Maven è la «convalida». Quando i plugin destinati alla convalida sono stati eseguiti, gli URL del repository erano già stati risolti. Per questo motivo, la nostra variabile non è mai stata compilata e l'URL non ha un nome di branch, dopotutto. Anche se avevamo utilizzato un layout in un repository separato dalle nostre istantanee di sviluppo, questo non sarebbe stato isolato per lo sviluppo parallelo.

Head. Nuovo incontro con il tecnico: il tuo MIGLIORE AMICO.

Dopo una birra, il suddetto ingegnere ha fatto ulteriori ricerche e ricerche su un altro modo per aggiungere funzionalità a Maven: le estensioni.

«Alla birra: la causa e la soluzione di tutti i problemi della vita». - Homer Simpson

Le estensioni, come i plugin, ti offrono tutta la potenza necessaria per migliorare il tuo flusso di lavoro Maven, tuttavia vengono eseguite prima degli obiettivi del ciclo di vita e hanno un maggiore accesso ai componenti interni di Maven. Utilizzando il pacchetto RepositoryUtils, abbiamo costretto Maven a rivalutare i suoi URL utilizzando un parser personalizzato e poi a reimpostarli utilizzando i nostri valori aggiornati. [3]

Estensione in atto e testata, abbiamo iniziato a interrompere le attività pre-migrazione una dopo l'altra, passando da "questo non succederà mai" a "questo accadrà lunedì... così ora devo scrivere dieci pagine di documentazione entro domani". A breve pubblicherò un articolo su come gli strumenti collaborano per realizzare il nostro nuovo flusso di lavoro di sviluppo e su alcune delle lezioni che abbiamo appreso sul processo.