Strategia di ramificazione per ambiente di test

La tua strategia di ramificazione mi sembra davvero buona. Ho fatto la stessa strategia in passato e funziona bene. Disegnala su una lavagna e fai in modo che tutti i tuoi sviluppatori lo comprendano in modo che le persone facciano il lavoro giusto nel ramo giusto. Insegna e spiega a tutti il comando di cambio e fai in modo che tutti possano ricontrollare il ramo su cui stanno lavorando. (Oppure, in alternativa, controlla l'intero repository ... a seconda della dimensione del codice :) Ricorda ... svn revert è il tuo migliore amico!

Personalmente preferisco che una persona sia la persona "fusione / branca" (con alcune persone di riserva come riserve) per assicurare che tutto sia tenuto sotto controllo e coerente. Lascia che quella persona diventi il tuo guru SVN e te ne andrai.

Alcuni altri suggerimenti utili:

• Incoraggiare gli aggiornamenti SVN frequenti e i commit SVN. È preferibile ogni giorno.
• Le fusioni incrociate devono essere eseguite ogni giorno, o in alternativa ogni volta che viene risolto un bug. Falli presto e fallo spesso! (sarai bravo a farlo in fretta).
• Ottieni uno strumento di differenziamento buono: oltre l'obiettivo è l'asso. Lo standard tortoiseSVN uno ... non troppo bello.
• Non eseguire il check-in delle cose che cambiano durante la compilazione (come la directory di output)
• Prova a ripulire il repository prima di iniziare la ramificazione (sbarazzati dei file che non devono essere sotto controllo di versione - cose come librerie esterne, ecc.). Più piccolo è il tuo repository, meglio
• Le modifiche al tuo ramo di produzione e ai rami QA dovrebbero essere il più brevi e brevi possibile: non avviare il codice di refactoring, basta correggere il bug.
• Assicurati di passare dal livello più alto della tua soluzione - e se hai un DB spero che tu abbia scriptato tutti i tuoi file DB (come proc o trigger memorizzati)

Indica inoltre alle persone di non spostare le cartelle in giro a meno che non sia strettamente necessario. Questo renderà la tua fusione molto più semplice :) (Non fare quello che ho fatto, lanciarmi su una directory enorme ristrutturata a metà strada attraverso un enorme cambiamento nel bagagliaio che ha rovinato tutte le nostre fusioni ... ero molto popolare dopo quello).

Sembra un'idea che potrebbe non funzionare.

Forse dai un'occhiata a questo link per qualche ispirazione: GitHub Flow Questo è il modo github sta usando il suo sistema di versioni. Anche se usano git invece di svn, direi che le idee dietro le loro decisioni rimarranno comunque.

Le (imho) parti più importanti di questo post riguardanti il controllo delle versioni:

• master / trunk è distribuibile o, ancora meglio, implementato
• lo sviluppo avviene solo sui rami
• l'unione avviene solo dopo la revisione (forse puoi inserire il QA qui)

In questo modo ottieni stabilità. Lasciami spiegare perché. Hai bisogno di una base per diramarti. Ora, se questa base non è la migliore che si possa fare e l'istanza definitiva di tutto, allora non ha senso farlo. Se ti allontani dal tronco mentre altri ci lavorano, vedrai che i bug che hanno introdotto non sono stati trovati o risolti. Quindi i probabili test di integrazione (e qualsiasi cosa sopra) potrebbero fallire anche se non ne sei la causa, aumentando drasticamente la quantità di debug e di frustrazione.

Inoltre avrai un sacco di lavoro mantenendo sincronizzati i tuoi 3 rami (trunk, QA, production). Ciò probabilmente causerà confusione. Posso quasi garantirti di perdere la traccia ad un certo punto nel tempo se non applichi questa funzionalità con l'automazione.

Suggerirei di andare nel modo in cui GitHub sta andando. È quindi possibile taggare quale versione inviare a QA per avere un riferimento durante la comunicazione. Ancora meglio potrebbe avere un QA più stretto integrato nel circuito di feedback come indicato sopra. Suggerisco vivamente di utilizzare un sistema CI come Jenkins se non si è ancora pensato di utilizzarlo. In questo modo si riduce al minimo il tempo di andata e ritorno tra il check-in e il feedback e si possono applicare regole di codifica, eseguire analizzatori statici per il controllo degli errori e così via.

Dichiarazione di non responsabilità: il flusso git può funzionare solo se non vuoi correggere bug senza introdurre nuove funzionalità. Se vuoi farlo, il tuo approccio potrebbe essere più adatto.

La tua strategia di ramificazione mi sembra abbastanza ragionevole. Abbiamo perseguito una strategia simile nella mia azienda e ha funzionato bene con noi.

Una piccola differenza è che eseguiamo pre-release di correzioni di QA sul trunk perché ci impedisce di unirle e non abbiamo avuto davvero problemi nello sviluppo di nuove funzionalità durante la correzione dei difetti. Ciò conferisce al QA un po 'più di un obiettivo mobile in termini di ciò che stanno testando, quindi quanto è praticabile dipende da quanto QA sia strettamente integrato con il team di sviluppo. Funziona bene per noi perché abbiamo un team abbastanza integrato e perché siamo in una pianificazione di iterazione rapida. Abbiamo un ramo separato per ogni versione in modo che possiamo applicare patch all'ambiente di produzione mentre stiamo ancora creando nuove funzionalità sul trunk, ma non sembra che sarà necessario per te fino a quando non inizierai a rilasciare oltre il QA.

Ci sono un paio di consigli aggiuntivi che vorrei fare:

