meistä
1C ei kehitä vain alustaa päälle и , mutta myös Java-sovelluksia - erityisesti uutta kehitysympäristöä perustuu Eclipseen ja alustaan syvästi integroituun messenger-palvelimeen - .
Merkintä
Käytämme useimmiten mavenia Java-sovellusten rakennusjärjestelmänä, ja tässä lyhyessä artikkelissa haluamme puhua yhdestä ongelmista, joita jouduimme kohtaamaan kehittämisen organisointiprosessissa, ja lähestymistavasta, jonka avulla pystyimme voittamaan tämän. ongelma.
Edellytykset ja työnkulku
Maven-projekteissamme kehityksen erityispiirteistä johtuen käytämme melko paljon moduuleja, riippuvuuksia ja lapsiprojekteja. Pom-tiedostojen määrä yhdessä puussa voi olla kymmeniä tai jopa satoja.
Vaikuttaa siltä: ei iso juttu, he loivat sen kerran ja unohtivat sen. Jos sinun on muutettava tai lisättävä jotain kaikissa tiedostoissa kerralla, editoreissa ja IDE:issä on paljon käteviä työkaluja. Mikä on yleisin säännöllinen muutos tiedostoon pom.xml? Uskomme, että muutokset projektiversioissa ja riippuvuuksissa. Ehkä joku haluaa kiistellä tästä, mutta meillä on juuri tämä tilanne. Syynä on se, että ytimen kanssa kehitämme samanaikaisesti monia omia kirjastojamme, ja rakennus- ja testaustulosten jatkuvan toistettavuuden kannalta tilannekuvien käyttö ei vaikuta meistä kätevältä lähestymistavalta. Tästä syystä projektien versionumeroa on nostettava jokaisen koontiversion yhteydessä.
Lisäksi kehittäjän on ajoittain rakennettava oma kirjaston haara ja tarkistettava sen toimivuus kaikkiin riippuvuuksiin nähden, minkä vuoksi hänen on vaihdettava kaikkien niiden versiot manuaalisesti.
Alkuperäinen ratkaisu
Tällaisten toistuvien ja useiden versiomuutosten myötä haluan yksinkertaistaa ja automatisoida prosessia CI:ssä. Tässä kätevä, tunnettu laajennus tulee apuun. versions-maven-plugin - yhdistä se ja käynnistä se
mvn -N versions:set -DnewVersion=2.0.1
ja Maven tekee kaiken kuten pitääkin: se kulkee hierarkian läpi ylhäältä alas ja korvaa kaikki versiot - kauneus! Nyt ei enää tarvitse kuin nostaa vetopyyntö, kollegat tarkistavat muutokset ja voit nopeasti liittyä runkoon. Nopeasti? Ihan sama miten se on. Pari sataa pom.xml tarkistettavaksi, ja tämä ei laske koodia. Lisäksi kukaan ei ole turvassa yhdistämisristiriidoista niin suuren muuttuneiden tiedostomäärän kanssa. Tässä on huomioitava, että CI-prosessissa versiomuutokset tapahtuvat automaattisesti toiminnallisuuden muutosten mukana, ei jotenkin erikseen.
Uudet ominaisuudet
Hetken rauhoittuimme ja erottuamme elimme niin, kunnes pojat kotosivat Versiosta 3.5.0-beta-1 alkaen Maven ei sisältänyt tukea niin sanotuille "paikkamerkeille". Näiden korvikkeiden ydin on se pom.xml Projektiversion nimenomaisen osoituksen sijaan käytetään muuttujia ${versio}, ${sha1} и ${changelist}. Itse näiden ominaisuuksien arvot asetetaan joko elementissäominaisuudet> tai ne voidaan määrittää järjestelmän ominaisuuden kautta
mvn -Drevision=2.0.0 puhdas paketti
Järjestelmän ominaisuusarvot ovat etusijalla kohdassa määriteltyihin arvoihin nähdenominaisuudet>.
Vanhempi
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-vanhempi
Ensimmäinen CI-ystävällinen
${revision}${sha1}${changelist}
...
1.3.1
-SNAPSSHOT
Jälkeläinen
4.0.0
org.apache.maven.ci
ci-vanhempi
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-lapsi
...
Jos haluat rakentaa version 2.0.0-SNAPSHOT, käytä sitä
mvn -Drevision=2.0.0 puhdas paketti
Jos haluat julkaista julkaisun, nollaa SNAPSHOT
mvn -Dchangelist= puhdas paketti
*Yllä olevat esimerkit ovat peräisin Maven Apache -projektin verkkosivuilla
Raaka todellisuus
Kaikki on hyvin ja tervettä, on aika tuntea tyytyväisyyttä, mutta ei. Osoittautuu, että tämä menetelmä ei toimi asennuksessa ja käyttöönotossa, koska sitä ei korvata arkistossa julkaistuissa artefaktien kuvauksissa ${versio} sen merkityksestä ja maven ei enää ymmärrä mistä on kyse.
org.apache
apache
${versio}
Valoa tunnelin päässä
Meidän on etsittävä ratkaisua ongelmaan. Olisi voinut pelastaa tilanteen . Tämä liitännäinen ratkaisee kaikki pom-muuttujat, mutta samalla leikkaa pois paljon muuta tietoa, jota tarvitaan vain kokoonpanon aikana ja joita ei tarvita, kun julkaistuja artefakteja tuodaan muihin projekteihin. Laajennus myös "suoraa" kaikki vanhemman ja lapsen väliset riippuvuudet, ja tuloksena saat litteän pomin, joka sisältää kaiken tarvitsemasi. Haittana oli se, että se leikkaa liikaa "ylimääräistä", mikä ei sopinut meille ollenkaan. Tutkittuaan tietoja tämän laajennuksen kehityksestä kävi ilmi, että emme ole ainoita universumissa, ja jo elokuussa 2018 Githubille luotiin vetopyyntö laajennusvarastoon halulla tehdä se mahdolliseksi. määrittääksemme itse, miten pom.xml "spoiloidaan". Kehittäjät kuuntelivat kärsivien ääntä, ja jo joulukuussa uuden version 1.1.0 julkaisun myötä flatten-maven-pluginiin ilmestyi uusi tila, solveCiFriendliesOnly, joka oli sopivampi kuin koskaan - se lähtee pom.xml sellaisenaan, paitsi elementti ja sallii ${versio}, ${sha1} и ${changelist}.
Lisätään laajennus projektiin
org.codehaus.mojo
flatten-maven-plugin
1.1.0
totta
ratkaistaCiFriendliesOnly
litistää
prosessi-resurssit
litistää
litistä.puhdista
puhdas
puhdas
Valmis!
Onnellinen loppu
Tästä eteenpäin, jotta voimme muuttaa koko projektin version ja kertoa kaikille riippuvuuksille siitä, meidän tarvitsee vain muokata elementtiätarkistus> vain juuressa pom.xml. Näistä tiedostoista, joissa on sama muutos, ei saavu sata tai kaksi, vaan yksi. No, ei ole tarvetta käyttää versions-maven-plugin.
Lähde: will.com