Quantificazione dei vantaggi di un moderno sistema di controllo della versione [chiuso]

Ho lavorato come team leader / sviluppatore in un grande ambiente di impresa finanziaria per la parte migliore di tre anni. Il nostro processo di rilascio in produzione è un incubo perché ruota attorno a Clearcase. Abbiamo un gruppo di gestione delle modifiche che esegue tutte le versioni e che consentirà solo la produzione del codice che è stato preso da essa.

Una delle prime cose che ho fatto quando mi sono unito è stata quella di formare la mia squadra con Git. Tutti concordarono sul fatto che Clearcase fosse orribile e poco pratico per gestire le questioni quotidiane sul controllo delle fonti. Quindi abbiamo creato una sorta di repository "non ufficiale" sul mio computer locale e ho scritto uno script per sincronizzare i repository git e Clearcase al momento del rilascio.

La notizia si è diffusa ad altri team e molti hanno adottato lo stesso processo. Usare git in modo "non ufficiale" per le attività quotidiane e "ufficialmente" usare Clearcase per le versioni. Sono diventato una specie di go to guy per eventuali problemi con Git.

Quindi questa settimana ho un incontro con l'SVP nel cambio di infrastruttura che vuole specificamente che le spieghi i meriti di Git. Apparentemente la notizia le è arrivata delle mie frequenti assenze su Clearcase. Se accetta le mie argomentazioni, avrò una vera possibilità di aiutare il mio datore di lavoro a liberarsi di questo abominio.

La mia esperienza con i dirigenti mi dice che a) vogliono spiegazioni estremamente concise per tutto b) sono interessati solo a fatti che coinvolgono cifre in dollari

A uno sviluppatore posso spiegare i meriti di Git su Clearcase (o QUALSIASI altro sistema di controllo della versione su Clearcase per quella materia), ma sto disegnando uno spazio su come fare questo a un dirigente tecnico senza un background tecnico (ha un MBA e ha conseguito la laurea in geografia).

Sento che qualsiasi argomento che le faccio o suonerà come una sciocchezza tecnica o che sto evangelizzando le mie preferenze personali.

Quello che sto cercando di trovare sono fatti concreti che dimostrano che gli sviluppatori lavorano in modo più efficace con Git o QUALSIASI moderno sistema di controllo del codice sorgente.

Penso che il fatto che le altre squadre abbiano iniziato a usare Git internamente sia un segno significativo, ma non è ancora abbastanza forte perché può ancora essere respinto come preferenza personale.

Ciò di cui ho veramente bisogno è qualcosa di abbastanza potente da superare il "Questo processo ha funzionato per 20 anni, perché dovremmo cambiarlo?" discussione.

