Uscite con più filiali a lunga vita usando Maven

Question

Quindi, ecco la Subversion, Jenkins, l'installazione Beanstalk:

• trunk/-> sviluppo linea principale
  • CI si basa su checkin
  • successo accumulo CI genera CD Costruiamo che spinge all'ambiente fagiolo magico "Testing"
• rami/qa/-> versione attuale candidato
  012.
  • CI si basa su checkin
  • successo accumulo CI genera accumulo CD che spinge a "QA" ambiente Beanstalk
• rami/prod/-> versione corrente
  • CI si basa su checkin
  • successo CI costruire depone le uova accumulo CD che spinge l'ambiente a fagiolo magico "Prod"

Fondamentalmente quello che voglio fare è questo:

• ciclo di sviluppo inizia nel tronco (tronco: 0.1-SNAPSHOT)
• Quando il ciclo di sviluppo è completo ramo di QA e di essere ciclo qa. Inizia anche il ciclo di sviluppo successivo nel bagagliaio (trunk 0.2-SNAPSHOT, qa: 0.1-SNAPSHOT)
• Quando il ciclo qa è completo diramazione per produrre ed eseguire il rilascio di Maven. Anche cominciare successivo ciclo qa (tronco 0,2-SNAPSHOT, qa: 0.2-SNAPSHOT, prod: 0,1)

L'idea è quella di avere sprint brevi dove alla fine di ogni cylce uno sviluppo termina e un ciclo qa comincia. Quando il ciclo qa è completo, viene spinto in un ambiente di produzione.

Vorrei conservare i rami ed eseguire l'unione con \ dai rami anziché eliminati e ricreati. L'idea è che tutte le correzioni apportate in qa verrebbero unite al tronco di introduzione, e qualsiasi modifica apportata in prod sarebbe stata reimmessa in qa (e di nuovo nel trunk).

prod è quindi un ramo "attivo" e rappresenta lo stato corrente dell'ambiente di produzione.

questo è per un piccolo team di sviluppatori che lavorano su sprint settimana lungo.

Domande:

1. Come funziona questo suono messa a punto?
2. Posso convincere Maven ad agire correttamente, o dovrò scrivere questo?
3. Chi è il tuo papà? E cosa fa?

Answer 1

Non consiglierei un ramo qa e prod. Leggi le migliori pratiche di sovversione. Suggerirei The SVN Book, in particolare il capitolo 4 riguardante la ramificazione/fusione.

È consigliabile eseguire ogni versione anche se si tratta di QA (tramite tag). Trunk viene utilizzato per il lavoro di sviluppo corrente, i tag sono per le versioni rilasciate (definite come "funzionalità complete", non in quale ambiente si trova) e le diramazioni sono per correzioni di errori (tra le altre cose).

Esempio Scenario:

versione 1.0 è in produzione, il team ha appena rilasciato da 2,0 a QA per il test, e stanno ora lavorando su una versione 3.0. A questo punto si dovrebbe avere:

• /trunk (sviluppatori a lavorare su 3.0)
• /tags/2.0 (usato per QA)
• /tags/1.0 (storico per ciò che è in produzione)

Se la tua squadra di QA trova un problema in 2.0, creerai un ramo fuori dal tag 2.0. Fai la tua correzione, unisci a trunk quindi rilascia il ramo come 2.0.1 (un altro tag). Si potrebbe quindi lasciato con:.

• /tronco (sviluppatori che lavorano su 3.0, + 2.0 la correzione dei difetti)
• /branches/2.0.* (Utilizzare il carattere * per indicare questo è dove tutto 2.0 * le correzioni verranno commesse. È possibile riutilizzare questo stesso ramo se viene rilevato un altro difetto nel codice 2.0)
• /tags/2.0 (tag originale QA stava testando il difetto)
• /tags/2.0.1 (2.0 codice base, con SOLO correzione difetti)
• /tags/1.0 (storico per cosa è in produzione)

Answer 2

Ho fatto un lavoro simile su branching e release prima, e nella mia esperienza, l'installazione che hai descritto è diventata molto ingombrante e burocratica prima di troppo.

La risposta di Domenic D. è abbastanza vicina al tipo di impostazione che preferirei, in particolare con un numero limitato di sviluppatori. Più rami hai, più complessa diventa la gestione della base di codice e più probabile che tu introduca un errore attraverso cattive pratiche di fusione.

Una cosa che non si menziona è importante, secondo me, per iniziare subito è la vostra politica di check-in. Lo SCM non è un backup per il lavoro incompleto, dovresti cercare di assicurarti che le linee principali siano per lo meno sempre costruttive. Sii severo al riguardo, renderà la vita di tutti più facile alla fine.

La cosa principale è che, indipendentemente dalle procedure di rilascio, assicurati di ottenere il buy-in dal tuo team e che non devono essere "forzati" al loro posto. Questo è un segno che potrebbe esserci qualcosa di sbagliato in ciò che è venuto fuori non è giusto e sarà probabilmente ignorato o sovvertito rapidamente.