Boss è scettico sull'uso di un sistema di controllo della versione per un nuovo progetto, dovrei comunque?

Vedi /software/109817/superior-refusing-to-use-subversion

La mia domanda è simile, ma qui ci sono le principali differenze nel mio scenario:

• Stiamo iniziando un nuovo progetto da zero, utilizzando PHP e la tecnologia web. Non ci sarebbero tempi di fermo nello sviluppo in quanto lo adotteremmo dall'inizio, se potessi.

• Il mio team di sviluppo è composto da me e dal mio capo. Siamo il dipartimento "IT" di un'azienda relativamente piccola.

L'app Web sostituirà un'applicazione legacy senza alcun controllo del codice sorgente. A causa delle variazioni dei requisiti legali geografici, è stata presa la decisione (prima che venissi assunto) di raggruppare l'app in 7 directory completamente separate per ogni versione. Diversi sviluppatori hanno fatto cose diverse in luoghi diversi in momenti diversi dopo quello. Correggere le modifiche tra loro, beh, penso che potrebbe essere fatto meglio, credo sia per questo che sto postando.

La proposta del mio capo, incollata direttamente da un'e-mail:

• Gli aggiornamenti devono essere inviati come pacchetti nella cartella SUBMISSIONS. Il pacchetto deve contenere tutti i file pertinenti, nonché un file "UPDATE.NFO" che contiene una descrizione dell'aggiornamento, un elenco di tutti i nuovi file inclusi (con descrizioni) e un elenco di tutti i file modificati con dettagli di modifica.

• I pacchetti di aggiornamento dovrebbero concentrarsi su un singolo elemento e non deviare dallo scopo previsto. Il codice deve essere progettato per essere modulare e riutilizzabile quando possibile.

• Tutti i pacchetti inviati devono essere installati nell'ambiente di test di ciascuno sviluppatore subito dopo l'invio. Ogni sviluppatore deve rivedere la nuova aggiunta e dare voce a qualsiasi preoccupazione sulla sua installazione nell'ambiente di produzione. Un aggiornamento del pacchetto standard deve essere conservato per un minimo di 3 giorni lavorativi per questo processo di revisione prima di essere caricato nell'ambiente di produzione. Aggiornamenti / correzioni ad alta priorità possono saltare questo requisito.

Il motivo per cui è stato inventato il controllo del codice sorgente è rendere tutto automatico, giusto? Ho suggerito sovversione, perché è quello che ho usato al college. Al boss non piace la sovversione perché "Fa un casino del codice" (cioè usa la magia binaria e non è chiaramente leggibile). L'abbiamo provato una volta, ma penso che provare ad usarlo su Windows abbia fatto strani errori in maiuscolo / minuscolo e non siamo riusciti a controllare i nostri file. Non so se sia discutibile solo la sovversione o tutti i prodotti di controllo del codice sorgente.

Quindi, che tipo di argomento dovrei presentare al mio capo? O ha ragione, e potrebbe esserci il pericolo di perdere tutto il nostro lavoro da qualche strano bug?

O mi sbaglio del tutto? Il controllo del codice sorgente è davvero necessario nella mia situazione? Questo è il nostro principale software business-critical di cui stiamo parlando, quindi finirà enorme senza dubbio. Ma ci sono solo 2 sviluppatori (ora).

Inoltre, se non riesco a convincerlo, sarebbe utile che lo usassi solo per me stesso? Sto parlando come qualcuno con un'esperienza molto limitata che utilizza effettivamente svn; tutto quello che so è checkout e commit. Quali sono le caratteristiche del controllo del codice sorgente (che possono includere altri prodotti oltre a svn) che mi aiuterebbero nel mio sforzo di sviluppo individuale?

Per favore, nessun commento "trova un altro lavoro". Non è utile al dibattito.

Non chiederglielo Non dirglielo. Mostragli.

Installa svn, o git, o quello che ti piace su qualche macchina aggiuntiva. Esercitati a usarlo da solo fino a quando non ti senti a tuo agio non solo nell'usarlo, ma nel spiegarlo. Se hai intenzione di metterlo a tuo agio con il tuo nuovo sistema, dovrai essere più che a tuo agio con te stesso. Dovrai essere in grado di aiutarlo a recuperare facilmente quando sbaglia un'unione o controlla qualcosa nel posto sbagliato.

Quando sei pronto, mostragli esattamente di cosa stai parlando. Dimostragli che non "fa casino" di niente. Fai notare che non solo ti consente di recuperare facilmente qualsiasi versione precedente del tuo codice, ma anche di sapere esattamente cosa è cambiato tra le due versioni.

