Posts Tagged ‘deploy’

Develop & Deploy SNAPSHOTS, Release Deliverables

januari 15, 2010

De meeste maven-gebruikers kennen ondertussen de ‘default-lifecycle’-phases wel. Termen als ‘compile’, ‘test’ en ‘install’ kunnen de meeste maven-gebruikers wel dromen. Maar daarmee eindigt de defaul-lifecycle niet, er is namelijk ook nog een deploy-phase. Daar waar install ervoor zorgt dat het package-resultaat in je locale repository terecht komt, zal deploy deze naar een externe repository uploaden (bijvoorbeeld een nexus-applicatie in het netwerk). Vanaf dat moment kunnen andere ontwikkelaars er ook gebruik van maken zonder zelf steeds de broncode te updaten en te installeren op eigen machines.
Tot op een gegeven moment alles klaar is voor een officiele release. Hoe zorg je ervoor dat de codebase en/of deliverable van een specifieke release ook later nog te achterhalen is? Hoe voorkom je menselijke fouten? Hoe verzeker je, dat elke releasemechanisme gelijk verloopt ongeacht de uitvoerende ontwikkelaar? O ja, en wie op de eerste vraag ‘inpakken+branden’ heeft geantwoord: klinkt als de enige en de zwakste schakel. Lees dat het ook anders kan!

Snapshots vs. Deliverables

Zoals de term ‘snapshot’ al suggereert is het een package op een zeker moment voordat de definitieve versie opgeleverd wordt. De myproject-1.0.0-SNAPSHOT van gisteren hoeft dus niet gelijk te zijn aan de myproject-1.0.0-SNAPSHOT van morgen. Dit in tegenstelling tot myproject-1.0.0, welke ook na 2012 nog steeds exact hetzelfde zal zijn. En dit is ook hoe Maven ermee omgaat. Bij het aanroepen van bijv. compile wordt eerst gekeken of er SNAPSHOT’s tussen de dependecies van het project staan. Zo ja, dan wordt gecontroleerd of hier nieuwe versies van beschikbaar zijn. Bij de niet-Snapshots gaat Maven ervan uit, dat controle niet nodig is.
Vandaar ook, dat je altijd ontwikkelt aan een Snapshot-versie! Anders zou je in theorie namelijk voor elke checkin een versieverhoging moeten doorvoeren in je pom. Want uiteraard blijven deze regels ook gelden binnen je subversion- of cvssysteem. Alles blijft draaien om reproduceerbaarheid, ongeacht welke revision je uitcheckt. Elke non-Snapshot versie mag maar 1 keer voorkomen (eigenlijk 2, namelijk onder trunk en tags). Om dit proces te ondersteunen kunnen we gebruik maken van de release-plugin.

Maven-release-plugin

De twee belangrijkste onderdelen van deze release-plugin zijn de prepare– en perform-goals. De prepare-goal zorgt voornamelijk voor de communicatie met het source control management systeem (cvs, svn, etc.), kortweg SCM. De perform-goal doet het daadwerkelijk deployen. Het is dus ook mogelijk om je project in ieder geval in je SCM definitief te maken, te labelen en te prepareren voor de volgende development fase, zonder het project ook te deployen!

release:prepare

Zoals al gezegd gaan we hiermee het project inchecken, labelen en prepareren voor verdere ontwikkeling.
Het is hierbij niet noodzakelijk om van een specifieke buildmachine gebruik te maken, aangezien deze plugin ook nog een aantal controles uit zal voeren.
Laten we beginnen met de pom.xml, welke een klein beetje uitgebreid moet worden.
We nemen een scm-sectie op, met daarin minimaal de developmentConnection welke wijst naar de root van het project. Zie ook pom#SCM.
Verder hebben we scm-client nodig op het systeempad (svn.exe of cvs.exe onder Windows bijv.)
Om te controleren of we stappen vergeten zijn, kunnen we droog gaan oefenen:
mvn release:prepare -DdryRun=true
Er zullen 3 vragen gesteld worden, elk met een te verwachten antwoord zodat je slechts hoeft te ‘enteren’. Vervolgens worden de volgende stappen uitgevoerd:

  • Controleer, dat er geen oningecheckte bestanden zijn
  • Controleer, dat er geen SNAPSHOT afhankelijkheden zijn
  • Wijzig de versie in de pom van x-SNAPSHOT naar een nieuw versienummer (resultaat van eerste vraag)
  • Wijzig de SCM informatie in de pom door het toevoegen van het doel van de ‘tag’.
  • Voer de tests uit om te bevestigen dat ze ook nog werken met de gewijzigde pom
  • checkin de gewijzigde pom
  • Label de code in de SCM met de versiewaarde (resultaat van tweede vraag)
  • Wijzig de versie in de pom naar een volgende SNAPSHOT (resultaat van derde vraag)
  • checkin de gewijzigde pom

Als de dryRun goed is doorlopen, kun je een echte release:prepare uitvoeren. Je zult dan ook meteen merken of alle instellingen kloppen. Daarnaast moeten ook de gebruikersnaam en wachtwoord bekend zijn. In sommige gevallen zijn deze al op je systeem bekend door eerdere checkins, maar je kunt deze gegevens ook meegeven met -Dusername= -Dpassword=. Er zijn nog een aantal andere opties, maar die zijn vaak OS en SCM-client specifiek.
Tot slot over de prepare-goal. Er wordt een bestand aangemaakt, welke bij houdt hoe ver je de prepare-phase doorlopen hebt, mocht het onverhoopt toch niet in één keer lukken. Klopt er iets in de pom.xml niet, zet de gegevens weer terug (x-SNAPSHOT versie) check dit in, waarna je eerst eventueel eerst een release:clean uitvoert zodat je weer vanaf het begin kunt starten.

release:perform

Deze goal voert standaard zowel een deploy uit van de deliverable als een deploy-site van de bijbehorende versie (de online documentatie).
Uiteraard kun je zelf aangeven, of je inderdaad dit default gedrag wilt hebben of dat je bijvoorbeeld liever alleen een deploy doet (zie perform-mojo.html#goals).
Voor een release:perform wordt trouwens eerst de code uitgecheckt op basis van de tag. Op basis van deze bestanden wordt de deployment uitgevoerd.

Conclusie

Maak dankbaar gebruik van deze plugin, gebaseerd op de best practices omtrent release- en deploymanagement.
De titel zegt het eigenlijk al:

  • Ontwikkel altijd aan SNAPSHOT-versies
  • Voor het verplaatsen van een SNAPSHOT naar een externe repository, voer mvn deploy uit
  • Voor het veilig stellen van een versie in SCM, gebruik mvn release:prepare.
  • Voor het opleveren van een deliverable via een externe repository, voer mvn release:perform uit.