Ho appena saputo di Source Control questa settimana e mi sono reso conto che il mio team lo usa chiaramente.
- Una riga principale per il commit del codice da vivere. Nessun altro ramo; questo è tutto.
- Funzioni di ramificazione disattivate per tutti tranne amministratore
- Le persone creano backup di file manuali e li lasciano sparpagliati, perché non ci sono branching
- Directory di lavoro su unità condivisa: tutti modificano gli stessi file
-
Il checkout è sempre esclusivo, forse in base alla progettazione dei file di unità condivisi
-
Il flusso di lavoro è in genere Edit-Checkout-ImmediateCheckin a causa dei blocchi esclusivi. Dio non voglia che qualcuno abbandoni un progetto per lavorare su qualcos'altro e lo lascia a metà finito sull'unità condivisa
Lo stigma è che il controllo del codice sorgente viene messo in atto per ragioni di responsabilità piuttosto che per la cronologia delle revisioni: il check-in nell'unico ramo attivo richiede un ticket di supporto "quindi non abbiamo un altro spazio ufficio". Il nostro sistema di test è molto più gratuito: compilare il file dall'area dev e rilasciarlo in posizione nell'area di staging (anche una cartella condivisa) e vedere se funziona. Alla gente piace questa libertà.
Stiamo attualmente migrando le nostre applicazioni console alla GUI, quindi molte cose vengono riscritte. Immagino che questo sia il momento migliore per introdurre un cambiamento.
Stavo pensando di aggiungere una seconda linea principale per il nostro nuovo codice che "farai bene questa volta", piuttosto che ripulire il casino che abbiamo ora:
- una nuova mainline per codice live (se solo per i nuovi programmi)
- un ramo Baseline di test sotto questa nuova linea principale per build stabili
- rami di lavoro su richiesta per nuove funzionalità e correzioni di errori
Ho parlato con due dei quattro sviluppatori e ho ricevuto qualche riscontro da loro, ma sono preoccupati delle complicazioni e dei passaggi aggiuntivi che potrebbero portare al loro flusso di lavoro perché non hanno mai usato la ramificazione.
Usiamo Surround SCM accoppiato con TestTrack per i ticket di richiesta di modifica, se questo è importante. Sto proponendo di effettuare il check-in solo nelle filiali private dell'area di lavoro, quindi di promuovere i rami fino alla mainline come meglio crediamo.