Controllo di sovversione / sorgente solo per codice di produzione?

Mi sono laureato in Informatica un anno fa e ora lavoro in una piccola società di sviluppo web (io e un altro sviluppatore, oltre a manager, servizio clienti e tester). Fino a poco prima di iniziare, non esisteva un sistema di controllo del codice sorgente. Ora stiamo lentamente iniziando a implementare SVN, ma l'altro sviluppatore (senior) (d'ora in poi chiamato Joe) insiste sul fatto che l'unico codice che dovrebbe essere impegnato nel nostro repository SVN è quello che è stato testato e approvato come pronto per la produzione. Ciò significa che, su progetti più grandi, potrebbero non esserci impegni per settimane o più alla volta.

È una pratica normale? Mi sembra che perdiamo molti dei vantaggi del controllo del codice sorgente, tra cui:

• Tracciamento dettagliato dell'avanzamento del progetto
• Tracciamento dei problemi come appaiono e vengono risolti
• Rollback facile degli errori
• Facile backup del codice, quindi non perdiamo molto se una workstation si arresta
• È più facile identificare esattamente quale codice è in esecuzione in quali siti di produzione, supponendo che noi stampiamo le revisioni in file eseguibili come descritto qui
• Collaborazione semplice (anche se non facciamo alcun lavoro di squadra; sono tutti progetti da solista)
• Eccetera.

EDIT: dovrei sottolineare che storicamente, non c'è stato alcun vero lavoro di squadra in questa azienda; solo due sviluppatori che lavorano su progetti separati. Inoltre, molti progetti sono piccoli, quindi possono essere completati in un paio di settimane. E la società è in attività da più di un decennio e va d'accordo senza controllo del codice sorgente. I progetti vengono generalmente completati entro i tempi previsti.

Se i progetti vengono completati entro i tempi previsti, è sicuro presumere che i clienti siano clienti soddisfatti? :)

Sembra che la società stia iniziando ad affrontare anche nuovi tipi di progetti e attraversando alcuni dolori crescenti o alcuni "dolori mutevoli". Molte supponendo che succedano qui ... Per favore abbi pazienza!

Se sei sicuro che l'organizzazione e il controllo del codice possano aiutare te e il tuo team internamente, allora dovresti prendere in considerazione SVN, IMHO. Ottieni punti bonus se andare su questa strada funziona davvero e la società è in grado di realizzare prodotti di qualità superiore, rendendo così i clienti più felici!

Fai attenzione se sembra che una lotta con il management creerà un ambiente di lavoro teso. Il fatto è che i proprietari hanno creato l'azienda. E non solo, hanno creato un'azienda di successo. È improbabile che colpiscano un jackpot perché sono bravi a giocare d'azzardo.

Sii rispettoso e potresti finire per essere ascoltato.

Speriamo che questo finisca per dare vita a una squadra più efficiente e più felice. Nella mia esperienza, è difficile da ottenere con una gestione frustrata.

Joe ha praticamente torto. Ora, puoi sostenere che hai un ramo "pulito" che rappresenta il codice verificato e pronto per la produzione. Ma non usare il controllo del codice sorgente finché le cose non sono pronte è francamente autolesionista. Un po 'come provare a fare un martini senza gin.

Il "senior" è in realtà molto poco qualificato. Qualsiasi codice che può essere compilato (e supera i test se li hai) dovrebbe essere impegnato nel controllo del codice sorgente. Il controllo del codice sorgente è una risorsa centrale per la condivisione del codice e la creazione di SW in modo incrementale.

L'aspetto positivo è la separazione del codice di produzione (ultima versione stabile) ma in tal caso i sistemi di controllo del codice sorgente contengono funzionalità come tag / etichette e rami.

Il nostro team è molto sospettoso se qualcuno non commette nulla entro due-tre giorni. Significa che ha dei problemi e forse ha bisogno di aiuto. Un altro punto di controllo del codice sorgente è che di solito viene regolarmente eseguito il backup, il che non è il caso delle macchine di sviluppo. Se il disco si blocca, perdi il lavoro per diverse settimane.

Mettendo da parte la questione se Joe abbia ragione o torto (ha torto, a proposito), mi sembra che un compromesso potrebbe essere raggiunto se si utilizzasse un sistema di controllo di versione distribuito come Git o Mercurial .

In questo modo, te stesso e gli altri sviluppatori lavorerebbero sul tuo repository locale, impegnando le modifiche al controllo del codice sorgente in anticipo e spesso, ma non spingendo le modifiche al repository "produzione" fino a quando non vengono "testate e approvate come pronte per la produzione". Avresti avuto una storia completa di tutto ciò su cui hai lavorato nel corso delle settimane e Joe avrebbe avuto un repository incontaminato che aveva solo la storia dei cambiamenti che sono stati benedetti come pronti per la produzione.

Non ha senso, proprio per i motivi che hai elencato. È come usare il controllo versione senza i vantaggi dell'uso del controllo versione.