Sono stato in situazioni molto simili (nell'industria aerospaziale e automobilistica). Non aspettarti di progredire molto in questo o negli incontri successivi. Entrambe queste situazioni hanno superato il mio desiderio di continuare a lottare per il miglioramento, ma ecco la migliore tattica che ho visto finora ...

Dici "questo processo ha funzionato per 20 anni", ma ha davvero? Inizia descrivendo cosa intendi con "il nostro processo di rilascio della produzione è un incubo". Crea un elenco di problemi con l'attuale processo / strumento che sia il più agnostico possibile di ClearCase.

Quindi, crea un elenco di "soluzioni" di processo / strumento che siano il più agnostico possibile di Git (sebbene Git o qualsiasi DVCS moderno si adatteranno esattamente al conto). Spiegare perché Git è migliore di ClearCase non significa nulla per i non utenti.

Consentire al team dell'infrastruttura di confermare che l'approccio attuale presenta i problemi identificati. Ciò probabilmente li porterà a chiedere supporto a IBM per "risolvere" questi problemi. Rimani connesso per assicurarti che IBM non affronti i problemi. Poiché ClearCase è privo delle proprietà di base della nostra moderna comprensione del controllo della versione, la maggior parte di questi problemi non può essere risolta o richiederà una grande modifica dell'infrastruttura.

Speriamo che a questo punto, il team dell'infrastruttura vedrà questo come un problema aziendale, ma senza una soluzione semplice. A questo punto, offri di confrontare soluzioni aggiuntive con costi stimati. Poiché molti dei tuoi team stanno già utilizzando Git, dovresti essere in grado di rimuovere l'addestramento come spesa.

In bocca al lupo!

Il nostro processo di rilascio in produzione è un incubo perché ruota attorno a Clearcase. Abbiamo un gruppo di gestione delle modifiche che esegue tutte le versioni e che consentirà solo la produzione del codice che è stato preso da essa.

No, il tuo processo è un "incubo" a causa del tuo gruppo di gestione delle modifiche e delle tue procedure di rilascio. Vai avanti e sostituisci Clearcase per SVN o git o Fossil. Avrai gli stessi identici problemi . (Penso che stiano facendo bene TBH, i controlli di rilascio forti sono essenziali).

Questo è ciò su cui devi concentrarti, non le credenziali geek di git (che sono irrilevanti per tutti tranne gli sviluppatori), devi concentrarti sul business case per cambiare il processo per renderlo meno oneroso. È probabile che tu possa farlo usando Clearcase, ma ti dà l'opportunità di intrufolare l'idea di usare git in ogni caso.

Se non guardi il "quadro più grande" qui, nel migliore dei casi potrai usare git con le stesse restrizioni richieste dal gruppo di rilascio. Se prendi in considerazione gli aspetti più ampi di ciò a cui serve il controllo delle modifiche, apprezzerai le restrizioni che dovrai implementare per rendere git utile nel tipo di processo di rilascio fortemente controllato di cui la tua organizzazione ha bisogno.

Alcune idee per te: fagli vedere i problemi di produttività con il sistema attuale dal punto di vista degli sviluppatori. Fallo come parte 1 di 2. Parte 2, vai e lavora con loro in una versione in modo da poter vedere i problemi di controllo che gli sviluppatori devono capire. Consideralo come un esercizio di apprendimento per entrambe le parti per visualizzare la vista dell'altra parte, e quindi dovresti essere in grado di trovare una soluzione che risolva ancora i requisiti principali che entrambe le parti hanno. Nota che le versioni sono più importanti degli sviluppatori, quindi dovresti essere tu quello disposto a dare terreno più di quanto ti aspetti.

Una volta che hai la conoscenza di ciò che è richiesto per le versioni, dovresti concordare di scrivere un documento di processo dettagliato (con i dettagli dettagliati da seguire) che puoi mostrare loro dando loro ciò di cui hanno bisogno. Come puoi massaggiarlo in modo che il lato dev sia meglio per te dipende da te. Immagino che a loro non importi davvero come dev dev, purché l'origine sia gestita correttamente e le pubblicazioni siano organizzate correttamente - ciò significa che dovrai mostrare come le modifiche al codice possono essere legate ai cambi di ticket, come prendere il codice che ha fatto una versione per patch, compilare e rilasciare nuovamente.

Esempi specifici impressioneranno più dei vantaggi astratti. Penso che troverai maggior successo se riesci a documentare esempi particolari in cui (a) Clearcase ha causato problemi che hanno richiesto tempo per risolversi e (b) Git risolve tali problemi. Ricorda che non hai bisogno di entrare nei dettagli tecnici del perché questo è (a meno che non sia richiesto) semplicemente dimostrarlo; la gestione non ha bisogno di conoscere i tecnicismi, questo è ciò per cui sei pagato.

Se riesci ad allegare scadenze e date specifiche a questi esempi, tanto meglio. Potresti anche essere in grado di completare mostrando il compito X che fai molto richiede Y minuti in Clearcase e Z minuti in Git.

Ricorda che il tempo è denaro, quindi se puoi dimostrare che lavorare con Git è più veloce , puoi dimostrare che avrà anche senso finanziario.

Ecco un tentativo di come lo proverei.

Può sembrare stupido per uno sviluppatore, ma per il management i cambiamenti tecnologici sono considerati rischiosi.

"Se la cosa magica funziona già, perché correre il rischio di romperla?"

Quindi, devi girare il tavolo. Rendi più rischioso non passare a git. A tutti i costi, non far sembrare che sia un nuovo giocattolo.

Vorrei iniziare dicendo che Git è ora ampiamente usato. Usa numeri, come quelli: http://ianskerrett.wordpress.com/2014/06/23/eclipse-community-survey-2014-results/

Per un manager, questo implica che dovrebbero essere in grado di trovare molti sviluppatori che usano git. E un intero ecosistema di strumenti di terze parti (ho sentito che persino Microsoft integra git con Visual Studio ora).

Inoltre, un manager non può davvero essere accusato di seguire le cose tradizionali, vero? Al contrario, chi usa $ other_cvs qui?

Metti l'accento su come i grandi progetti lo stanno usando, perché è semplice, veloce, flessibile, potente ... Trova grandi progetti con grandi nomi collegati (GNU / Linux, Google, Microsoft ...) che usano git.

Avendo dimostrato che non può essere una mossa sbagliata, puoi quindi passare a come migliorerebbe le cose nel tuo caso.

Volete che l'azienda rimanga competitiva e non sia superata da squadre più veloci e più agili, giusto? Vorrei provare a trovare alcune stime interne (scritte) su come è cambiata la produttività usando Clearcase vs Git. Puoi usare un po 'di aiuto dai tuoi colleghi sviluppatori lì. Quindi estrapolare per l'intera azienda (es. Tutti gli sviluppatori di software), con numeri e costi stimati per stare con Clearcase.

Vorrei anche ricapitolare il tutto in una e-mail scritta dopo l'incontro (includere le persone giuste).

Ciò di cui ho veramente bisogno è qualcosa di abbastanza potente da superare il "Questo processo ha funzionato per 20 anni, perché dovremmo cambiarlo?" discussione.

Questo è un argomento non valido (le carrozze trainate da cavalli "hanno funzionato per secoli", ma probabilmente si desidera acquistare un'auto).

Ho sentito lo stesso argomento su svn vs. mercurial (ero io a usare mercurial sul mio sistema di sviluppo).

Questo problema non riguarda la sostituzione di ciò che funziona; Non provare a formularlo come tale, e se questa è la domanda che devi "sconfiggere", dovresti iniziare sottolineando che non si tratta di ciò che funziona o meno, ma di quali vantaggi hai con git , quando entrambi funzionano (e perché git funziona meglio).

Buoni argomenti per usare git:

• git è centrato sul changeset invece che sul file. Ciò significa che le modifiche sono più facili da tracciare attraverso i file (tracciabilità attraverso il progetto).

• git è distribuito anziché centralizzato; Ciò significa che il check-in non è limitato dalla velocità della rete, risparmiando ancora molto tempo. Significa anche che non hai un singolo punto di errore nel caso in cui il tuo server ClearCase non funzioni.

• a causa del suo sistema di diramazione, git minimizza la necessità di unire (cioè non unire i file ad ogni check-in, ma ad ogni funzionalità completata). Passa dalla risoluzione dei conflitti di unione (se presenti) alcune volte al giorno (ad ogni commit) a una o due volte alla settimana (su ogni funzione completata). Ciò significa più tempo di sviluppo per i tuoi sviluppatori (qualcosa che i gestori vorranno massimizzare).

Penso che il fatto che le altre squadre abbiano iniziato a usare Git internamente sia un segno significativo, ma non è ancora abbastanza forte perché può ancora essere respinto come preferenza personale.

Puoi sottolineare che la differenza qualitativa è così grande , che gli sviluppatori della tua azienda preferiscono le complicazioni dell'installazione, della configurazione e dell'utilizzo di git, oltre a Clearcase, per le sue funzionalità extra. In realtà è un argomento forte (se non ha fornito un'esperienza utente e set di funzionalità alltogether meglio, la gente non andare il miglio supplementare per utilizzarlo - soprattutto perché si tratta di qualcosa non è richiesto dalla società).

Quindi questa settimana ho un incontro con l'SVP nel cambio di infrastruttura che vuole specificamente che le spieghi i meriti di Git.

Disegna un grafico che rappresenta i commit con i due sistemi e mostra la semplificazione ottenuta dagli sviluppatori che non si impegnano pubblicamente (ad esempio, se esegui il borking di un file, il resto del team non viene bloccato e non è in grado di compilare fino a quando non lo risolvi). Spiega anche i controlli di qualità extra che puoi effettuare quando puoi effettuare commit di intermediari senza influenzare nessun altro, il fatto che puoi ottenere differenze pulite per funzione (essenziale per le revisioni del codice).

Ciò di cui ho veramente bisogno è qualcosa di abbastanza potente da superare il "Questo processo ha funzionato per 20 anni, perché dovremmo cambiarlo?" discussione.

È difficile giudicare davvero quale sarebbe una buona discussione senza essere un testimone della scena. Ma proverò ad aiutarti a inquadrare i tuoi argomenti in modo che possano essere ascoltati.

Presumo che il tuo pubblico abbia un livello di conoscenza non esperto sull'argomento e sia interessato a mantenere il corso attuale. Hanno diverse preoccupazioni e responsabilità e possono subire gravi conseguenze se qualcosa va storto, quindi dovrai lavorare da quella mentalità. Anticipare alcune delle domande o preoccupazioni che potrebbero avere:

• Quali nuove funzionalità porterebbe questo? C'è qualcosa che attualmente non possiamo fare, che vorremmo fare e che questa nuova cosa ci permetterebbe? Inizia con una nota positiva.

• Qual è l'impatto sui programmi di rilascio? Qual è il costo dell'implementazione di questa modifica verso la versione immediatamente successiva? Quali sono i costi e i vantaggi delle seguenti versioni?

• Ciò comporterà un cambiamento nel processo? A prescindere dal programma di rilascio, questo cambiamento richiederà che le persone nel processo di rilascio cambino strada? Sarà trasparente per loro o dovranno adattarsi? Dovrai collaborare con altri dipartimenti? Le persone sono resistenti ai cambiamenti.

• Ci sono pericoli imminenti per rimanere con l'attuale sistema? L'attuale processo ha dipendenze software o hardware che sono andate o finiranno presto? Fa affidamento su conoscenze specialistiche di individui che aumentano i costi di assunzione? Ha un potenziale buco di sicurezza che il nuovo sistema inserisce (punti bonus se questo buco può portare a un'azione legale)? Non agitare a mano o "forse" o "probabilmente" questo: il senso è che ha funzionato bene per 20 anni, quindi l'onere della prova è a carico del sostenitore del cambiamento.

Inoltre, sii specifico su problemi e soluzioni . Se non riesci a trovare esempi specifici, utilizza stime oneste dalla tua posizione di esperto. Esempi di altre aziende / dipartimenti / entità che adottano tale cambiamento, preferibilmente dal proprio settore, e la loro valutazione di tale cambiamento, ti aiuteranno. (Non scegliere esempi che hanno avuto una sorta di problema IT pubblicizzato negli ultimi anni, o sarà compito tuo dimostrare che questa modifica non è stata la causa.)

È possibile trovare questa risposta per convincere la società per cui lavoro a implementare il controllo versione? utile.