La chiave qui è di creare un flusso di lavoro che eviti la situazione in cui il codice "cattivo" viene mai esposto a sviluppatori o team diversi da quelli che lo hanno creato. Se ciò dovesse accadere, un buon codice verrebbe mischiato a male, e "scomparire" o districarli sarà difficile. Quindi, evita che ciò accada in primo luogo.
Suppongo che HelloWorld in questo esempio sia il repository principale, che contiene un buon codice noto. Gli sviluppatori A, B e C clonano tutti da questo repo e sviluppano le loro modifiche contro di esso. Nel modello che sto descrivendo, HelloWorld-test è un repository temporaneo utilizzato esclusivamente dal QA per testare le modifiche unite prima di spostarle nella linea principale. Gli sviluppatori non guardano mai al test HelloWorld. Ecco come funziona.
-
A, B e C tutti clonano un buon codice dalla linea principale (HelloWorld).
-
A apporta modifiche e dice a QA che è pronta (o A spinge le sue modifiche a un repository temporaneo). Il clone del QA è mainline, estrae e unisce le modifiche di A, quindi costruisce e verifica. Supponendo che tutto ciò sia andato a buon fine, il controllo qualità accolla queste modifiche nella riga principale.
-
B ora rende disponibili le sue modifiche. QA clona la riga principale e quindi estrae e trasforma le modifiche di B in HelloWorld-test. Continuando con il tuo esempio, diciamo che questi cambiamenti sono pessimi. Quindi l'unione di QA fallisce, o la compilazione fallisce, o i test falliscono, o qualcosa del genere. A questo punto, il QA dichiara che le modifiche sono errate, notifica B e semplicemente elimina il test HelloWorld. Ora è responsabilità di B estrarre e unire da mainline, correggere errori di test o qualsiasi altra cosa.
-
QA può quindi eseguire il processo con C, partendo da un nuovo clone di mainline e unendo le modifiche di C. Nota che le cattive modifiche di B non hanno mai raggiunto la linea principale e quindi le modifiche di C (o di chiunque altro) non verranno mai mixate con esse.
-
A un certo punto B ha aggiustato le sue modifiche e chiede al QA di fare un altro pull / merge / build / test. Il QA può farlo in seguito, oppure possono semplicemente aggirare il ciclo di diversi sviluppatori o team finché non tornano in B.
Questo è spesso chiamato un "modello di attrazione" dello sviluppo. Credo che le modifiche al kernel di Linux siano gestite in questo modo.
In molti casi non è "QA" chi fa il ciclo pull / merge / build / test, ma invece è fatto da un sistema di integrazione continua come Hudson o Jenkins.
Naturalmente, ci sono molte varianti di questo, indipendentemente dal fatto che singoli sviluppatori o team dispongano di repository temporizzati, se le modifiche siano propagate tramite push o pull, ecc. Ma dovrebbero condividere tutte queste caratteristiche chiave:
-
Solo le buone modifiche conosciute lo fanno nella linea principale.
-
Gli sviluppatori estraggono / clonano solo dalla linea principale, quindi non basano mai il loro lavoro su modifiche errate.
-
Le nuove modifiche vengono unite, costruite e testate separatamente da tutto il resto e vengono verificate correttamente prima di essere unite nella linea principale.