Credo che Joe non abbia capito che i sistemi di controllo del codice sorgente non sono backup glorificati delle versioni di produzione del codice sorgente, ma uno strumento utile per i programmatori mettendo le parole sui piccoli passi del progresso e della maturazione del codice per il tuo futuro sé e colleghi. Forse Joe non è abituato a lavorare in team con codice di altre persone?

Hai mai considerato "perché è stata aggiunta questa riga di codice"? Individua il commit che lo ha introdotto e vedi il suo commento. Se ti impegni solo quando vai in produzione, i commenti non saranno abbastanza specifici da essere utili per te.

Suggerirei anche di utilizzare uno strumento più potente di SVN. Puoi vedere una buona introduzione sulle possibilità su http://hginit.com/ di Joel Spoelsky.

Usa mercurial e al giorno d'oggi ci sono molti contendenti. Git è considerato molto potente e https://github.com/ ha alcuni strumenti molto, molto utili e fornisce account di avviamento gratuiti in modo da poterlo provare davvero.

Joe non sembra conoscere SVN, cerca di scoprire Branches, Tag e Trunk ... I tag sono coerenti con ciò che Joe vuole. Alcune letture sulle migliori pratiche SVN non farebbero male

Non ho mai usato SVN, quindi non so quali sarebbero le procedure per questo. Stiamo usando ClearCase e la pratica qui è per ogni sviluppatore di avere il proprio ramo di sviluppo, quindi un ramo di integrazione a cui ci uniamo quando siamo pronti per iniziare i test e uno o più rami di rilascio per codice integrato e testato .

Joe è un hacker, non uno sviluppatore. Sembra un ottimo hacker, ma ha torto su come usare il controllo di revisione. Quindi cosa fare al riguardo?

Mi sembra che la tua organizzazione abbia un investimento in SVN, e sarebbe una carriera limitarti a sfidare Joe e invalidare l'investimento in dollari nel server SVN. Imposta un repository GIT e usa l'interfaccia git svn per lavorare come vuoi (Questo è tutto software gratuito e richiederà da un'ora a un giorno per l'installazione, tutto sulla tua workstation). Socializza il tuo flusso di lavoro con Joe: può preservare il suo sistema di credenze "non inquinato SVN repo" e mantenere la sua credibilità sul costoso elefante bianco nell'angolo (e sull'ego).

Tra poco mi aspetto che Joe guarderà come lavori, e inizierà a fare lo stesso. Tra un anno o due, il server SVN diventerà un repository Git.

Potresti provare a convincere Joe con gli argomenti sopra. Se questo non riesce, usa SVN localmente per il tuo lavoro di sviluppo e spera che a volte venga raccolto da Joe. Se non riesci a convincerli con argomenti, fai ciò di cui sei convinto e mostragli che funziona. Tipo di approccio distribuito ma con gli strumenti esistenti.

Ho intenzione di echeggiare @ Carson63000 qui e dire che ho già visto questo atteggiamento prima, ed è in gran parte causato dalle orribili capacità di ramificazione / fusione del VCS. Avere un ramo che compila e supera i test, con i tag per ogni versione, è un ottimo approccio ma non dovrebbe essere seguito al punto che nessun altro codice è stato impegnato. Il DVCS in generale, e git in particolare, rendono la ramificazione un'operazione facile e comune e riduce molte difficoltà con questo flusso di lavoro.

Il motivo per cui i sistemi di controllo della versione supportano i tag è perché è possibile taggare il codice certificato e continuare a impegnarsi nel lavoro quotidiano. Ogni volta che si dispone di un codice di qualità della produzione, lo si commette grattugiando un tag e il gioco è fatto. Conosci il punto esatto in "tempo" che devi tornare indietro per ottenere ciò che il cliente ha. E puoi sempre controllare e confrontare diverse versioni del tuo codice. In questo modo puoi essere soddisfatto di ciò che hai nel database di controllo del codice sorgente. Funziona per l'azienda per cui lavoro, che ha 100 sviluppatori, tutti impegnati nello stesso progetto. Funzionerà sicuramente anche per te.

È abbastanza comune archiviare oggetti nei sistemi di controllo della versione che sono pronti per la consegna alla produzione. È così che è stato fatto storicamente per decenni, dai tempi antichi in cui l'archiviazione su disco costava centinaia di dollari per megabyte e archiviare tutto era semplicemente troppo costoso.

Non è più considerato il modo migliore per fare le cose, ma posso capire appieno perché le persone lo fanno ancora, poiché molti sistemi di controllo della versione precedente sono ancora in uso che rendono difficile se non impossibile fare qualsiasi altra cosa e mantengono ancora la conoscenza di ciò che il tuo ogni versione è (o meglio, non c'è modo di sapere quale sia una versione senza controllare i tag su ogni singolo file se è necessario tornare indietro. Ho visto più di un repository in cui l'unico modo per ripristinare un vecchio la versione doveva recuperare dal repository un file zip con il codice sorgente e i binari per quella versione).