Používáte Subversion a Maven pro správu svých projektů? Provozujete vlastní (firemní) Maven repository pro správu knihoven? Pokud ano, pak jistě hledáte způsob jak automatizovat provádění releasů svých projektů.
Standardní cestou, jak toho dosáhnout, je použití Maven Release Pluginu. Sladění všech částí konfigurace projektu pro jeho použití ovšem není triviální, takže zde je konkrétní příklad, jak to děláme my. Nebudu se rozepisovat o obecných principech použití Maven Release Pluginu, protože ty si lze snadno dohledat kdekoliv na webu.
Verze v Mavenu
Maven podporuje použití až 4 úrovní verzování, takže pro projekt lze definovat např. verzi <version>1.0.1-beta1</version>. Tři úrovně jsou ovšem nepovinné, takže lze mít i verzi <version>1</version>
Při vývoji se doporučuje mít v projektu nastavenu verzi SNAPSHOT a pouze během procesu releasu by se verze měla krátkodobě změnit na finální (bez kvalifikátoru „SNAPSHOT“). Po vyreleasování by se zase měla hned přehodit do vyšší SNAPSHOT verze (např. tedy: 1.0.1-SNAPSHOT > 1.0.1 > 1.0.2-SNAPSHOT). Tento princip se odráží i ve funkcionalitě samotného Maven Release Pluginu.
Konfigurace projektu
Příklad nastavení SVN adresy v pom.xml:
<scm> <connection>scm:svn:svn+ssh://host/cesta</connection> </scm>Nastavení Maven Release Pluginu v pom.xml
<build> <plugins> <plugin> <groupid>org.apache.maven.plugins</groupid> <artifactid>maven-release-plugin</artifactid> <version>2.0</version> <configuration> <remotetagging>false</remotetagging> <preparationgoals>clean install</preparationgoals> <goals>deploy</goals> </configuration> </plugin> </plugins> </build>Nastavení URL vaší firemní repository pro deploy v pom.xml:
<distributionmanagement> <snapshotrepository> <id>dist-snapshots</id> <url>ADRESA_VASI_FIREMNI_REPO</url> </snapshotrepository> <repository> <id>dist-releases</id> <url>ADRESA_VASI_FIREMNI_REPO</url> </repository> </distributionmanagement>Nastavení přístupových údajů pro deploy do firemní repo v lokálním settings.xml:
<servers> <server> <id>dist-snapshots</id> <username>VASE_USERNAME_K_FIREMNI_REPO</username> <password>VASE_HESLO_K_FIREMNI_REPO</password> </server> <server> <id>dist-releases</id> <username>VASE_USERNAME_K_FIREMNI_REPO</username> <password>VASE_HESLO_K_FIREMNI_REPO</password> </server> </servers>Proces releasu
Pokud si takto nastavíte svůj projekt, pak chování maven release pluginu bude následující. (pozn.: před releasem je třeba mít komitnuty všechny lokální změny do SVN).
Release provedeme ve dvou krocích:
- mvn -B -Dusername=VASE_SVN_USERNAME –Dpassword =VASE_SVN_HESLO release:prepare
zkontroluje, zda jsou všechny lokální změny komitnuty
- provede ‚mvn clean install‘ na projektu a ověří tak, že projekt je zkompilovatelný
- změní v pom.xml verzi ze SNAPSHOT na ostrou (např. z 4.2.2-SNAPSHOT na 4.2.2) a komitne celý projekt do SVN
- vytvoří nový tag v SVN s názvem aktuální ostré verze (např. MujProjekt-4.2.2)
- změní v pom.xml verzi z ostré na SNAPSHOT (např. z 4.2.2 na 4.2.3-SNAPSHOT) a komitne celý projekt
- mvn -B -Dusername=VASE_SVN_USERNAME –Dpassword =VASE_SVN_HESLO release:perform
- checkoutne tag (vytvořený v předchozím kroku) ze SVN
- zbuilduje checkoutnutý tag a deployne do firemní repository
Pozn.: pro SVN funkčnost je nutné mít nainstalovaného řádkového SVN klienta
To je samozřejmě optimistický případ, kdy jde všechno dobře. Pokud dojde k pádu v některém z kroků tohoto procesu, tak je to nutné řešit standardní cestou, popsanou v dokumentaci Maven Release Pluginu (příkaz ‚rollback‘, apod.).
Vysvětlivky k jednotlivým elementům a jejich hodnotám si jistě snadno dohledáte sami. Doufám, že tento textík vás při hledání správného způsobu releasování aspoň nakopne správným směrem.
18.6.2010 at 08:36
Hezky popsané, až na jednu věc – krok 1: „provede ‘mvn clean install’ na projektu a ověří tak, že projekt je zkompilovatelný“
Nejenom zkopilovaný, ale i otestovaný, protože je defaultně bindovaná „test“ fáze a nijak se to zde neignorovalo. Ale vzhledem k množství druhů testů by mne zajímalo, zda vůbec (skip-tests = true) testy spouštíte a pokud ano tak jaké testy (čistě unit testy, integrační i proti databázy, funkcionální…) v rámci této tvorby releasu. Nebo se spoléhá na kontinuální integraci a release je tak především o dané verzi a tagu? A čistě ze zájmu – ze SVN se to pak deployuje ručně, nebo to cpete dál přes něco jako je Cargo, Maven Deploy Plugin apod.?
19.6.2010 at 09:37
Máte pravdu, v defaultním nastavení se pouští i testy, ale máte pravdu i v tom, že my testy při releasu přeskakujeme (maven.test.skip=true). A pokud jde o deploy, tak ten provádí automaticky release plugin, viz. element deploy v nastavení release pluginu. Takže release je o změně verzí, otagování a o deployi do firemní repo. Pokud máte na mysli deploy do aplikačního kontejneru u enterprise či webových aplikací, pak v testovacím prostředí používáme Cargo, Tomcat, JBoss plugin, apod., do ostrého prostředí se to z firemní repo deployuje většinou ručně.
19.6.2010 at 09:40
Tedy měl jsem na mysli element goals s hodnotou deploy v konfiguraci release pluginu.
15.7.2010 at 20:33
Mvn release plugin je super, jen by mě zajímalo, jestli jde pomocí něho dělat automaticky denní buildy. Tj. něco takového
– V trunku mám verzi 1.6-SNAPSHOT
– mvn
– vznikne tag myProject-20100715
– v trunku dál bude verze 1.6-SNAPSHOT
Jde to samozřejmě dělat ručně, kdy při mvn release:prepare zadám ty hodnoty ručně, ale to je práce pro cvičenou opici :)
20.7.2010 at 07:26
Tak to bohužel nevím. Tímto způsobem release plugin nepoužíváme. Řekl bych, ale že takto automaticky to nepůjde.