in che modo QA verifica il codice e si fonde con un ramo stabile in mercurial?

Question

Il mio team di sviluppo è appena agli inizi con Mercurial e siamo confusi sul seguente punto:

Siamo un team di php webdev.

Abbiamo 3 sviluppatori. La maggior parte di ciò che stiamo facendo ora è la correzione di bug su un prodotto molto nuovo. Anche facendo qualche nuovo sviluppo di funzionalità.

Abbiamo 2 persone di controllo qualità. Ogni bugfix e funzionalità devono essere testati prima di poter essere pubblicati.

Finora, ogni sviluppatore ha il proprio repository. Abbiamo un server centrale chiamato WebDev con il proprio repository. Uno sviluppatore si allontana da WebDev, quindi apporta alcune modifiche (cioè risolve un bug) e invia a Webdev. Quindi un tester QA testerà il codice sul server centrale (quindi testando il codice in WebDev) e se funziona, invierà quel codice al nostro server di produzione.

Questo non funziona bene, perché ... cosa succede quando Developer-1 (dev-1) corregge un bug e spinge a WebDev. Allo stesso tempo, dev-2 corregge un bug diverso e spinge a WebDev. la persona QA verifica il codice lì e approva il secondo bugfix ma non il primo. Come avrebbe spinto il secondo changeset alla produzione senza il primo? Sembra che stiamo perdendo tutti i vantaggi di un sistema di controllo della versione.

Ho letto molto sulla ramificazione, ma non riesco a capire come farlo funzionare per noi ... creiamo un nuovo ramo per ogni bugfix e nuova funzione, e l'unico dopo che è stato testato, Il QA si fonderà nel ramo predefinito su WebDev? È il modo migliore, o c'è qualcosa che mi manca?

Grazie !!

---- ---- UPDATE

grazie a tutti coloro che hanno risposto finora. ecco dove sto trattenendo ora ... posso pensare a due soluzioni.

1) dev-1 corregge un bug per bug-101. tira da webdev, si fonde e si impegna localmente. lo mette in prova. Il QA viene prelevato direttamente dal suo repository e testato localmente. se passa, QA attingerà da webdev -> merge -> push a webdev (e se è un grosso cambiamento, può rivedere lì per assicurarti che vada bene). quindi testiamo solo una cosa alla volta, WebDev contiene solo le modifiche che sono state testate localmente dai tester ed è sempre stabile.

2) creare rami per tutto. dev-1 crea il ramo "bugfix-101" quindi spinge su webdev senza unirlo. Il QA può testare il codice derivato e, se approvato, unirlo con il ramo predefinito. Ho quattro domande su questo metodo: (a) è possibile spingere un ramo aperto in un repository remoto? (b) se QA fonde e chiude il ramo su webdev, al prossimo riavvio, il mio repo locale chiuderà e unirà anche il ramo? e (c) come si esegue il test dal codice derivato? quando eseguo l'app Web nel browser, come faccio a testare dal ramo ?? (d) ci sono problemi di prestazioni con la creazione di così tanti rami denominati (supponendo che la maggior parte di essi verrà chiusa rapidamente)?

Grazie ancora.

Answer 1

Seguire fino a Bassam:

La tua squadra è ovviamente manca il (molto facile) ramificazione e la fusione in Mercurial e lavorare con un monolitico ramo di default (?).

Basta cambiare il vostro pensiero e del flusso di lavoro un po 'e vedrete una grande differenza:

1. Ogni QA-membro ha una permanente clone del pronti contro termine e tira solo repo di uno sviluppatore su richiesta (è più veloce, i cambiamenti tirati sono più visibili); forse ramo QA ha anche senso
2. Utilizzare un ramo separato per ogni grande cambiamento (caratteristica o bugfix)
3. Quando uno sviluppatore ha un insieme di modifiche X nel ramo "Bugfix Y" nella sua repo finito e pronto per il test , chiede al QA di "tirare e testare il changeset X"
4. QA lo fa, forse unisce "Bugfix Y" al ramo "QA" nel il suo repository (come un "test passato" segno?) e unisce il " QA "ramo su mainline (ramo" Stable "o" predefinito ") e infine invia i risultati alle destinazioni necessarie (WebDev e Prod?)
5. Ad ogni richiesta successiva, il passaggio 4 deve essere ripetuto

In questo modo si mai mix in uno approvare ciclo più di un sviluppo azione

Answer 2

Creare rami con Mercurial è un gioco da ragazzi, usalo :) Vorrei creare rami separati per diverse funzionalità e diversi bug e fare in modo che la persona QA li unisca al ramo principale ogni volta che si assicura che un bug sia corretto.

Un'altra alternativa è utilizzare named branches che è essenzialmente la stessa cosa ma invece di rami separati, i rami nominati stanno andando fianco a fianco con il ramo predefinito fino a quando non sono pronti per essere uniti.

Nota: abbiamo alternato entrambe le strategie sul mio posto di lavoro.

Answer 3

Questo è un buon posto per utilizzare tags. La persona dev o qa può taggare la versione contenente solo le modifiche che desidera, quindi la persona qa può clonare il repository a livello di tag (o aggiornare il repository al changeset con tag se questo si adatta meglio a te ... la tua preferenza). Quindi fai il test usando la versione codificata del codice.

Come nota a margine, sarebbe la pena guardare in queste due risposte sul sito Kiln StackExchange per vedere le strategie di repository di Fog Creek (vedere come mangiano il proprio cibo per cani):

• http://kiln.stackexchange.com/questions/354/release-repo-suggestions/355#355
• http://kiln.stackexchange.com/questions/500/should-i-use-more-than-one-repository/504#504

Aggiornamento

C'è una buona descrizione in this post sul motivo per cui è meglio correggere i bug in un ramo stabile e spingerli indietro a dev, mentre si usa un ramo dev per le funzionalità (che vengono rimandate anche al ramo stabile ... a due vie spingendo/tirando). Questo è come lo facciamo anche noi. Non risponde direttamente alla tua domanda, ma è abbastanza correlato che pensavo di includerlo.