Omgaan met Maven-afhankelijkheden bij de overstap naar Git

Al onze builds gaan naar Artifactory. Met SVN hadden we een repository voor snapshots gebruikt voor het bewaren van de laatste 2 snapshot-builds, van een stagingopslagplaats voor alle release-builds die nog niet zijn goedgekeurd, en van een releaserepository alleen voor de builds die klaar waren om in productie te gaan.[1] Deze builds zijn genummerd, zoals ik eerder heb beschreven, en zijn terug te vinden aan de hand van een voorspelbaar URL-patroon op basis van repository en versie.

De primaire workflow voor elke ontwikkelaar was om vanuit de develop-branch een feature-branch voor hun werk te creëren, deze te voltooien en een pull-aanvraag in te dienen om dat werk terug samen te voegen in de develop-branche. Voor één project werkt dit meestal zonder problemen, maar laat me je een beeld schetsen van het eerste probleem dat we tegenkwamen, en een probleem waarbij we de hele migratie serieus opnieuw moesten overwegen:

Zoals ik al eerder zei, zijn er meerdere afhankelijkheidslagen tussen onze projecten. Daar is voor onze producten een heel goede reden voor, zowel historisch als strategisch gezien. We hebben alternatieve architecturen overwogen om dit probleem op te lossen, maar ze zouden andere architecturen introduceren. We kunnen het ons makkelijker maken (en dat hebben we gedaan, maar dat is voor een latere post), maar op dit moment is het voor ons van strategisch belang om onze structuur te behouden zoals deze is.

Dus ontwikkelaar A, laten we haar Angela noemen, begint te werken aan een functie in Jira. Hiervoor zijn twee branches nodig: een van ons gemeenschappelijke project en een van product X. De versie voor het gemeenschappelijke project is 2.1.0-SNAPSHOT. De versie voor productX is 2.4.0-SNAPSHOT. Ze werkt een tijdje lokaal en pusht dan uiteindelijk terug naar Bitbucket Data Center. Bamboo pikt deze wijzigingen op, stelt het gemeenschappelijke pakket samen en uploadt common-2.1.0-SNAPSHOT naar Artifactory, bouwt vervolgens productX met een afhankelijkheid van common-2.1.0-SNAPSHOT en uploadt ook productX-2.4.0-SNAPSHOT. De unittests zijn geslaagd!

Ontwikkelaar B, laten we hem Bruce noemen, begint te werken aan een andere functie in Jira, voor een ander product: productY. Ook hiervoor zijn twee branches nodig: een van ons gemeenschappelijke project en een van productY. De versie voor het gemeenschappelijke project is 2.1.0-SNAPSHOT, zoals hiervoor. De versie van product Y is 2.7.0-SNAPSHOT. Hij werkt een tijdje lokaal en pusht dan uiteindelijk de wijzigingen naar Bitbucket Data Center. Bamboo pikt deze wijzigingen op, stelt het gemeenschappelijke pakket samen en uploadt common-2.1.0-SNAPSHOT naar Artifactory, bouwt vervolgens productX met een afhankelijkheid van common-2.1.0-SNAPSHOT en uploadt ook productX-2.4.0-SNAPSHOT. De unittests zijn geslaagd!

Angela vindt ondertussen een kleine bug in haar productX-code en schrijft een unittest om haar oplossing valideren. Ze voert deze lokaal uit en de test slaagt. Ze pusht haar wijzigingen naar Bitbucket en Bamboo, pakt de wijziging op en bouwt productX. De build is geslaagd, maar sommige van haar unittests zijn mislukt. Het zijn niet de nieuwe die ze schreef, maar de eerste van haar aanvankelijke wijzigingen in het functiebeheer. Op de een of andere manier heeft de Bamboo-build een regressie gevonden die haar lokale build niet heeft gevonden? Hoe kan dit?

Dat is omdat haar gemeenschappelijke afhankelijkheid (die Bamboo naar binnen pullde om productX te bouwen) niet langer haar exemplaar was. Bruce heeft common-2.1.0-SNAPSHOT overschreven in Artifactory toen zijn functiebuild voltooid was. Er was geen bronconflict: beide ontwikkelaars werkten geïsoleerd aan hun eigen branches, maar de bron van waarheid voor het ophalen van het Maven-artefact was beschadigd.

Kop. Ontmoet het bureau.

Ongeveer een maand nadat we dit probleem hadden ontdekt, hebben we alles geprobeerd om dit op te lossen. Via onze TAM[2] spraken we met mensen van het Bamboo-team die git-flow gebruiken, en we spraken met de ontwikkelaar die git-flow onderhoudt, een Java-implementatie van git-flow. Ze waren allemaal erg behulpzaam, maar bij gebrek aan een proces waarbij elke ontwikkelaar elke keer dat ze aan een functie werkten een lijst met handmatige stappen moest uitvoeren, konden we geen aanvaardbare oplossing vinden.

Als je benieuwd bent wat we hebben overwogen, is hier een overzicht van alles wat we geprobeerd hebben:

1. Wijzig het versienummer bij het aanmaken van de branch of onmiddellijk daarna.

• We kunnen dit doen met mvn jgitflow:feature-start om de branch aan te maken.
• We kunnen een Bitbucket Data Center-hook of een lokale githook gebruiken.
• We kunnen dit handmatig instellen met mvn-version:set-version nadat we de branch hebben aangemaakt.
• We kunnen de wijziging automatiseren met de plug-in [maven-external-version].

