Quando è opportuno iniziare a utilizzare la prossima revisione di uno strumento quando si mangia il cane?

In particolare, sto lavorando a uno strumento che integra un DVCS e un sistema di compilazione, ma immagino che la sfida che sto affrontando sorgerebbe per chiunque sviluppi uno strumento "meta" (compilatore, VCS, sistema di compilazione, test runner, ecc.) Che desidera svilupparsi attraverso "dogfooding" .

La mia domanda è: in un processo di rilascio in stile scrum utilizzando il flusso di lavoro di ramificazione , a che punto posso iniziare a utilizzare una versione più recente dello strumento nel ciclo di sviluppo dello strumento?

Sto cercando un processo per creare un equilibrio tra:

• uso costantemente la developversione dello strumento: trovo che sto interrompendo il mio sviluppo mentre le modifiche vengono incorporate.

• usa costantemente la masterversione dello strumento: eventuali problemi che scopro attraverso il cibo per cani sono problemi che sono già stati rilasciati.

La prima cosa da fare è eseguire test di regressione offline automatizzati molto approfonditi. Rendi questi test un requisito minimo per ciò che usi ufficialmente.

In secondo luogo, è necessario un modo semplice per tornare alla versione di lavoro precedente, per problemi che i test automatici non rilevano.

Ad esempio, il mio kernel Linux è stato personalizzato per un po 'di tempo. Vorrei patchare e compilare il mio kernel sullo stesso computer su cui intendevo usarlo, il che significava che avrei potuto perdere il mio ambiente di sviluppo se avessi creato un kernel difettoso. Quindi mi sono assicurato di tenere sempre un kernel noto nel mio menu di GRUB, quindi se ho fatto un errore, sono tornato in un buon ambiente di sviluppo con un semplice riavvio.

Coordinare questo con una squadra è complicato, ma suppongo che sia principalmente una questione di consentire a chiunque di avviare un fallback e comunicarne i motivi. Nel controllo della versione, un modo per designare sarebbe quello con qualcosa come un last_known_goodramo, da qualche parte tra develope masternel flusso di lavoro. Nulla viene spinto lì fino a quando non hai mangiato con successo una build.

Se questo strumento viene utilizzato per produrre software di qualità di produzione (soprattutto se viene utilizzato in modo ricorsivo, cioè per svilupparsi), aumenterei i tuoi sforzi di test iniziali e aspetterei il cibo per cani fino a quando il rilascio non sarà abbastanza stabile da te abbastanza sicuro che non infrangerai il codice di produzione usandolo.

Se devi aspettare che la versione principale abbia quel livello di confidenza, allora così sia.

Git è anche un tale strumento e ovviamente fa anche il cibo per cani. Ma lo fa in misura diversa in ambienti diversi. I server pubblici eseguono solo il rilascio mentre gli sviluppatori di solito lavorano con next(questo è il nome del progetto git per "sviluppo") o pu(ancora più sviluppo che sviluppo). Ogni sviluppatore che viene bloccato da qualche problema può tornare a nexto mastero l'ultima versione ogni volta che vengono bloccati da qualcosa e il repository principale non è interessato, in modo i problemi possono essere puliti facendo riferimento ad essa.

Il modello di ramificazione è simile al precedente con nomi leggermente diversi. masterè ciò da cui vengono fatte le grandi versioni, maintè il ramo di rilascio per la prossima versione del punto, nextè simile allo sviluppo con una leggera differenza che le funzioni possono essere unite al master separatamente dopo essere già state nella prossima successiva invece che l'intera successiva.

C'è un ramo in più, pu. Questo viene creato unendo tutti i rami delle funzionalità che sono considerati per l'integrazione insieme next(il ramo viene scartato e ricreato ogni volta). IIRC viene pubblicato solo se supera la suite di test. L'ultima volta che ho visto Junio, il manutentore, stava eseguendo gli script per costruirli regolarmente a mano, ma tali script potevano essere eseguiti da una continua integrazione notturna e credo che Gerrit lo crea anche automaticamente.

Quindi quel tipo di è la risposta. Dogfood è la versione di sviluppo più disponibile negli ambienti di sviluppo, ma utilizza la versione precedente per creare versioni.

Sulla base della risposta accettata , ho intenzione di espandere il flusso di lavoro di ramificazione per mantenere i rami simili ai seguenti:

• master: si fonde con release-*alla chiusura
• dogfood: Rami da master; include correzioni identificate durante l'alimentazione del cane; si fonde da developquando il software è considerato "stabile" per uso interno; la testa di questo ramo può essere spostata indietro nel tempo, se necessario
• develop: rami da master; include modifiche in corso, correzioni di errori e fusioni da dogfoode feature-*rami
• feature-*: rami da develop; include le modifiche per una nuova funzionalità particolare
• release-*: rami da dogfoodquando il software è considerato "stabile" per uso esterno; include aggiornamenti della documentazione e correzioni di bug minori prima della fusione conmaster