Controllo del codice sorgente: ruoli e responsabilità - Best practice

Sto cercando "Best Practices" per quanto riguarda ruoli e responsabilità, in particolare chi è responsabile delle fusioni dai rami di sviluppo al trunk (o principale). Fondamentalmente sto cercando munizioni per aiutare la mia causa.

Lasciami descrivere ciò che sto affrontando. Sono lo sviluppatore principale (proprietario) di una particolare applicazione. Di recente la nostra azienda è passata da VSS (di cui ero amministratore del database VSS in cui era archiviata la mia applicazione) a TFS (dove ho solo autorizzazioni per i rami di sviluppo creati dal nostro team "operazioni"). Nei lavori precedenti, ero un amministratore TFS, quindi conosco il modo in cui mi muovo tra TFS e MSBuild.

Non ho alcun problema con la strategia di diramazione e fusione in uso (ramo principale, con rami di sviluppo bug / progetto creati in base alle esigenze, uniti al principale quindi promossi in un ramo di rilascio). I problemi che ho sono:

1. Non riesco a creare i miei rami. Devo creare un'attività TFS per fare in modo che un membro del team "operazioni" crei il ramo per me.

2. Non riesco a unirmi da Main al mio ramo di sviluppo. Devo creare un'attività TFS per fare in modo che un membro del team "operazioni" esegua l'unione e quindi spero che non "calpesti" nessuna delle modifiche del mio team poiché il "ragazzo delle operazioni" può o meno essere uno sviluppatore e sicuramente ha poca o nessuna conoscenza del codice che sta unendo.

3. Non posso unirmi dallo sviluppo al Main. Ancora una volta devo creare un'attività TFS per fare in modo che "ops guy" esegua l'unione, sperando che lo faccia correttamente. Quindi devo creare un'altra attività TFS per ricollegarmi al mio ramo in modo da poter risolvere tutti i problemi che si sono verificati avendo un'unione non sviluppatore con Main.

4. Non riesco a creare o modificare gli script di MSBuild. Ancora una volta devo lavorare con il team "ops" che è nuovo in MSBuild in modo da poter eseguire solo le attività di build più basilari. (Dimentica qualsiasi cosa complessa o proibisci al cielo un compito personalizzato).

5. Non riesco a eseguire uno script MSBuild. Ancora una volta solo il team "ops" può farlo.

6. Per finire, in genere si tratta di una risorsa "off-shore" che esegue le attività richieste, quindi anche se creo l'attività di (branch / merge / build) al mattino presto, probabilmente non verrà completata fino a quella sera.

Ora non ho alcun problema con il team "operazioni" che mantiene i rami di rilascio. Come tutto ciò che stanno facendo è (sostanzialmente) prendere l'ultima versione da Main e promuoverla nel ramo di rilascio; quindi finché "Main" è stabile e pronto, il ramo di rilascio sarà buono.

La mia opinione è che i lead tecnici (come I) dovrebbero essere responsabili del mantenimento del trunk ("Main") e di qualsiasi fusione da / verso i rami di sviluppo. Il responsabile del team dovrebbe inoltre avere la capacità di generare script di MS Build da compilare e distribuire nell'ambiente di test di integrazione.

Qualcuno può indirizzarmi a un documento di buone pratiche che mi aiuterà a dimostrare il mio caso? Tutta la mia ricerca ha rivelato solo le migliori pratiche relative alle tecniche di ramificazione e fusione, e nessuna menzione dell'OMS dovrebbe eseguire tale diramazione / fusione.

La mia opinione generale sulle migliori pratiche è che qualsiasi membro del team di sviluppo dovrebbe essere in grado di eseguire qualsiasi azione sull'albero presumendo che tali azioni non facciano cose come avviare una distribuzione di produzione. Nei casi in cui una specifica diramazione / tag / repository agisce come una fonte per distribuzioni automatizzate che danno un ragionevole controllo delle modifiche o barriere all'ingresso, ha senso, più da un errore di mantenimento semplicemente da una prospettiva che da un angolo di controllo-maniaco. Vorrei incoraggiare gli sviluppatori a creare filiali e migliorare gli script di build. Vorrei trovare il modo di ottenere l'accesso degli sviluppatori alla produzione, se necessario. Parte del punto di controllo del codice sorgente è che si tratta di un'efficace gomma magica per errori - il peggio che devi fare è tornare indietro di un giro o due e diramarlo.

Purtroppo questo non sembra l'approccio che hanno adottato qui. Per sconfiggere questo penso che sia necessario coprire alcuni angoli:

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

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

Spero che sia di aiuto.

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 momento in cui scopre che è utile archiviare i lavori in corso. Perché vogliono / dovrebbero eseguirne il backup alla fine della giornata, vogliono condividerlo con un altro membro del team, devono essere protetti dai cambiamenti in main o altro.

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

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

   • Gli sviluppatori fanno questo da soli. Discutono solo i rischi con lo sviluppatore principale e testano le funzionalità in modo appropriato. Ciò implica che chiunque ha i permessi; se qualcuno infrange le regole, viene semplicemente sgridato e viene annullato il cambiamento sbagliato.
   • 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 deve comprendere il codice. In una squadra più piccola sarebbe la stessa persona dell'architetto, in una più grande sarebbero separati, ma avrebbero bisogno di cooperare strettamente.

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

5. Se esiste un integratore designato, di solito si occupano di definire (quale script eseguire) e avviare le build. Altrimenti o il capo squadra lo fa, il membro designato del gruppo lo fa o qualcuno ha le autorizzazioni e i delegati del capo squadra creano e avviano particolari build caso per caso.

6. In nessun caso le operazioni sopra descritte richiedono un operatore esterno alla squadra. L'operatore è necessario solo per impostare le autorizzazioni, creare repliche e simili.

Non importa "buone pratiche" (abbi pazienza con me) questo è un problema di gestione - fondamentalmente non sei in grado di svolgere il tuo lavoro correttamente a causa dei vincoli posti su di te.

In realtà non importa quale sia la "migliore pratica": si tratta di un problema semplice, dimostrabile, che influirà sulla produttività di te e del tuo team e che dovrai occuparti della gestione della tua linea su tale base.

Vedo che brandizzare un documento di buone pratiche potrebbe (ma solo potrebbe ) essere di aiuto nel tentativo di persuaderli, ma di gran lunga migliore è l'idea che dovrai avere membri del team di sviluppo seduti nelle loro mani in attesa di qualcuno in un diverso fuso orario mettere insieme i loro atti a meno che i processi non vengano migliorati / razionalizzati.

E non essere troppo conflittuale - tanto quanto qualsiasi cosa tu voglia sapere perché le restrizioni sono in atto, qual è la giustificazione ...