Controllo del codice sorgente: ruoli e responsabilità: best practice

La mia visione generale delle migliori pratiche è che ogni membro del team di sviluppo dovrebbe essere in grado di eseguire qualsiasi azione sull'albero presumendo che quelle azioni non facciano come dare il via a un'implementazione di produzione. Nei casi in cui un ramo / tag / repository specifico agisce come una fonte per le distribuzioni automatizzate mettendo in qualche ragionevole controllo il cambiamento o le barriere all'entrata hanno senso, più da errori di mantenimento si limitano a sbagliare la prospettiva rispetto ad un certo angolo di controllo. Vorrei incoraggiare gli sviluppatori a creare filiali e migliorare gli script di compilazione. Troverò dei modi per consentire agli sviluppatori di accedere alla produzione, se necessario. Parte del punto di controllo della sorgente è che si tratta di un'efficace gomma da cancellare di errori: la cosa peggiore che devi fare è eseguire il rollback di un giro o due e staccare quello.

Sfortunatamente questo non sembra l'approccio che hanno preso qui. Per sconfiggere questo penso che devi coprire alcuni angoli:

a) Dimostra che queste politiche sono dannose per lo sviluppo. Registra tutto il tempo che passi in attesa di operazioni per lavorare su qualcosa. Questo da solo dovrebbe vendere una gestione ragionevole sul perché questa è una cattiva politica.

b) Fai amicizia con Ops - forse c'è un motivo per questa politica. Forse questo ragionamento potrebbe essere affrontato in maniera più efficace.

Spero che questo aiuti.

Le pratiche che ho visto sono:

1. Chiunque può creare rami di lavoro a proprio piacimento. Uno sviluppatore deve essere in grado di creare un ramo di funzionalità nel secondo in cui trova che è necessario archiviare il proprio lavoro corrente in corso. Perché vogliono / dovrebbero eseguire il backup alla fine della giornata, vogliono condividerli con un altro membro del team, devono essere protetti dai cambiamenti principali o simili.

2. Chiunque può fare assolutamente qualsiasi cosa per i rami di sviluppo. Lo sviluppatore deve essere in grado di unirsi dal momento in cui un altro sviluppatore dice loro che qualcosa di cui hanno bisogno è stato integrato in main.

3. Per unire a main (integrazione), ci sono tre opzioni:

   • Gli sviluppatori lo fanno da soli. Discutono solo i rischi con lo sviluppatore principale e testano le funzionalità in modo appropriato. Ciò implica che qualcuno ha i permessi; se qualcuno infrange le regole, viene semplicemente sgridato e viene ripristinata la modifica sbagliata.
   • Un altro sviluppatore lo fa dopo aver esaminato le modifiche. Richiede ancora che tutti abbiano i permessi per farlo; le regole sono ancora applicate dallo sviluppatore principale.
   • C'è un integratore designato che rivede e si fonde in main. Ma l'integratore fa parte del team e ha bisogno di capire il codice. Su una squadra più piccola sarebbe la stessa persona dell'architetto, più grandi sarebbero separati, ma avrebbero bisogno di cooperare strettamente.

4. Chiunque prepari una caratteristica dovrebbe adattare lo script di costruzione. Ma non sono sicuro di come funzioni con TFS; nei sistemi che ho usato lo script build era sempre solo un file con versione, quindi gli sviluppatori lo hanno modificato come qualsiasi altro ed è stato integrato insieme a tutto il resto.

5. Se c'è un integratore designato, di solito si occupano di definire (quale script eseguire) e di iniziare le build. In caso contrario, il responsabile del team lo fa, il membro del team designato lo fa o chiunque ha i permessi e il team guida i delegati che configurano e avviano particolari build caso per caso.

6. In nessun caso le operazioni sopra indicate richiedono l'operatore al di fuori del team. L'operatore è necessario solo per impostare le autorizzazioni, creare repliche e così.