Meist
1C-s arendame mitte ainult platvormi järgnevaga ja , vaid ka rakendusi Java-s – eelkõige uut arenduskeskkonda Eclipse'i põhjal ja sügavalt platvormiga integreeritud sõnumside serverit – .
Sissejuhatus
Java-rakenduste ehitamise süsteemina kasutame kõige sagedamini mavenit, ja selles lühikeses artiklis tahaksime rääkida ühest probleemist, millega arenguprotsessi korraldamisel silmitsi seisisime, ja lähenemisest, mis võimaldas selle probleemi ületada.
Eeldused ja tööprotsess
Seoses meie maven-projektide arenduse spetsiifikaga kasutame piisavalt palju mooduleid, sõltuvusi ja alprojekti. Ühes puu struktuuris võib pom-failide arv ulatuda kümneteni või isegi sadadeni.
Tundub, et pole midagi hullu, korra loodi ja unustati. Kui tuleb midagi muuta või lisada kõigis failides korraga, on toimivaid tööriistu toimetamises ja IDE-des piisavalt. Milline on kõige levinum regulaarne muudatus pom.xml failis? Oleme kindlad, et see on projekti ja sõltuvuste versioonide muutmine. Võib-olla on kellegil soov selle vastu vaielda, kuid meil on see just nii. Põhjus peitub selles, et koos põhikomponendiga arendame paralleelselt palju oma raamatukogusid ja pideva koostamise ning testimise tulemuste korduvuse tagamiseks ei näe me snapshotide kasutamist mugava lähenemisviisi. Seetõttu tuleb iga kogumise korral projektides versiooninumbrit tõsta.
Samuti tekib arendajal aeg-ajalt vajadus koguda oma haru mõnest raamatukogust ja testida selle tööd kõigi sõltuvustega, mille jaoks tuleb kõigis neist käsitsi versioon muuta.
Esialgne lahendus
Nii sagedaste ja mitmekesiste versioonimuudatustega tahaks CI raames protsessi lihtsustada ja automatiseerida. Siin tuleb appi mugav ja tuntud plugin. versions-maven-plugin — ühendame selle ja käivitame
mvn -N versions:set -DnewVersion=2.0.1
ja Maven teeb kõik nagu peab: läheb läbi hierarhia ülevalt alla, asendab kõik versioonid — ilus! Nüüd jääb üle vaid teha pull-request, kolleegid vaatavad muudatused üle ja saab kiiresti trunk'i sulanduda. Kiiresti? Kuidas veel! Paar-kolm sada pom.xml ülevaatamiseks ja see ei hõlma isegi koodi. Lisaks ei ole merge-konfliktide eest keegi kaitstud, kui on nii palju muudetud faile. Siinkohal on oluline märkida, et CI protsessi käigus muutuvad versioonid automaatselt koos funktsionaalsuse muutustega, mitte kuidagi eraldi.
Uued võimalused
Me rahunesime hetkeks ja, leppides, elasime nii edasi, kuni poisid kandsid Mavenisse, alates versioonist 3.5.0-beta-1, toetust nn «asendajatele» (placeholders). Asendajate olemus on see, et pom.xml konkreetse projekti versiooni näitamise asemel kasutatakse muutujaid ${revision}, ${sha1} ja ${changelist}. Nende omaduste väärtused määratakse kas elemendis <properties> või saab need määrata süsteemi omaduse kaudu
mvn -Drevision=2.0.0 clean package
Süsteemi omaduste väärtused on eelised väärtustele, mis on määratud <properties>.
Vanem
<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
<version>18</version>
</parent>
<groupId>org.apache.maven.ci</groupId>
<artifactId>ci-parent</artifactId>
<name>First CI Friendly</name>
<version>${revision}${sha1}${changelist}</version>
…
<properties>
<revision>1.3.1</revision>
<changelist>-SNAPSHOT</changelist>
<sha1/>
</properties>
</project>
Järglane
<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache.maven.ci</groupId>
<artifactId>ci-parent</artifactId>
<version>${revision}${sha1}${changelist}</version>
</parent>
<groupId>org.apache.maven.ci</groupId>
<artifactId>ci-child</artifactId>
…
</project>
Kui soovid üles ehitada versiooni 2.0.0-SNAPSHOT, siis lihtsalt kasutame
mvn -Drevision=2.0.0 clean package
Kui soovid teha väljaannet, siis lihtsalt nullime SNAPSHOT
mvn -Dchangelist= clean package
*Ülaltoodud näited on võetud Maven Apache projekti veebisaidilt
Karm reaalsus
Kõik on hästi ja tore, aeg on rahulolutunne kogeda, aga ei. Selgub, et installi ja deploy korral see meetod ei sobi, kuna avaldatud artefaktide kirjeldustes ei toimu asendust ${revision} tema väärtusele ja maven ei saa aru, millest üldse jutt.
<parent>
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
<version>${revision}</version>
</parent>
Valgus tunneli lõpus
Peab otsima probleemi lahendust. Situatsiooni oleks võinud päästa . See plugin võimaldab kõiki muutujaid pom-is, kuid samal ajal kärbib palju muud teavet, mis on vajalik ainult ehitamisel ja ei ole vajalik avaldatud artefaktide importimiseks teistesse projektidesse. Plugin "sirutab" kõik parent-child sõltuvused, ning tulemuseks on lamedad pom-id, mis sisaldavad kõike vajalikku. Probleem oli aga see, et kärbiti "liialt palju" üleliigset, mis meid üldse ei rahuldanud. Pärast teabe uurimist selle plugina arendamise kohta selgus, et me pole ainukesed universumis, ning juba 2018. aasta augustis loodi GitHubis plugina hoidlas pull-request, mille sooviga teha võimalus iseseisvalt määrata, kuidas pom.xml "portida". Arendajad kuulasid hädasolijate hääli, ja juba detsembris, uue versiooni 1.1.0 väljalaskmisega, ilmus flatten-maven-plugin`isse uus režiim resolveCiFriendliesOnly, mis tuli kui valatult – see jätab pom.xml-i selliseks nagu see on, välja arvatud element <version> ja lubab ${revision}, ${sha1} ja ${changelist}.
Lisame plugina projekti
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>flatten-maven-plugin</artifactId>
<version>1.1.0</version>
<configuration>
<updatePomFile>true</updatePomFile>
<flattenMode>resolveCiFriendliesOnly</flattenMode>
</configuration>
<executions>
<execution>
flatten
process-resources
<goals>
flatten
</goals>
</execution>
<execution>
flatten.clean
clean
<goals>
clean
</goals>
</execution>
</executions>
</plugin>
</plugins>
Valmis!
Õnnelik lõpp
Nüüd, et muuta kogu projekti versioon ja teavitada sellest kõiki sõltuvusi, peab lihtsalt redigeerima elementi <revision> ühes ainsas juurkataloogis. pom.xmlArvutisse ei jõua sadu neid faile sama muudatusega, vaid üks. Ning kaob vajadus kasutada versions-maven-plugin.
Allikas: habr.com