2. Pas het versienummer aan wanneer je klaar bent met de branch en deze weer samenvoegt om te ontwikkelen.

• We kunnen dit doen met mvn jgitflow:feature-finish om de branch te voltooien.
• Gebruik een git merge-driver om pom-conflicten af te handelen.
• Gebruik een asynchrone post-receive hook in Bitbucket Data Center

3. Doe alles handmatig. (Grapje! We hebben deze optie niet heel lang overwogen.)

Door dit kernconcept te onthouden en erover na te denken, kun je begrijpen dat die submodule sommige workflows goed ondersteunt en andere minder optimaal. Er zijn minstens drie scenario's waarin submodules een redelijke keuze zijn:

• Als een component of subproject te snel verandert of als er komende wijzigingen de API defect maken, kun je voor je eigen veiligheid de code aan een specifieke commit vastkoppelen.

• Als je een component hebt die niet vaak wordt bijgewerkt en je dit wilt bijhouden als leveranciersafhankelijkheid. Ik doe dit bijvoorbeeld voor mijn vim-plug-ins.

• Wanneer je een deel van het project delegeert aan een externe partij en je hun werk op een bepaald moment of in een specifieke release wilt integreren. Nogmaals, dit werkt als er niet te vaak updates zijn.

Met dank aan Finch voor de goed toegelichte scenario's.

Elk van deze opties had een soort van negatieve bijwerking. Vooral de handmatige stappen voor ontwikkelaars, telkens wanneer ze een feature-branch nodig hadden. En we wilden dat ze voortdurend feature-branches zouden aanmaken. In de meeste gevallen konden we ook niet effectief gebruik maken van pull-aanvragen, wat een spelbreaker was.

Dit heeft 1-2 mensen bijna twee maanden lang beziggehouden, totdat we het (verbijsterende) inzicht kregen dat we dit probleem vanuit de verkeerde richting benaderden.

Achteraf bezien snap ik dat onze grootste fout was dat we onze aandacht richtten op de git-flow-tools in plaats van de tools te gebruiken die we al hadden om de workflow te implementeren die we wilden. We hadden:

• Jira
• Bamboo Data Center
• Maven
• Artifactory Pro

Het bleek dat dat alle tools waren die we nodig hadden.

Een van onze ingenieurs kreeg het zeer briljante idee dat, aangezien het probleem niet aan het buildbeheer zelf lag, maar aan de overschreven artefacten, dat we in plaats daarvan Artifactory moesten repareren. Zijn idee was om een eigenschap van Maven te gebruiken om de URL van de snapshot-repository in te stellen op een aangepaste URL met de Jira-issue-ID, en vervolgens de artefacten te schrijven naar een dynamisch aangemaakte repository in Artifactory met een aangepast sjabloon. De afhankelijkheidsoplosser van Maven zal artefacten vinden in de repository voor ontwikkelingssnapshots vals we ze niet hoeven te branchen, bijvoorbeeld als we alleen aan een product werken en niet ook aan een gemeenschappelijk product.

We hebben die handige kleine eigenschapsvariabele in ons bestand met build-instellingen gezet en een Maven-plug-in geschreven om die te vullen tijdens het eerste deel van de buildcyclus van Maven. Op papier klonk dit ongelooflijk en het gaf het team een nieuwe impuls om harder te werken om dit probleem op te lossen. Het probleem was dat we dit eigenlijk niet konden doen. De vroegste fase van de levenscyclus van Maven is 'valideren'. Tegen de tijd dat de te valideren plug-ins al beschikbaar waren, waren de URL's van de repository al afgesloten. Daarom werd onze variabele nooit ingevuld en heeft de URL helemaal geen branchnaam. Hoewel we een lay-out hadden gebruikt in een andere repository dan de ontwikkelingssnapshots, zou die niet op zichzelf staan voor parallelle ontwikkeling.

Terug naar het bureau, je BESTE VRIEND.

Na een biertje deed de eerdergenoemde ingenieur nog wat diepgravend zoekwerk naar een andere manier om functionaliteit aan Maven toe te voegen: extensies.

„Leve het bier: de oorzaak van en oplossing voor alle problemen in het leven.” - Homer Simpson

Extensies bieden je, net als plug-ins, een hele reeks mogelijkheden om je Maven-workflow te verbeteren, maar ze worden uitgevoerd vóór de levenscyclusdoelen en hebben een betere toegang tot de interne functies van Maven. Door het pakket RepositoryUtils te gebruiken, hebben we Maven gedwongen de URL's opnieuw te evalueren met behulp van een aangepaste parser en ze vervolgens opnieuw in te stellen op basis van onze bijgewerkte waarden.[3]

Nadat we de extensie hadden ingevoerd en getest, begonnen we de ene na de andere premigratietaak uit te voeren, variërend van 'dit gaat nooit gebeuren' tot 'dit gaan we maandag ZEKER doen... dus moet ik uiterlijk morgen tien pagina's aan documentatie schrijven'. Ik zal binnenkort meer schrijven over hoe de tools samenwerken om onze nieuwe ontwikkelingsworkflow te realiseren, en meer vertellen over enkele van de lessen die we over het proces hebben geleerd.