Chi siamo
In 1C sviluppiamo non solo la piattaforma con e , ma anche applicazioni in Java, in particolare un nuovo ambiente di sviluppo basato su Eclipse e un server profondamente integrato con la piattaforma di messaggistica – .
Introduzione
Come sistema di build per le applicazioni Java, utilizziamo principalmente maven e in questo breve articolo vorremmo discutere una delle sfide incontrate nel processo di organizzazione dello sviluppo e il metodo che ci ha permesso di superare questo problema.
Prerequisiti e flusso di lavoro
A causa delle specificità dello sviluppo nei nostri progetti maven, utilizziamo un numero significativo di moduli, dipendenze e progetti secondari. Il numero di file pom in un albero può arrivare a contare decine e persino centinaia.
Sembra semplice: una volta creato si può dimenticare. Se è necessario cambiare o aggiungere qualcosa in tutti i file contemporaneamente, ci sono molti strumenti utili negli editor e IDE. Qual è la modifica più comune al file pom.xml? Riteniamo sia la modifica delle versioni di progetto e dipendenze. Forse qualcuno vorrà contestare questa affermazione, ma per noi è così. La ragione è che, oltre al core, sviluppiamo parallelamente molte delle nostre librerie e, per garantire la riproducibilità costante dei risultati di compilazione e test, l'uso degli snapshot non ci sembra un approccio pratico. Per questo motivo dobbiamo aumentare il numero di versione nei progetti ad ogni build.
Inoltre, lo sviluppatore ha di tanto in tanto la necessità di costruire il proprio ramo di una libreria e testarne il funzionamento con tutte le dipendenze, per questo motivo è necessario modificare manualmente la versione in tutte.
Soluzione iniziale
Con queste frequenti e molteplici modifiche alle versioni, desideriamo semplificare e automatizzare il processo all'interno del CI. Qui entra in gioco un plugin di pubblico dominio molto utile. versions-maven-plugin — lo attiviamo e lo eseguiamo
mvn -N versions:set -DnewVersion=2.0.1
e Maven farà tutto come deve: passerà attraverso l'gerarchia dall'alto verso il basso, sostituirà tutte le versioni — è fantastico! Ora resta solo da fare un pull request, i colleghi lo esamineranno e si può rapidamente integrare nel trunk. Rapidamente? Non proprio. Un paio di centinaia pom.xml in revisione, e questo senza contare il codice. Inoltre, nessuno è al riparo da conflitti di merge con un numero così elevato di file modificati. Vale la pena notare che durante il processo CI le modifiche delle versioni avvengono automaticamente insieme alla modifica della funzionalità, e non separatamente.
Nuove funzionalità
Per un po' siamo stati tranquilli e, accettando la situazione, così abbiamo vissuto, finché i ragazzi del non hanno incluso in Maven, a partire dalla versione 3.5.0-beta-1, il supporto per quelli che vengono chiamati "sostituti" delle versioni (placeholders). L'essenza di questi sostituti è che invece di specificare una versione concreta del progetto si utilizzano variabili pom.xml ${revision} ${sha1}, ${changelist} e ${changelist}. I valori di queste proprietà sono definiti o nell'elemento <properties>, o possono essere definiti tramite una proprietà di sistema
mvn -Drevision=2.0.0 clean package
I valori delle proprietà di sistema prevalgono su quelli definiti in <properties>.
Genitore
<project>
4.0.0
<parent>
org.apache
apache
18
</parent>
org.apache.maven.ci
ci-parent
First CI Friendly
<version>${revision}${sha1}${changelist}</version>
…
<properties>
<revision>1.3.1</revision>
<changelist>-SNAPSHOT</changelist>
<sha1
</properties>
</project>
Discendente
<project>
4.0.0
<parent>
org.apache.maven.ci
ci-parent
<version>${revision}${sha1}${changelist}</version>
</parent>
org.apache.maven.ci
ci-child
…
</project>
Se desideri compilare la versione 2.0.0-SNAPSHOT, basta usare
mvn -Drevision=2.0.0 clean package
Se vuoi fare un rilascio, basta azzerare SNAPSHOT
mvn -Dchangelist= clean package
*Gli esempi sopra sono presi da sito del progetto Maven Apache
La dura realtà
Va tutto bene e fantastico, è il momento di provare un senso di soddisfazione, ma no. Si scopre che per install e deploy questo metodo non è praticabile, poiché nelle descrizioni degli artefatti pubblicati nel repository non sarà sostituito ${sha1} con il suo valore e Maven non capirà di cosa si tratta.
<parent>
org.apache
apache
${revision}
</parent>
Luce in fondo al tunnel
Devi cercare una soluzione al problema. La situazione potrebbe essere salvata da . Questo plugin consente di risolvere tutte le variabili nel pom, ma allo stesso tempo elimina un sacco di altre informazioni che sono necessarie solo durante la build e non servono per importare artefatti pubblicati in altri progetti. Inoltre, il plugin "appiattisce" tutte le dipendenze parent-child, e alla fine si ottengono pom piatti che includono tutto il necessario. Il problema era che elimina troppo "superfluo", il che non ci soddisfava affatto. Dopo aver studiato le informazioni sullo sviluppo di questo plugin, abbiamo scoperto che non eravamo gli unici nell'universo, e già nell'agosto 2018 nel repository del plugin su GitHub era stata creata una pull request con la richiesta di rendere possibile definire autonomamente come "rottamare" pom.xml. Gli sviluppatori hanno ascoltato le voci dei bisognosi, e già a dicembre, con il rilascio della nuova versione 1.1.0, nel flatten-maven-plugin è stata introdotta una nuova modalità resolveCiFriendliesOnly, che è arrivata come una manna dal cielo - lascia pom.xml com'è, tranne per l'elemento <version> e consente ${sha1}, ${changelist} e ${changelist}.
Aggiungiamo il plugin al progetto
<plugins>
<plugin>
org.codehaus.mojo
flatten-maven-plugin
1.1.0
<configuration>
true
<flattenMode>resolveCiFriendliesOnly</flattenMode>
</configuration>
<executions>
<execution>
flatten
process-resources
<goals>
flatten
</goals>
</execution>
<execution>
flatten.clean
clean
<goals>
clean
</goals>
</execution>
</executions>
</plugin>
</plugins>
Fatto!
Felice fine
Da ora in poi, per modificare la versione dell'intero progetto e informare tutte le dipendenze, basta modificare l'elemento <revision> in un solo file radice. pom.xmlNon arriveranno un centinaio di questi file con la stessa modifica, ma uno solo. Inoltre, non sarà più necessario utilizzare versions-maven-plugin.
Fonte: habr.com
