In che modo i manager delle release ruotanti migliorano la velocità e la stabilità di un progetto?

A seconda di come è strutturato il tuo processo, posso pensare a due argomenti per la rotazione:

• Quando abbiamo rilasci che si sovrappongono, come le versioni di bug back port che avvengono contemporaneamente a una versione generale, aiuta a gestire la complessità perché persone separate gestiscano versioni separate.
• I rilasci hanno spesso una "caratteristica stella". In tal caso è molto utile avere qualcuno che abbia molta familiarità con quella caratteristica sia la persona che fa le chiamate su quali bug sono show stop, cosa errare, quali cambiamenti dell'ultimo minuto sono troppo rischiosi, quando siamo sicuri che sia stato sufficientemente testato, ecc.

Ci sono due cose da tenere in considerazione qui.

1. il processo di rilascio del progetto richiede molto tempo:
   
   • richiede 1 mese, guida per la gestione dei rilasci è 15K testo normale ,
   • ha 11 passaggi con un totale di ~ 50 sotto-punti (vedi la ripartizione sotto)
2. la versione viene eseguita dagli sviluppatori ("committer"),
   
   • non hanno tecnico di rilascio dedicato
     ^{suppongo che sia perché è open source, in cui tutti vogliono essere uno sviluppatore}
   • con un processo così complicato che probabilmente dovrebbero avere anche un tecnico di rilascio del backup

Sulla base delle osservazioni di cui sopra, è abbastanza facile capire il ragionamento dietro le loro affermazioni.

La velocità parte della loro richiesta è probabilmente la migliore nella guida di gestione dei rilasci:

To make a monthly release schedule possible, we spread the burden of releases...

Avere un committer che fa i rilasci che richiedono tanto "onere" come da loro guida, oltre a svolgere regolarmente lavori di sviluppo, difficilmente permetterà loro di rilasciare mensilmente - più probabilmente due o tre volte meno frequentemente - e anche questo andrebbe solo fino a che "il solo committer del capro espiatorio" che fa i rilasci si annoierebbe e lascerebbe il progetto.

La stabilità parte del reclamo deriva molto probabilmente dal fatto che il processo di rilascio e la sua documentazione sono piuttosto complicati. La rotazione dei ragazzi che eseguono il processo e l'utilizzo della documentazione fornisce revisione permanente del processo e guida , mantenendoli aggiornati e sincronizzati.

Appendice: analisi della guida del manager di rilascio

I. Preparations During the Month Before a Release
8 sub-points

II. Get the Most Recent Changes
2 sub-points

III. Update the Release Version
10 sub-points

IV. Push Changes to the GitHub Repository
4 sub-points

V. Prepare the Release Tarballs
5 sub-points

VI. Tag the Release Commit
2 sub-points

VII. Push Tarballs to the FTP Server
6 sub-points

VIII. Release Announcement
3 sub-points

IX. Update the Website
7 sub-points

X. Update parrot.github.com and the Relevant parrot-docsx Repository
1 sub-point,...
...plus "more information about the update process" referring to release_parrot_github_guide.pod which incidentally contains 4 more sub-points

XI. Publicity
6 sub-points

Penso che il ruolo di un Release Manager sia leggermente diverso dal ruolo di uno sviluppatore principale, a seconda delle dimensioni del team / organizzazione di sviluppo.

ITIL v3 descrive il ruolo di un gestore di rilascio come:

The Release Manager is responsible for planning and controlling the movement of Releases to test and live environments. His primary objective is to ensure that the integrity of the live environment is protected and that the correct components are released.

L'RM è fondamentalmente responsabile e responsabile dei seguenti sottoprocessi:

• Supporto per la gestione delle versioni
• Pianificazione della versione
• Crea versione
• Rilascio distribuzione
• Supporto per la vita in anticipo
• Chiusura di rilascio

Credo che avere forti processi di gestione del rilascio e una RM strong possa certamente migliorare la stabilità del progetto, tuttavia - non sono convinto che migliorerà la velocità. Esiste anche un rischio intrinseco nell'avere una sola persona responsabile del ruolo di gestione del rilascio. Come con qualsiasi cosa in cui hai una persona primaria che sa cosa fare / cosa sta succedendo, ci deve essere una pianificazione di emergenza in atto nel caso in cui la persona non sia disponibile o indisposta (ad esempio, colpita da un autobus).

Release management is something that requires a good understanding of all parts of the code and the authority to make calls under pressure if issues come up during the release itself

Avendo processi (e documenti) appropriati (e documentati) e autorizzando la RM a prendere decisioni, dove un'altra persona entra nel ruolo che dovrebbero essere in grado di assumere il ruolo con relativa facilità - fornendo trasparenza a tutti i processi e le pratiche. La RM dovrebbe anche essere in contatto con lo Sviluppatore principale per la consulenza tecnica (se del caso) prima di prendere decisioni in merito al rilascio. Ciò garantisce che le decisioni corrette vengano prese in base alle informazioni fornite dal team di sviluppo.

The less change we can have to the release process the better from an operational perspective

Vedi il mio precedente punto, a condizione che l'RM sia governato da una serie di politiche e processi che richiedono un processo di modifica / revisione prima di essere modificati - non ci dovrebbe essere alcuna destabilizzazione durante il processo di rilascio.

Don't really want an engineer to have to learn all this stuff on the job as well as have other things to take care of (regular development responsibilities)

Questo dipende dalla cultura della squadra / organizzazione. Potresti avere un team dedicato di RM che ruotano durante i cicli di rilascio ed eseguono altri compiti quando non hanno una "grande versione" da seguire.

Dove c'è una versione che contiene requisiti / caratteristiche / ecc. complessi, sarebbe anche una buona idea avere qualcuno che conosca queste modifiche come la RM - come se fossero nella posizione migliore per prendere decisioni sulla qualità e la stabilità del codice che deve essere rilasciato. Come affermato in precedenza, disporre di buone politiche / procedure / documentazione relative al processo di rilascio implica che il ruolo non debba essere troppo lungo per consentire a qualcuno di intervenire.

Quando si parla di velocità di progetto, non credo che avere una rotazione RM lo migliorerà, poiché avere una bassa velocità non è generalmente dovuto al fatto che le pratiche di gestione dei rilasci sono cattive, o il Release Manager stesso - di solito fa parte di un problema più profondo / più ampio all'interno del team di sviluppo.

Complessivamente - penso che la rotazione del ruolo sia generalmente una buona idea, in quanto fornisce una maggiore trasparenza al processo e condivide la conoscenza e l'esperienza tra i membri del tuo team. Ciò significa che in qualsiasi momento, qualcuno dovrebbe essere in grado di intervenire nel ruolo di RM in caso di "emergenza". Avere sempre una RM di backup per quella attualmente delegata dovrebbe essere a posto, nel caso in cui il bus arrivi e cancelli il tuo RM.