1. Incoraggia i frequenti check-in. Questo è particolarmente utile se hai molte persone che si stanno sviluppando nel bagagliaio. Impedirà agli sviluppatori di non essere sincronizzati con ciò che gli altri stanno facendo e di ridurre il potenziale di conflitti. Assicurati che ci sia una guida esplicita su quando è il momento di impegnarsi e su quanto spesso gli sviluppatori dovrebbero ottenere dal trunk. I commit frequenti non dovrebbero essere un problema dato che stai cercando di isolare le modifiche di rottura ai rami delle funzionalità.
2. Stabilisci un processo di integrazione continua. Questo garantisce che non ti ritroverai con enormi mal di testa alla fine di un'iterazione, fornirai una notifica se qualcosa è rotto, e automatizzeremo di più il tuo QA sia attraverso test automatizzati di unità / accettazione e potenzialmente attraverso analisi statiche / strumenti di ispezione del codice. Ho trovato che CI fornisce un grande "bang for the buck" come investimento nel processo di gestione della configurazione. Nota , esiste una tensione tra l'elemento della configurazione e l'utilizzo eccessivo dei rami di funzionalità perché i rami consentono essenzialmente di mantenere pulito il trunk, passare i test in CI, ma creare comunque conflitti / problemi nei rami. Frequenti fusioni nel bagagliaio possono essere d'aiuto in questo modo, poiché è possibile eseguire CI nel ramo e tirare spesso dal tronco, ma una proliferazione di rami inizierà a sconfiggere il processo di CI complicandone l'amministrazione o semplicemente ignorandolo nei rami.

Da ciò che affermi:
Il tuo codice risiede nel trunk
Per ogni caratteristica / miglioramento principale - si taglia un ramo fuori dal tronco - sviluppare e quindi fornire al controllo qualità per testare Tutti i principali e importanti bug vengono risolti in questo 'ramo del QA' Posta QA "tronca" il codice da questo ramo al tronco

Questa mi sembra una buona strategia per me abbiamo regolarmente ramificato, unito e trunking in SVN usando il plugin svn di eclipse o tortoise
Mi sembra buono

Suona bene, mi preoccuperei che il ramo QA sia relativamente di breve durata, e farei tutte le correzioni relative a quella release su quel ramo in modo che venissero fusi in trunk su 1 go anziché fissarli sul trunk come sono trovati.

Se correggi i bug insignificanti nel ramo QA, i tester possono vederli e contrassegnarli rapidamente. Presumo che ottengano build settimanali / settimanali dalla branca del QA, quindi bug insignificanti non dovrebbero richiedere molto tempo se eseguiti su QA. (Parlo per esperienza in cui il più piccolo dei microscopici bug può avere un effetto a catena che causa un grave dolore altrove)

Un potenziale miglioramento che posso citare è lo sviluppo di funzionalità su un ramo, ovvero spostare il lavoro che si esegue normalmente su un tronco su un ramo dedicato. Quindi al trunk verranno assegnate solo le unioni, che possono aiutare a tenere traccia delle modifiche completate.

Hai menzionato diverse cose che potrebbero aumentare l'imbarazzo e ridurre le possibilità di successo per il tuo progetto:

The project will be 1 year and production deployment will only occur towards the end of the project.

Ti consiglio davvero di distribuirti in un ambiente simile alla produzione il più spesso possibile, idealmente ogni giorno. Lasciare il cosiddetto 'productionization' alla fine del progetto di solito causa problemi imprevisti. Gli anti-pattern qui sono 'integrazione tardiva' e 'implementazione tardiva della produzione'.

1 month per iteration

Un mese è un battito cardiaco di iterazione molto lungo e pochi sviluppatori saranno in grado di ricordare chiaramente a cosa stavano lavorando all'inizio dell'iterazione. Suggerirei di andare per le iterazioni di 2 settimane, consegnando in lotti più piccoli. Anti-pattern: "lotti di grandi dimensioni", "tempo di ciclo lungo".

Feature Branch

Probabilmente dovresti evitare i rami di funzionalità, a meno che tu non usi anche rami di integrazione . Idealmente, utilizzare invece i selettori di funzionalità e il branch-by-astrstration. La ramificazione delle feature tende a portare a problemi di integrazione tardiva imprevisti. Anti-pattern: "integrazione in ritardo".

We're using SVN.

L'unione è piuttosto dolorosa in Subversion, anche se si utilizzano le funzionalità di tracciamento unione di v1.5 e successive. Ti consiglio di passare a Git: non guarderai mai indietro. L'unione con Git è indolore rispetto a Svn. Ho usato Subversion per molti anni e inizialmente ero scettico nei confronti di Git, ma ora sono "venduto". Le uniche cose che userei Svn per oltre Git sono per la memorizzazione di file binari (se veramente necessario!) E per cose come RANCID che hanno il completo controllo del repository. Per il controllo del codice sorgente, Git batte Subversion ogni volta.

Recentemente ho scritto del lavoro che ho svolto sul rilascio di trunk / mainline / master ed evitando i branch delle funzionalità, che potrebbero darti qualche ulteriore "spunto di riflessione": Lasciando la piattaforma - Branching and Releasing for Independent I sottosistemi

Inoltre, leggi alcuni post sul sito di Martin Fowler, come ContinuousIntegration , FeatureBranch e BranchByAbstraction .

Infine, acquista una copia di Consegna continua di Jez Humble e David Farley e segui le raccomandazioni: è un libro estremamente prezioso e ogni sviluppatore dovrebbe possedere una copia. Ho trovato utile stampare le pagine del Sommario e metterle sul muro per tenere traccia dei progressi :) Anche se non si intende continuare la consegna, molte delle pratiche in questo libro sono davvero salutari e vitali per il successo della consegna del software oggi.

Spero che questo aiuti.

M