Quando è appropriato iniziare a utilizzare la prossima revisione di uno strumento quando si utilizza il cibo per cani?

Question

Quando è appropriato iniziare a utilizzare la prossima revisione di uno strumento quando si utilizza il cibo per cani?

#1 da (5 voti)
#2 da (3 voti)
#3 da (1 voti)
#4 da (1 voti)

9

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

La mia domanda è: in un processo di rilascio in stile scrum che utilizza 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:

usa costantemente la versione develop dello strumento: trovo che sto rompendo il mio sviluppo man mano che le modifiche vengono incorporate.
usa costantemente la versione master dello strumento: qualsiasi problema che scopro tramite dogfooding è un problema che è già stato rilasciato.

branching workflows scrum tools dogfooding

posta Jace Browning 23.07.2013 - 19:59

fonte

4 risposte

3

Se questo strumento viene utilizzato per produrre software di qualità di produzione (specialmente se viene utilizzato ricorsivamente, cioè per svilupparsi), aumenterei i tuoi sforzi di test iniziali e attenderò il dogfooding fino a quando il rilascio sarà abbastanza stabile che sei abbastanza fiducioso sul fatto che non infrangerà il codice di produzione usandolo.

Se devi aspettare che la versione principale abbia quel livello di confidenza, fallo.

risposta data 23.07.2013 - 22:21

fonte

1

Git è anche uno strumento di questo tipo e ovviamente anche il cibo per cani. Ma lo fa in misura diversa in diversi ambienti. I server pubblici sono in esecuzione solo mentre gli sviluppatori di solito lavorano con next (è il nome del progetto git per "sviluppare") o pu (ancora più sviluppare che sviluppare). Qualsiasi sviluppatore bloccato da qualche problema può tornare a next o master o all'ultima release ogni volta che viene bloccato da qualcosa e il repository principale non è interessato, quindi i problemi possono essere puliti facendo riferimento ad esso.

Il modello di ramificazione è simile al precedente con nomi leggermente diversi. master è il risultato di grandi rilasci, maint è il ramo di rilascio per il rilascio successivo, next è simile a sviluppare con una leggera differenza che le funzioni possono essere unite al master separatamente dopo essere già in next invece che whole next being fuse.

C'è un ramo extra, pu . Questo viene creato unendo tutti i rami di feature considerati per l'integrazione insieme a next (il ramo viene scartato e ricreato ogni volta). IIRC è pubblicato solo se supera la suite di test. Infine, ho visto Junio, il manutentore, che stava eseguendo gli script per costruirlo regolarmente a mano, ma tali script potrebbero essere eseguiti all'integrazione continua ogni notte e credo Gerrit lo crea addirittura automaticamente.

Quindi questo è la risposta. Tu condividi la versione di maggior sviluppo che hai negli ambienti di sviluppo, ma usa la versione precedente per creare versioni.

risposta data 24.07.2013 - 09:59

fonte

1

In base alla risposta accettata , ho intenzione di espandere il branching workflow per mantenere filiali simili alle seguenti:

master : si fonde con release-* alla chiusura
dogfood : rami da master ; include correzioni identificate durante la pastorizia; si fonde da develop quando il software è ritenuto "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 dogfood e feature-* rami
feature-* : rami da develop ; include le modifiche per una particolare nuova funzione
release-* : rami da dogfood quando il software è definito "stabile" per uso esterno; include aggiornamenti della documentazione e correzioni di bug minori prima di unire con master

risposta data 24.07.2013 - 20:44

fonte

Leggi altre domande sui tag branching workflows scrum tools dogfooding

Come funziona in pratica la manutenzione di OpenJDK? Perché i metodi accessor della specifica JavaBean diventano lo standard per lo sviluppo Java?

score 5 · Accepted Answer

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

In secondo luogo, è necessario un modo semplice e semplice per tornare alla precedente versione funzionante, per problemi che i test automatici non catturano.

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

Il coordinamento di una squadra è complicato, ma suppongo che si tratti principalmente di permettere a chiunque di iniziare una riserva e di comunicare le ragioni. Nel controllo della versione, un modo per designare questo sarebbe con qualcosa come un ramo last_known_good , da qualche parte tra develop e master nel tuo flusso di lavoro. Nulla viene spinto lì fino a quando non hai portato a termine con successo una build.