Branching strategie con Maven, TeamCity e TFS

Question

Sono stato incaricato con il aggiornando il nostro processo di generazione in questo momento di essere più efficienti ed io abbiamo trascorso una settimana la lettura di best practice e strategie, ma ancora non hanno trovato una soluzione per il nostro problema attuale.

Sfondo

Attualmente abbiamo una monolitico build/applicazione che ha davvero bisogno di essere diviso a parte in almeno 4 applicazioni con alcune librerie condivise. Al momento non si diramano a meno che non sia assolutamente necessario. Abbiamo una build di teamcity che si basa su ogni check-in su TFS. Quando siamo pronti per un rilascio abbiamo un blocco del codice e solo le correzioni di check-in per i bug trovati in QA. Ovviamente questa è una pratica terribile e abbiamo finalmente ottenuto l'approvazione per cambiarlo.

Soluzioni proposte

La soluzione proposta sarà suddividere l'applicazione e hanno diversi cicli di rilascio per ogni applicazione, passare da formica Maven e ramo per ogni rilascio.

ramificazione - In questo momento non ci resta che un tronco principale di controllo del codice sorgente. Penso che vogliamo staccare il tronco quando siamo pronti per un rilascio e aggiornare il ramo per i bug trovati in QA. Quando la build è pronta per essere rilasciata, unire il ramo cambia nel tronco.

Ecco come stavo progettando di configurare TFS.

+Apps 
    +App1 
     +Components 
      +Core 
      +Web 
     +Branches 
    +App2 
     +Components 
      +Core 
      +Web 
     +Branches 
    +Libraries 
     +Lib1 
     +Lib2 
     +Branches 

Pensare di gestire tutte le POM e le versioni nelle POM sembra troppo difficile in questo momento. Ho letto il plugin di rilascio di Maven, ma non sono sicuro che possa diramarsi nel modo in cui penso che lo desideriamo.

Il prossimo problema è far funzionare Teamcity. Stavo pensando di avere 3 progetti TeamCity per ogni app. Un progetto dev che punta sempre ai tronchi, un progetto QA per testare la build del QA e un progetto di produzione per creare modifiche per gli hotfix. Ogni volta che una nuova versione arriva al QA, dovrei aggiornare il progetto teamcity di QA per indicare il nuovo ramo di rilascio e aggiornare il numero di build della release in teamcity. Quando quella release passa a QA, dovrei aggiornare il progetto di teamcity di produzione per indicare che il ramo che ha appena superato il QA e aggiornare il numero di build al numero di build che ha appena superato il QA.

Sicuramente c'è una strategia migliore che questo.

Domande

Dove dovrei mettendo queste cartelle ramo?

Qualora QA costruisce essere istantanee ancora fino a quando la build va alla pre-produzione?

Come si configura TeamCity di raccogliere questi rami senza modificare il percorso di fonti per ogni release?

Dovrebbe esserci POM genitore per ogni applicazione che gli sviluppatori utilizzano per assicurarsi che tutti i loro dipendenze sono compilati e aggiornati?

Answer 1

Voglio solo mettere in discussione il vostro pensiero che le applicazioni dovrebbero essere su diversi cicli di rilascio. La modularizzazione è una buona cosa per la qualità del codice, ma se i moduli sono su cicli di rilascio separati, si introduce un sovraccarico. In particolare, la gestione delle versioni diventa piuttosto onerosa e se ti sbagli puoi introdurre bug di runtime.

In che modo queste applicazioni separate si correlano tra loro? Esiste una dipendenza tra di loro (magari tramite una libreria condivisa)? Comunicano tra loro? Sono schierati insieme?

Se non è necessario che si trovano in cicli di rilascio separati, probabilmente è meglio tenerli insieme.