O nas
W 1C rozwijamy nie tylko platformę
Wejście
Najczęściej używamy mavena jako systemu kompilacji aplikacji Java i w tym krótkim artykule chcielibyśmy porozmawiać o jednym z problemów, z którymi musieliśmy się zmierzyć w procesie organizacji rozwoju oraz o podejściu, które pozwoliło nam to pokonać problem.
Warunki wstępne i przepływ pracy
Ze względu na specyfikę rozwoju w naszych projektach mavenowych wykorzystujemy całkiem sporo modułów, zależności i projektów potomnych. Liczba plików pom w jednym drzewie może wynosić dziesiątki, a nawet setki.
Wydawałoby się: nic wielkiego, raz to stworzyli i zapomnieli o tym. Jeśli chcesz zmienić lub dodać coś we wszystkich plikach na raz, w edytorach i IDE dostępnych jest wiele wygodnych narzędzi. Jaka jest najczęstsza regularna zmiana w pliku pom.xml? Wierzymy, że zmiany w wersjach projektu i zależnościach. Być może ktoś będzie chciał się z tym kłócić, ale u nas dokładnie tak jest. Powodem jest to, że wraz z jądrem rozwijamy jednocześnie wiele własnych bibliotek, a dla stałej powtarzalności wyników kompilacji i testów stosowanie migawek nie wydaje nam się wygodnym podejściem. Z tego powodu konieczne jest podnoszenie numeru wersji w projektach przy każdej kompilacji.
Ponadto od czasu do czasu programista musi zbudować własną gałąź biblioteki i sprawdzić jej funkcjonalność pod kątem wszystkich zależności, dla których musi ręcznie zmienić wersję wszystkich z nich.
Rozwiązanie początkowe
Przy tak częstych i wielokrotnych zmianach wersji chcę uprościć i zautomatyzować proces w ramach CI. Tutaj z pomocą przychodzi wygodna, dobrze znana wtyczka. wersje-maven-plugin - podłącz go i uruchom
mvn -N wersje: zestaw -DnewVersion=2.0.1
a Maven zrobi wszystko tak, jak powinien: przebiegnie hierarchię od góry do dołu, zastępując wszystkie wersje - piękność! Teraz pozostaje tylko zgłosić żądanie ściągnięcia, współpracownicy przejrzą zmiany i będziesz mógł szybko dołączyć do łącza trunkingowego. Szybko? Nieważne jak to jest. Kilkaset pom.xml do przeglądu i to nie jest liczenie kodu. Ponadto nikt nie jest bezpieczny przed konfliktami scalania przy tak dużej liczbie zmienionych plików. Należy tu zaznaczyć, że w procesie CI zmiany wersji następują automatycznie wraz ze zmianami funkcjonalności, a nie jakoś osobno.
Nowe funkcje
Na chwilę uspokoiliśmy się i po rezygnacji żyliśmy tak, aż do chłopaków
mvn -Drevision=2.0.0 czysty pakiet
Wartości właściwości systemowych mają pierwszeństwo przed wartościami zdefiniowanymi wniska zabudowa>.
Rodzic
4.0.0
org.apache
Apache
18
org.apache.maven.ci
ci-rodzic
Pierwszy przyjazny dla CI
${wersja}${sha1}${lista zmian}
...
1.3.1
-MIGAWKA
Potomek
4.0.0
org.apache.maven.ci
ci-rodzic
${wersja}${sha1}${lista zmian}
org.apache.maven.ci
ci-dziecko
...
Jeśli chcesz zbudować wersję 2.0.0-SNAPSHOT, po prostu użyj
mvn -Drevision=2.0.0 czysty pakiet
Jeśli chcesz wydać wersję, po prostu zresetuj SNAPSHOT
mvn -Dchangelist= czysty pakiet
*Powyższe przykłady pochodzą z
Brutalna rzeczywistość
Wszystko dobrze i zdrowo, czas poczuć satysfakcję, ale nie. Okazuje się, że ta metoda nie będzie działać w przypadku instalacji i wdrażania, ponieważ nie zostanie zastąpiona w opisach artefaktów publikowanych w repozytorium ${wersja} na jego znaczeniu, a Maven nie będzie już rozumiał, o co w tym wszystkim chodzi.
org.apache
Apache
${wersja}
Światło na końcu tunelu
Musimy poszukać rozwiązania problemu. Mógłby uratować sytuację
Dodanie wtyczki do projektu
org.codehaus.mojo
flatten-maven-plugin
1.1.0
PRAWDA
rozwiązaćTylkoCiFriendlies
spłaszczyć
zasoby procesowe
spłaszczyć
spłaszczyć. oczyścić
czysty
czysty
Gotowe!
szczęśliwe zakończenie
Od tej chwili, aby zmienić wersję całego projektu i dać znać o tym wszystkim zależnościom, wystarczy, że dokonamy edycji elementurewizja> tylko w katalogu głównym pom.xml. Do recenzji trafia nie sto czy dwa takie pliki z tą samą zmianą, ale jeden. Cóż, nie ma potrzeby używać wersje-maven-plugin.
Źródło: www.habr.com