Subversion / source control only for production code?

Se i progetti vengono completati entro i tempi previsti, è lecito ritenere che i clienti siano clienti felici? :)

Sembra che l'azienda stia iniziando a intraprendere nuovi tipi di progetti e sta attraversando alcuni dolori crescenti o alcuni "dolori commoventi". Molte assumendo di andare qui ... Per favore, sopportami!

Se sei sicuro che l'organizzazione e il controllo del codice possano aiutare te e il tuo team internamente, è necessario prendere in considerazione l'SVN, IMHO. Ottieni punti bonus se l'itinerario in corso funziona e l'azienda è in grado di realizzare prodotti di qualità superiore, rendendo così i clienti più felici!

Stai attento se sembra che una lotta con il management crei un ambiente di lavoro teso. Il fatto è che i proprietari hanno fatto la compagnia. E non solo, hanno fatto un'azienda di successo. È improbabile che colpiscano un jackpot perché sono bravi nel gioco d'azzardo.

Sii rispettoso e potresti finire per essere ascoltato.

Speriamo che questo finisca per creare un team più efficiente e più felice. Nella mia esperienza, è difficile da ottenere con una gestione frustrata.

Joe è praticamente sbagliato. Ora puoi rendere l'argomento che hai un ramo "pulito" che rappresenta il codice controllato, pronto per la produzione. Ma non usare il controllo del codice sorgente finché le cose non sono pronte è francamente controproducente. Un po 'come provare a fare un martini senza il gin.

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

Il punto buono è separare il codice di produzione (ultima versione stabile) ma per tali casi i sistemi di controllo del codice sorgente includono funzioni come tag / etichette e rami.

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

Mettendo da parte la questione se Joe abbia ragione o torto (ha torto, comunque), mi sembra che si possa raggiungere un compromesso se si usasse un sistema di controllo della versione distribuito come Git o Mercurial .

In questo modo, tu e l'altro sviluppereste il vostro repository locale, commettendo le modifiche al controllo del codice sorgente in anticipo e spesso, ma non trasferirete le modifiche al repository "produzione" finché non saranno "testati e approvati come pronti per la produzione" ". Avresti una cronologia completa di tutti quelli su cui hai lavorato nel corso delle settimane, e Joe avrebbe avuto un repository incontaminato che aveva solo la storia di modifiche che erano state benedette come pronte per la produzione.

Non ha senso, proprio per le ragioni che hai elencato. È come utilizzare il controllo della versione senza i vantaggi dell'uso del controllo della versione.

Credo che Joe non abbia capito che i sistemi di controllo del codice sorgente non sono copie glorificate dei rilasci di produzione del codice sorgente, ma uno strumento utile per i programmatori mettendo le parole sui passi più piccoli del progresso e della maturazione del codice per il tuo sé e colleghi futuri. Forse Joe non è abituato a lavorare in team con il codice di altri popoli?

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

Suggerirei anche di utilizzare uno strumento più potente di SVN. Puoi vedere una buona introduzione sulle possibilità del link di Joel Spoelsky.

Usa mercurial e ci sono diversi contendenti in questi giorni. Git è considerato molto potente e il link ha alcuni strumenti molto utili e fornisce account di avviamento gratuiti in modo che tu possa provarlo per davvero.

Joe non sembra sapere di SVN, prova a scoprire Branches, Tag e Trunk ... I tag sono coerenti con ciò che Joe vuole. Alcune letture sulle best practice SVN non farebbero male a

Mai usato SVN quindi non so quali sarebbero le procedure per questo. Usiamo ClearCase e la pratica qui intorno è che ogni sviluppatore abbia il proprio ramo di sviluppo, quindi un ramo di integrazione a cui ci uniamo quando siamo pronti per iniziare il 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 a riguardo?

Mi sembra che la tua organizzazione abbia un investimento in SVN e sarebbe una carriera che ti limiterà a sfidare Joe e invalidare l'investimento in dollari nel server SVN. Configura un repository GIT e usa l'interfaccia git svn per funzionare nel modo desiderato (questo è tutto il software libero e impiegherà un'ora al giorno per l'installazione, tutto sulla tua workstation). Socializza il tuo flusso di lavoro con Joe - può preservare il suo sistema di credenze "incontinente SVN" e mantenere la sua credibilità sul costoso elefante bianco nell'angolo (e nell'ego).

In breve tempo mi aspetto che Joe guarderà a come lavori e inizierai a fare lo stesso. Tra un anno o due, il server SVN diventerà un repo Git.

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

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

Il motivo per cui i sistemi di controllo di versione supportano i tag è perché puoi taggare il codice certificato e continuare a far funzionare il tuo lavoro quotidiano. Ogni volta che hai un codice di qualità di produzione, lo commetti grattando un tag e hai finito. Sai il punto esatto in "tempo" 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 contento di ciò che hai nel database di controllo del codice sorgente. Funziona per la società per cui lavoro, che ha 100 sviluppatori, tutti che lavorano sullo stesso progetto. Funzionerà anche per te.

È abbastanza comune archiviare le cose solo nei sistemi di controllo delle versioni pronti per essere consegnati alla produzione. È così che è stato fatto storicamente per decenni, dai tempi antichi in cui lo storage su disco costava centinaia di dollari per megabyte e l'archiviazione di tutto era semplicemente troppo costoso.

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