Gestione delle modifiche al codice in questo ambiente di codifica

Question

Gestione delle modifiche al codice in questo ambiente di codifica

#1 da (6 voti)

3

Ho il seguente ambiente di codifica:

Tre sviluppatori
Il codice sorgente risiede in Team Foundation Server (2010)
Ambiente di sviluppo
Ambiente Stage
Ambiente di produzione

Come sviluppatore senior, ho bisogno di rivedere il codice prima di essere trasferito all'ambiente di staging. Una volta esaminato il codice, viene spinto sullo stage dove viene testato dal nostro (piccolo) team di test. Una volta che le modifiche sono state testate e accettate, passo alla produzione.

Supponiamo che:

Developer A invia una modifica, la rivedo e spingo allo stadio. Developer B invia una modifica, la rivedo e la push to stage.

Durante il test, un utente dice che la modifica Developer A fatta ha bug e deve essere corretta. Ma le modifiche Developer B hanno reso necessario andare alla produzione.

Questo succede più che non. Al momento, devo aspettare Developer A per correggere i bug e provare di nuovo o avere Developer A per disabilitare le loro modifiche.

Come risolvere questo dilemma?

development-process production

posta PhillyNJ 11.09.2014 - 16:37

fonte

1 risposta

Leggi altre domande sui tag development-process production

Questa avvertenza nella documentazione dell'API di Android è un'indicazione di progettazione non ottimale? Oggetto modello e attributi aggiuntivi

score 6 · Accepted Answer

Una strategia, che può essere stabilita con qualsiasi VCS decente, consiste nell'aprire un ramo di manutenzione parallelo in tale situazione (basato sull'ultima release di produzione stabile) e unire solo le correzioni di bug immediate o altre modifiche urgenti per la produzione in esso ( per esempio, le modifiche del tuo sviluppatore B). In genere, è possibile creare una versione di manutenzione da questo ramo per la produzione molto più veloce, con solo un rischio basso che introduce nuovi bug e con meno sforzi di test rispetto al tuo attuale ramo di sviluppo.

Il tuo "ramo di staging" conterrà comunque tutte le nuove funzionalità (comprese le modifiche da A e B), e potrai distribuirlo in un secondo momento quando sarà "pronto".

Questo modello può essere supportato dallo schema di numerazione della versione: ad esempio, quando si rilascia la versione 1.2 in produzione, è in realtà la versione 1.2.0. Ogni volta che si rilascia una versione di manutenzione, si aumenta l'ultima cifra: 1.2.1, 1.2.2, 1.2.3. Questi numeri dicono a chiunque che la tua applicazione non contiene nuove funzionalità reali all'interno della linea 1.2, solo correzioni urgenti. Quando consegni una versione con nuove funzionalità, aumenti le prime cifre: 1.3, 1.4 o 2.0.

Infatti, nel nostro team facciamo a volte uso di questa tecnica per il nostro prodotto principale, ma solo quando non possiamo nascondere facilmente le modifiche "di dev A" dietro a " attiva / disattiva la funzione ". Quest'ultima causa in genere meno sforzi di ramificazione / fusione rispetto a un ramo di manutenzione, quindi se è possibile evitare le modifiche nel codice di dev A influenzando la produzione semplicemente impostando uno switch di runtime, allora questa potrebbe essere l'alternativa migliore.