Vedi link
La mia domanda è simile, ma qui ci sono le principali differenze nel mio scenario:
-
Stiamo iniziando un nuovo progetto da zero, usando PHP e la tecnologia web. Non ci sarebbero tempi morti nello sviluppo come lo adotteremmo dall'inizio, se avrò la mia strada.
-
Il mio team di sviluppo è composto da me e dal mio capo. Siamo il dipartimento "IT" di un'azienda relativamente piccola. C'è un altro operatore IT che fa il supporto desktop ma non lo sviluppo.
-
Il mio titolo di lavoro è programmatore; il mio capo è IT Manager. Il livello superiore del management piace al mio capo. Piacciono anche a me, ma probabilmente non abbastanza per darmi l'autorità di scavalcarlo.
L'app Web sostituirà un'applicazione legacy di FoxPro senza alcun controllo del codice sorgente. Infatti, a causa dei requisiti legali, è stata presa la decisione (prima dell'assunzione) di inserire l'app in 7 programmi completamente separati - non solo i file che calcolano le cose che possono variare a seconda dello stato - ma l'intera directory è stata copiata, 7 volte e diversi stati sono stati assegnati a diversi sviluppatori. Le cose divergevano da lì. L'idea del mio capo di controllo della versione è di copiare e incollare interi file sorgente dallo stato in cui sta lavorando, in tutti gli altri stati, sovrascrivendo così quei file. Piccole modifiche vengono registrate manualmente nei file di testo e devono essere copiate e incollate dallo sviluppatore per lo stato di destinazione. Questo non funziona sempre così bene. Sono accusato di aver cambiato le cose e di averle provocate un'interruzione quando questi file sono stati incollati.
La proposta del mio capo, incollata direttamente da un'email:
-
Gli aggiornamenti devono essere inviati come pacchetti nella cartella SUBMISSIONS. Il pacchetto dovrebbe contenere tutti i file rilevanti e 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 i dettagli delle modifiche.
-
I pacchetti di aggiornamento dovrebbero concentrarsi su un singolo elemento e non allontanarsi dal suo scopo. Il codice dovrebbe essere progettato per essere modulare e riusabile quando possibile.
-
Tutti i pacchetti inviati devono essere installati nell'ambiente di test di ciascun sviluppatore subito dopo l'invio. Ogni sviluppatore deve rivedere la nuova aggiunta e comunicare eventuali dubbi sulla sua installazione all'ambiente di produzione. Prima di essere caricato nell'ambiente di produzione, è necessario tenere un aggiornamento del pacchetto standard per almeno 3 giorni lavorativi per questo processo di revisione. Gli aggiornamenti / correzioni ad alta priorità possono saltare questo requisito.
(email finale)
Il motivo per cui il controllo del codice sorgente è stato inventato è di rendere tutto automatico, giusto? Ho suggerito la sovversione, perché è quello che ho usato al college. A Boss non piace la sovversione perché "Fa casino del codice" e le persone su Internet gli hanno detto che non andava bene. (Dove sta guardando ???) Non so se non gli piaccia solo la sovversione, o tutti i prodotti di controllo del codice sorgente (non ha ancora risposto a questa domanda). Non sto chiedendo un confronto / contrasto di sistemi diversi come svn vs git, posso farlo da solo. Sto cercando una terza parte che possa presentare un argomento logico per l'uso di una forma di controllo della versione SOME.
Per favore, colleghi coder, aiutami. Se qualcosa che puoi dire, indirizzata al mio capo, avrebbe un effetto sulla mia situazione, ti prego di venire avanti. Il mio capo può essere ragionato se viene presentato un argomento logico. Sto mettendo avanti il mio sforzo personale per convincerlo, attraverso la ricerca e la dimostrazione, ma se le persone della comunità di sviluppo sono in modo schiacciante dalla mia parte, penso che potrebbe riconsiderare. Per essere onesti, devo anche chiedere agli oppositori del controllo di versione di parlare. RSVP.
O 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à per non avere dubbi. Ma ci sono solo 2 sviluppatori (ora).
LA MIA DOMANDA REALE: Se non riesco a convincerlo, ci sarebbe alcun senso per me usarlo solo per me stesso? Sto parlando come qualcuno con un'esperienza molto limitata che effettivamente usa svn; tutto quello che so davvero è il checkout e il commit. Quali sono le caratteristiche del controllo del codice sorgente (potrebbe includere altri prodotti oltre a svn) che potrebbero essere di aiuto nel mio sforzo di sviluppo individuale?
E per favore nessun commento "Ricevi un altro lavoro". Lo so, gente, credimi, lo so. Prima che si presenti, si può presumere che io sia pazzo. Forse sono solo una ventosa per la sfida o un semplice vecchio masochista. Ma considera solo un'opzione.