Fai notare che se qualcosa dovesse succedere al server (bug grave, virus, hacker, crash del disco ...) sembrerai entrambi eroi se riesci a ricostruire immediatamente la versione necessaria. Ricorda anche che avrai un aspetto doppio se sei in grado di produrre qualsiasi versione su richiesta. Cerca nella tua vecchia e-mail e compila un elenco di problemi che hai avuto nell'ultimo anno che avresti potuto evitare con il controllo della versione.

Dagli un cheat sheet che gli consentirà di utilizzare facilmente il tuo sistema di controllo della versione.

Infine, suggerisci alcune opzioni ma lascia a lui la decisione . Dovresti configurare il tuo server o utilizzare uno dei tanti servizi ospitati ? Dovresti usare svn, git o qualcos'altro? Dovresti migrare tutti e sette i progetti sul sistema o provarlo con uno o due all'inizio?

I vantaggi del controllo del codice sorgente vanno ben oltre il consentire a più sviluppatori di lavorare su un singolo codice. Eric Sink, il fondatore di SourceGear , elenca alcuni motivi convincenti per utilizzare il controllo del codice sorgente come unico sviluppatore :

- It's an undo mechanism.
- It's a historical archive.
- It's a reference point for diff.
- It's a backup.
- It's a journal of my progress. 
- It's a server. 

Eric capita anche di avere un ottimo controllo del codice sorgente per principianti . Esiste un tutorial Mercurial online gratuito disponibile da Joel Spolsky, Mercurial è un popolare sistema di controllo della versione distribuita.

Come passaggio successivo ti suggerisco di iniziare a utilizzare il controllo del codice sorgente localmente sul tuo computer, come unico sviluppatore. Molto presto il tuo capo noterà che sei capace di pura magia, come dire in pochi minuti, se non in secondi, quanto tempo fa un bug super critico e poi gli dirai con precisione quali account dei clienti sono stati colpiti e devono essere riparati prima di tutto l'inferno si scatena. O essere in grado di annullare qualsiasi modifica che il CEO non approva in modo superveloce.

E infine, prima di provare a convincere il tuo capo, potresti voler approfondire l'argomento della gestione delle obiezioni . Sono 101 le vendite.

Se non ha successo, vai avanti il ​​più presto possibile, non ha molto senso sprecare il tuo tempo inclinandoti sui mulini a vento.

Sì, usare il controllo del codice sorgente, anche se solo per te, è totalmente utile. Git, ad esempio, funziona davvero bene per uno sviluppatore autonomo e ti consente di fare cose come diramare e unire (con il minor costo possibile) e modificare le modifiche mentre procedi.

SVN - o qualsiasi sistema di controllo della versione, in realtà - ti consente di farlo anche tu, ma l'unione è un po 'più problematica.

Se non riuscissi a convincerlo, sarebbe utile che lo usassi solo per me stesso?

Sì. C'è un vantaggio nell'usarlo solo per te stesso. Ottieni la cronologia delle modifiche in modo da poter vedere cosa c'è di diverso.

No. Non ci sono vantaggi perché il tuo capo ha condannato il tuo progetto a molte inutili rielaborazioni perché hanno rovinato le cose.

Consiglio vivamente come detto prima dell'uso di git, il motivo n. 1 è perché qualsiasi VCS è una rete di sicurezza in caso di disastro. Cerca l'adesivo "In caso di incendio: git commit, git push, lascia l'edificio". Il codice può essere memorizzato da qualche altra parte, ma no in un laptop che può rompersi, essere rubato o altro ... anche un server di rete locale non è il posto più sicuro per qualcosa di prezioso come il codice.

Numero 2. Tracciabilità dei cambiamenti, chi ha fatto cosa, quando, ecc ... Unisce, Annulla. Numero 3. Diff lo strumento magico per # 2 e molti altri casi. Numero 4. Filiali Numero 5. Contrassegnare versioni, rilasci, ecc.

Puoi trovare maggiori informazioni su uno dei flussi di lavoro git più comuni qui: https://nvie.com/posts/a-successful-git-branching-model/

So che inizialmente usare git può essere intimidatorio, ma è un buon investimento per un'abilità e un must per qualsiasi team di sviluppo.

A proposito del tuo problema con il caso di testo, evita di usare Tortoise, so che molte persone lo usano come una GUI per git, dato che era molto comune per SVN, quindi potrebbe essere la prima scelta, invece usa la riga di comando o un'altra GUI come github desktop o il SourceTree di Atlasian.