Qual è una buona strategia di versioning per ottenere 'fallire velocemente' con catene di sottomoduli dipendenti di Maven?

Question

Qual è una buona strategia di versioning per ottenere 'fallire velocemente' con catene di sottomoduli dipendenti di Maven?

#1 da (1 voti)

0

La mia organizzazione ha modularizzato il proprio monolite in moduli di esperti in dipendenze fino a quattro in profondità. Inizialmente abbiamo usato il plugin Maven per aumentare automaticamente i numeri di versione nel pom ogni volta che qualcuno ha effettuato un check-in. Quindi le dipendenze dei genitori potrebbero inserire gli aggiornamenti aggiornando i numeri di versione nel loro pom.xml .

Questo ha portato a un problema di "errore lento". Immagina il seguente scenario di dipendenza - dove ogni lettera è un modulo, e ogni numero è una versione:

OraimmaginadifareunaseriedimodificheaD,BeA,dimenticandoC.

Cèrimastoindietro(estaancorapuntandoaunavecchiaversionediD).

Ora,quandolapersonachedeveapportareunamodificaaClofa,trovachetuttelemodificheaDhannorottoCindiversimodi.IlfixingCorarichiedegiorni.

Quindiilteamhaelaboratounpianodiverso.Fallireveloce

OratuttociòcheeraunnumerodiversionesopraoraèLATEST.(Nota questo è maven 2 non esperto 3 ).

Ciò significa che qualsiasi modifica di rottura a D, verrà visualizzata in B o C alla successiva creazione. (La frase chiave qui è la prossima volta che viene costruita).

Ora supponiamo che il modulo A sia l'applicazione web genitore utilizzata dagli sviluppatori. Ora uno sviluppatore controlla una modifica a B - per la quale B compila (e A lavora sulla loro macchina). A tuttavia ha avuto diversi check-in e la versione di B: LATEST ora si interrompe con A: LATEST.

Abbiamo una strategia fail-fast - ma non c'è nulla nel controllo di versione per mostrare cosa ha rotto l'app. (E potenzialmente 40 moduli da esaminare per vedere quale sia la causa principale.)

La sfida è che ora puoi avere 50 sviluppatori la cui build è danneggiata, che non ha apportato modifiche alla loro macchina - né vedere nulla nel controllo della versione. Tutto perché la loro macchina è arrivata più tardi da artefatto.

Abbiamo ricevuto diversi suggerimenti per migliorarlo:

Nello strumento CI: collega le modifiche nel modulo per attivare le ricostruzioni dell'app Web principale
Nello strumento CI: crea moduli per inviare email agli sviluppatori in modo che sappiano cosa sta succedendo
Nello strumento CI: fai in modo che il modulo di compilazione scriva un "messaggio di build" in un file di registro nel repository git dell'applicazione web principale.

L'ultima raccomandazione è stata quella di modificare l'app Web principale con i numeri di versione e lasciare i moduli grandchild a LATEST .

Da notare che per le versioni - incrementiamo le versioni del modulo alle versioni fisse.

La mia domanda è: Qual è una buona strategia di versioning per raggiungere "fallire velocemente" con catene di sottomodelli dipendenti di maven?

versioning modules maven submodules modularization

posta hawkeye 20.07.2017 - 13:32

fonte

1 risposta

Leggi altre domande sui tag versioning modules maven submodules modularization

Per Qt, o C ++, esistono standard o pratiche moderni per la progettazione di file Run Configuration per i tuoi programmi? [chiuso] Progettazione di controller in cascata

score 1 · Accepted Answer

We have a fail-fast strategy

Sembra che tu abbia già capito una strategia di versione che fallisce rapidamente.

but there is nothing in version control to show what broke the app.

Dovresti avere test di integrazione automatici che testano l'integrazione tra i componenti. Se falliscono dovrebbe darti una buona indicazione di quale componente è cambiato. Se la compilazione non funziona, dovrebbe essere abbastanza ovvio quale componente è il colpevole con MethodNotFoundException o ClassNotFoundException e il pacchetto del componente sarà nella traccia dello stack.

The challenge is that you can now have 50 developers whose build is broken, who didn't make a change on their machine - nor see anything in version control. All because their machine pulled in latest from artifactory.

Potrebbe esserci qualcosa che puoi fare con le versioni per aiutare a risolvere questo impedimento per il tuo team. L'utilizzo di SNAPSHOT versioni può aiutarti davvero qui. Invece di LATEST potresti usare LATEST-SNAPSHOT o qualcosa di simile. L'utilizzo di SNAPSHOT è utile perché in Maven ci sono caratteristiche legate al mantenimento di versioni separate. Artifactory salverà tutte le versioni delle dipendenze degli snapshot in un formato come LATEST-SNAPSHOT-20090610.041042-5 . Ogni versione pubblicata avrà un identificativo univoco e l'ultima build è indirizzabile da LATEST-SNAPSHOT . Ciò significa che se la tua build si rompe, puoi temporaneamente ripristinare il componente B per dipendere da uno specifico snapshot precedente di A componente, quindi la build è fissa mentre B e A sono debuggati per l'integrazione da uno o più membri di la squadra.

Non solo, ma puoi sapere esattamente quale versione di LATEST-SNAPSHOT viene utilizzata con ogni build. Puoi tracciarlo per eseguire il commit nei log di costruzione.

Maven memorizzerà le versioni -SNAPSHOT nella cache per un periodo di tempo e gli sviluppatori e il tuo elemento della configurazione devono utilizzare il flag -U ( --update-snapshots ) durante la creazione (ad esempio mvn install -U ) per ottenere l'ultima istantanea. Nel caso in cui qualcosa si rompa, puoi avvisare i tuoi sviluppatori di non aggiornare le loro istantanee, o di far loro usare la specifica versione di lavoro dell'istantanea fino a quando non viene corretto il bug di integrazione.