Modelli per l'integrazione continua e DVCS

12

Al momento utilizziamo Subversion e TeamCity, passeremo all'utilizzo di Mercurial (in particolare il forno come utenti di FogBugz).

Ovviamente ciò comporterà cambiamenti, si spera, miglioramenti nei nostri modelli di sviluppo (tutti e due di noi!), ma l'unico problema con cui sto discutendo è come strutturare le cose in modo tale da godere ancora dei benefici dell'integrazione continua Il server CI (che ci sono e resteranno benefici è un dato di fatto, la cui discussione è al di fuori della portata della questa domanda).

Con SVN ci stiamo impegnando in un numero limitato di repository centrali, in effetti uno per progetto (più o meno una soluzione di Visual Studio), quindi è facile innescare una build e ottenere la rassicurazione che tutti i file sono stati commessi e che non ci sono dipendenze vaganti ecc. ecc. Ma se vogliamo sfruttare al meglio il mercurial vorremmo avere più istanze di repository - dove mi aspetterei che i cambiamenti in genere fluiscano verso un repo definitivo "in diretta". Il problema con cui sto combattendo è che il repository live mi sembra troppo "tardivo" per attivare i miei build CI. OTOH un build CI per progetto per sviluppatore è probabilmente eccessivo (e causa altri problemi). Penso che il live sia troppo tardi perché - dato che possiamo / dovremmo avere più repository (cloni di) - live dovrebbe essere distribuibile mentre vogliamo costruire / eseguire test (unità al commit, integrazione a intervalli programmati) su commit dello sviluppo.

Sto pescando un po 'ma questo perché una delle cose che un repository centrale di subversion ne dà uno (io, con il nostro setup!) è molta chiarezza su cosa costruire quando.

NB. Non sto chiedendo dei meccanismi per usare Mercurial con un'integrazione continua - Ho questo che funziona come un trattamento per un progetto personale, i suoi modelli e strutture e pratiche di lavoro / flusso di lavoro che sto cercando di far girare la testa.

    
posta Murph 02.12.2011 - 17:50
fonte

3 risposte

2

In primo luogo, avere più build per progetto in TeamCity è davvero la strada da percorrere. La natura della piattaforma rende davvero semplice - il pulsante di copia è lì per un motivo.

In ogni caso, quando eravamo su SVN, in genere eseguivamo 2 build per ciascun progetto, uno puntato sulla linea di sviluppo principale (nel nostro caso il trunk) e uno sul nostro ramo di rilascio. Abbiamo portato questa configurazione di build su HG seguendo un modello di ramificazione simile a questo . Solo la vera sfida è stata trovare un nuovo schwea funk sui numeri di build ora che non potremmo più usare il numero di revisione SVN attuale.

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

    
risposta data 03.12.2011 - 02:30
fonte
2

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

  • default tracce "completato" sviluppo
  • feature branches traccia il lavoro attualmente in corso
  • rilascia rami punti traccia in cui abbiamo rilasciato l'impostazione predefinita

Quindi, il lavoro inizia creando un ramo dalla punta corrente di default . Quando il ramo della funzione è fatto *, il ramo viene chiuso e reimmesso in default .

A un certo punto, decidiamo che siamo pronti per il rilascio, quindi creiamo un nuovo ramo di rilascio dal suggerimento corrente in predefinito . Questo ci consente di apportare modifiche al codice attualmente in produzione assegnandoci al ramo di rilascio pur consentendo lo sviluppo attivo sui rami delle funzioni e predefinito .

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

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

Il lavoro di ramo predefinito ci fa sapere che il nostro albero dei sorgenti principale è sempre stabile: i lavori di rilascio ramo ci fanno sapere che quei rami sono stabili e ci forniscono l'output di build è necessario inserire un rilascio in produzione.

* La nostra definizione di "fatto" è che la funzione è aggiornata con le fusioni di default ed è stata approvata nella revisione del codice.

    
risposta data 07.12.2011 - 07:39
fonte
1

Se ti sposti su un DVCS, come Hg, non otterrai solo la "parte distribuita", ma otterrai anche tutta la potenza di una buona ramificazione e fusione.

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

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

L'ho spiegato dettagliatamente qui e i professionisti e contro di CI vs "controllato" qui .

    
risposta data 09.12.2011 - 19:08
fonte

Leggi altre domande sui tag