Pattern per l'integrazione continua e DVCS

Attualmente utilizziamo Subversion e TeamCity, passeremo all'utilizzo di Mercurial (in particolare Kiln poiché siamo utenti di FogBugz).

Ovviamente ciò comporterà cambiamenti - si spera miglioramenti - nei nostri modelli di sviluppo (tutti e due!) Ma l'unico problema con cui mi sto cimentando è come strutturare le cose in modo da godere ancora dei vantaggi dell'integrazione continua / del nostro server CI ( che ci sono e rimarranno vantaggi è un dato, la cui discussione è al di fuori dell'ambito di questa domanda).

Con SVN ci impegniamo a un numero limitato di repository centrali - effettivamente uno per progetto (più o meno una soluzione di Visual Studio), quindi è facile attivare una build e ottenere la sicurezza che tutti i file sono stati sottoposti a commit e che non ci sono dipendenze vaganti, ecc. ecc. Ma se avremo il giusto vantaggio di Mercurial, avremo bisogno di più istanze di repository - dove mi aspetterei che i cambiamenti fluiscano generalmente verso un repository "live" definitivo. Il problema con cui sto lottando è che il repository live mi sembra troppo "in ritardo" per innescare i miei build CI OTOH una build CI per progetto per sviluppatore è probabilmente eccessiva (e causa altri problemi).

Sto pescando un po ', ma è perché una delle cose che un repo centrale di sovversione fornisce (io, con la nostra configurazione!) È molta chiarezza su cosa costruire quando.

nb Non mi sto chiedendo quali sono i meccanismi dell'utilizzo del mercurio con integrazione continua: ho un lavoro da trattare per un progetto personale, i suoi schemi e le sue strutture e la pratica / flusso di lavoro che sto cercando di farmi girare la testa.

Innanzitutto, avere più build per progetto in TeamCity è davvero la strada da percorrere. La natura della piattaforma lo rende davvero semplice: il pulsante Copia è lì per un motivo.

In ogni caso, quando eravamo su SVN, di solito eseguivamo 2 build per ogni progetto: uno puntava sulla linea di sviluppo principale (nel nostro caso il trunk) e uno puntava sul ramo di rilascio. Abbiamo portato questa configurazione di build su HG seguendo un modello di branching simile a questo . L'unica vera sfida è stata trovare un nuovo funk schwea sui numeri di build ora che non potevamo più usare l'attuale numero di revisione SVN.

Cerchiamo di incoraggiare le persone a spingere relativamente spesso, specialmente quando c'è molto lavoro in corso contemporaneamente e volevamo cicli di feedback più rapidi. Solo perché è un DCVS non significa che devi spingere solo una volta al giorno o qualcosa del genere.

Usiamo Kiln da circa un anno e abbiamo provato diverse cose. Dove siamo finiti è usare i rami con nome (al contrario dei cloni dei rami) con la seguente strategia di ramificazione:

• traccia predefinita sviluppo "completato"
• i rami delle caratteristiche tengono traccia del lavoro attualmente in corso
• i rami di rilascio tengono traccia dei punti in cui siamo stati rilasciati per impostazione predefinita

Quindi, il lavoro inizia creando un ramo di funzionalità dall'attuale punta di default . Al termine del ramo della funzione *, il ramo viene chiuso e ricollegato al valore predefinito .

Ad un certo punto, decidiamo che siamo pronti per il rilascio, quindi creiamo un nuovo ramo di rilascio dal suggerimento corrente per impostazione predefinita . Questo ci consente di apportare modifiche al codice attualmente in produzione impegnandoci nel ramo di rilascio pur consentendo lo sviluppo attivo sui rami delle funzionalità e l' impostazione predefinita .

Per quanto riguarda l'integrazione continua, facciamo due cose:

• Un'integrazione "sempre attiva" che monitora lo stato di default
• Nuove integrazioni per ciascun ramo di rilascio

Il processo di diramazione predefinito ci consente di sapere che il nostro albero di origine principale è sempre stabile: i processi di diramazione di rilascio ci consentono di sapere che quei rami sono stabili e ci forniscono l'output di generazione necessario per inviare un rilascio alla produzione.

_{* La nostra definizione di "fatto" è che la funzionalità è aggiornata con le unioni predefinite ed è stata approvata nella revisione del codice.}

Se passi a un DVCS, come Hg, non solo ottieni la "parte distribuita", ma ottieni anche la piena potenza di una buona ramificazione e fusione.

Considerando che ora avrai un buon tracker di problemi e un buon SCM ... perché non creare un ramo per ogni attività?

Il modello "branch per task" non è nuovo (controlla il libro di Berczuk) ma è sicuramente qualcosa da provare.

L'ho spiegato in dettaglio qui , e i pro ei contro di CI vs "controllati" qui .