È insolito per una piccola azienda (15 sviluppatori) non utilizzare il controllo di origine / versione gestito? [chiuso]

Non è davvero una domanda tecnica, ma ci sono molte altre domande qui sul controllo del codice sorgente e sulle migliori pratiche.

La società per cui lavoro (che rimarrà anonima) utilizza una condivisione di rete per ospitare il suo codice sorgente e il codice rilasciato. È responsabilità dello sviluppatore o del gestore spostare manualmente il codice sorgente nella cartella corretta a seconda che sia stato rilasciato, quale versione sia e altro. Abbiamo diversi fogli di calcolo sparsi ovunque in cui registriamo nomi e versioni dei file e cosa è cambiato, e alcuni team mettono anche i dettagli delle diverse versioni nella parte superiore di ogni file. Ogni squadra (2-3 squadre) sembra fare diversamente all'interno dell'azienda. Come puoi immaginare, è un disastro organizzato - organizzato, perché le "persone giuste" sanno dove si trovano le loro cose, ma un disastro perché è tutto diverso e si basa sul fatto che le persone ricordano cosa fare in qualsiasi momento.

Ho cercato di spingere per qualche tipo di controllo del codice sorgente gestito per un po ', ma non riesco a ottenere abbastanza supporto per esso all'interno dell'azienda. I miei argomenti principali sono:

• Siamo attualmente vulnerabili; in qualsiasi momento qualcuno potrebbe dimenticare di fare una delle tante azioni di rilascio che dobbiamo fare, il che potrebbe significare che intere versioni non sono memorizzate correttamente. Se necessario, potrebbero essere necessarie ore o addirittura giorni per ricostruire una versione
• Stiamo sviluppando nuove funzionalità insieme a correzioni di bug e spesso dobbiamo ritardare il rilascio dell'uno o dell'altro perché alcuni lavori non sono ancora stati completati. Dobbiamo anche costringere i clienti a prendere versioni che includono nuove funzionalità anche se vogliono solo una correzione di bug, perché c'è davvero solo una versione su cui stiamo tutti lavorando
• Stiamo riscontrando problemi con Visual Studio perché più sviluppatori utilizzano gli stessi progetti contemporaneamente (non gli stessi file, ma continuano a causare problemi)
• Ci sono solo 15 sviluppatori, ma facciamo tutti cose diversamente; non sarebbe meglio avere un approccio standard a livello aziendale che tutti dobbiamo seguire?

Le mie domande sono:

1. È normale che un gruppo di queste dimensioni non abbia il controllo del codice sorgente?
2. Finora mi sono state fornite solo vaghe ragioni per non avere il controllo del codice sorgente - quali ragioni suggeriresti potrebbero essere valide per non implementare il controllo del codice sorgente, date le informazioni di cui sopra?
3. Ci sono altre ragioni per il controllo del codice sorgente che potrei aggiungere al mio arsenale?

Chiedo principalmente di avere un'idea del perché ho avuto così tanta resistenza, quindi per favore rispondi onestamente.

Darò la risposta alla persona che credo abbia adottato l'approccio più equilibrato e abbia risposto a tutte e tre le domande.

Grazie in anticipo

1. Potrebbe non essere normale , ma come dice Treb , probabilmente non è così insolito

2. Come altri hanno già detto, non ci sono ragioni valide per non avere il controllo del codice sorgente in un'azienda delle tue dimensioni. Quindi è necessario identificare e attaccare i motivi non validi :

   a) quello principale è lo status quo : "se non è rotto, non aggiustarlo". Questo è difficile: potresti iniziare a sottolineare tutte le cose che non funzionano come dovrebbero (che possono rapidamente farti etichettare come una "persona negativa"), oppure aspettare semplicemente che scoppi qualcosa (che potrebbe mai accadere), oppure potresti enfatizzare tutte le cose che potrebbero andare storte. Purtroppo i responsabili delle piccole aziende sono relativamente impervi di "cose ​​che potrebbero andare male" fino a quando non si sbagliano davvero ...

   b) ignoranza / paura / incertezza : "non capiamo veramente quale sia il controllo del codice sorgente; non sappiamo come usarlo; non sappiamo quale strumento scegliere; sta per restringere il nostro stile" . Questo è uno dei motivi per cui sicuramente non li manderei qui! Potrebbe essere un ordine abbastanza alto per te da solo, ma penso che per massimizzare le tue possibilità devi presentare una soluzione "chiavi in ​​mano" e non troppe varianti o alternative. Hai bisogno di una chiara idea di: come vuoi adattare / trasformare il tuo processo di lavoro per lavorare con lo strumento dato; come / se si prevede di eseguire il back-port del codice esistente; quanto velocemente pensi di poter "addestrare" gli utenti e metterli in funzione; come è possibile gestire il periodo di transizione (se presente); quanto può "costare" (in ore, se non in dollari).

   c) potrebbero esserci altri motivi (ad esempio precedenti esperienze negative con VSS o aver letto "storie dell'orrore" su strumenti presumibilmente troppo complicati), ma dovrai scoprirli singolarmente quando li scopri.

3. Vi sono molte ragioni per il controllo del codice sorgente delineate nelle altre risposte. Il mio consiglio sarebbe di scegliere i principali 2 o 3 che potrebbero davvero fare la differenza per la tua azienda, perfezionarli e presentarli in una riunione al maggior numero possibile di colleghi. Prova a provocare una discussione: anche se non li convincerai immediatamente, otterrai informazioni su quali potrebbero essere i punti critici.

(Hai letto / sentito parlare di The Change Function ?)

Non è assolutamente normale che un gruppo di quelle dimensioni funzioni senza il controllo del codice sorgente: il gruppo più grande di programmatori che può lavorare in modo efficace senza il controllo del codice sorgente è inferiore o uguale a uno. È assolutamente ingiustificabile lavorare senza controllo della versione per un team di professionisti di qualsiasi dimensione, e forse non mi sento creativo, ma non riesco a trovare alcun motivo per cui vorresti rinunciare.

Il controllo della versione è solo un altro strumento, particolarmente potente e che offre enormi vantaggi rispetto al suo costo minimo. Ti dà il potere di gestire con precisione tutte le tue modifiche in modo organizzato, con tutti i tipi di altre cose utili come la ramificazione, l'unione automatica, l'etichettatura e così via. Se hai bisogno di costruire una versione da mille versioni fa, puoi controllare il codice da quel momento in poi e costruire solo senza dover saltare altri cerchi.

Ancora più importante, se è necessario scrivere un bugfix, è possibile unirlo in un aggiornamento senza dover fornire le nuove funzionalità su cui si sta lavorando, perché si trovano su un altro ramo e per quanto riguarda il resto dello sviluppo preoccupati, non esistono ancora.

Stai vivendo resistenza perché stai sfidando la cultura dell'azienda. Ci vorrà del tempo per adattarsi, qualunque cosa tu dica. Il meglio che puoi fare è continuare a spingere per questo, e se la società non si muoverà davvero, trova un altro lavoro che sia più adatto al tuo livello di sviluppatore.

È normale che un gruppo di queste dimensioni non abbia il controllo del codice sorgente?

Nella mia esperienza, non è la norma, ma non è del tutto insolito come suggeriscono altre risposte qui. La maggior parte delle piccole aziende utilizza il controllo del codice sorgente, ma sfortunatamente un numero significativo non lo fa.

Finora mi sono state fornite solo vaghe ragioni per non avere il controllo del codice sorgente - quali ragioni suggeriresti potrebbero essere valide per non implementare il controllo del codice sorgente, date le informazioni di cui sopra?

Vedi questa domanda su SO per una buona discussione. La risposta accettata dice:
"Non ci sono buoni motivi per non usare il controllo versione. Neanche uno."

Ci sono altre ragioni per il controllo del codice sorgente che potrei aggiungere al mio arsenale?

Il consenso tra tutti gli sviluppatori e i project manager che ho incontrato, e ovviamente qui su programmatori e SO è che il controllo del codice sorgente è un must. È una best practice accettata . Se qualcuno decide di ignorarlo, deve avere degli argomenti molto forti e convincenti sul perché questa è la decisione giusta per lui (cioè un po 'più di "non ne abbiamo mai avuto bisogno, quindi perché dovremmo averne bisogno in futuro"). Gli argomenti che hai presentato finora sono focalizzati su questioni specifiche, forse dovresti provare un approccio più ampio sulla falsariga di 'tutti lo fanno, quindi perché non lo facciamo anche noi?

Il controllo del codice sorgente è valido anche per un singolo team di sviluppatori. Qualsiasi sistema di controllo del codice sorgente è fondamentalmente un sistema di controllo della versione che tiene traccia delle modifiche. Immagina un singolo sviluppatore, che potrebbe aver rimosso del codice e ritiene che il codice sia ora richiesto. Può riavere il vecchio codice?

Scegli uno strumento che ti aiuti. Le dimensioni non contano ovunque. La qualità conta ovunque.

Sembra che tu stia già utilizzando un sistema di controllo della versione, ma non molto valido. Le persone sembrano già riconoscere la necessità del controllo della versione. Devi solo introdurli al livello successivo: il controllo della versione del software.

Se fossi in me, introdurrei SCM come una versione migliorata di ciò che stanno già facendo. Vorrei sottolineare come l'uso di un buon strumento automatizzerà gran parte del lavoro già in corso.

• Invece di registrare le modifiche in un foglio di calcolo, il sistema SCM tiene traccia non solo di ciò che è cambiato, ma di chi è stato modificato e del perché.

• Come bonus, puoi tornare a qualsiasi punto della vita del codice e vedere cosa c'era effettivamente lì.

• Invece di avere versioni diverse di codice in cartelle diverse e di dover spostare / unire le cose tra le cartelle per effettuare il port di una modifica, puoi tenere tutto nello stesso posto e (cosa ancora più importante), lasciare che lo strumento faccia l'unione.

Come altri hanno già detto, mi aspetterei un po 'di resistenza, quindi prototiperei il sistema usandolo sulle cose che sto facendo.

(A proposito, in realtà ho messo il mio curriculum e altri documenti sotto SVN. Poi di nuovo, mi hanno recitato più volte i ruoli di Configuration and Integration Manager.)

Finora mi sono state fornite solo vaghe ragioni per non avere il controllo del codice sorgente - quali ragioni suggeriresti potrebbero essere valide per non implementare il controllo del codice sorgente, date le informazioni di cui sopra?

• Il prodotto che stai sviluppando è un sistema di controllo della versione; i manager sono preoccupati di impedire che i prodotti esistenti influenzino la progettazione e l'implementazione del nuovo prodotto.

• Tra i fine settimana di BASE saltando e correndo con i tori, i manager in cerca di brivido si divertono a guidare al lavoro chiedendosi se tutto è ancora andato all'inferno.

• Evita acquisizioni ostili. Chi vorrebbe acquisire un corredo di sviluppo software gestito in questo modo?

Ci sono altre ragioni per il controllo del codice sorgente che potrei aggiungere al mio arsenale?

• Stai già eseguendo il controllo della versione, ma attualmente lo stai facendo nel modo meno efficiente, più laborioso e più soggetto a errori immaginabile. L'uso di un VCS consente di risparmiare denaro, risparmiare tempo e migliorare la qualità.

• Risparmia spazio su disco. La maggior parte dei sistemi di controllo versione salva solo i delta tra i file. Attualmente, stai salvando un'intera copia di ogni versione di ogni file. (Il backup di tutte quelle copie deve richiedere molto tempo e spazio!)

• Diversi sviluppatori possono lavorare sullo stesso file contemporaneamente e conciliare le differenze senza troppi problemi. Unire i cambiamenti è ovviamente possibile senza un VCS, ma è quasi impossibile tenere traccia di chi ha cambiato cosa, quando e perché in quel caso.

• Offre agli sviluppatori la libertà di provare nuove idee sapendo che possono recuperare qualsiasi versione in qualsiasi momento.

• Un processo migliore semplifica l'assunzione e il mantenimento di sviluppatori di talento.

È normale che un gruppo di queste dimensioni non abbia il controllo del codice sorgente?

No sicuramente no. Quando ho iniziato con la mia attuale azienda, c'era una persona a cui dovresti inviare il tuo codice modificato e lo avrebbe unito. Potrei convincere tutti in pochi giorni a usare SVN.

Finora mi sono state fornite solo vaghe ragioni per non avere il controllo del codice sorgente - quali ragioni suggeriresti potrebbero essere valide per non implementare il controllo del codice sorgente, date le informazioni di cui sopra?

Penso che il motivo per cui hai sentito solo vaghi motivi sia perché non ci sono motivi validi per non utilizzare il controllo versione.

Ci sono altre ragioni per il controllo del codice sorgente che potrei aggiungere al mio arsenale?

Sì, ci sono molte ragioni.

1. La diramazione ti dà la possibilità di sviluppare nuove funzionalità senza interferire con altri sviluppi.
2. Ogni commit ti fornisce le informazioni su cosa è stato esattamente cambiato, chi ha fatto quel cambiamento e quando è stato fatto quel cambiamento.
3. Puoi facilmente commettere correzioni di bug e distribuirle ai clienti ed escludere la nuova funzionalità incompleta.
4. Puoi mantenere versioni diverse, se i clienti hanno paura di passare a una versione più recente.
5. Puoi lavorare sullo stesso progetto (anche gli stessi file sorgente!) Con facilità.
6. Puoi facilmente ripristinare un errore, conservando le modifiche dopo quell'errore commesso.

Alcune persone hanno difficoltà a rendersi conto di quanto sia grave lo status quo fino a quando non vedono qualcosa di meglio per se stessi. Ciò di cui hai bisogno è una buona demo . Mostra alcuni esempi reali di attività che potrebbe migliorare. "Mi ci sono volute 4 ore per rintracciare il nostro sistema attuale, ma questo comando di controllo del codice sorgente mi ha detto all'istante."

Non usare il controllo del codice sorgente è chiedere problemi, anche per uno sviluppatore solista. Il semplice fatto che puoi modificare spietatamente senza rischiare di perdere qualcosa compensa lo sforzo di apprendimento in settimane o giorni.

Detto questo, se non riesci a convincere i tuoi manager a introdurre il controllo del codice sorgente, fatti un favore e almeno usa qualcosa come git o mercurial localmente - se le cose esplodono a causa della mancanza di controllo del codice sorgente, almeno non sarai il uno che l'ha fatto.

La mia azienda utilizza GIT per il controllo della versione. La compagnia è composta da uno sviluppatore, un amministratore delegato, una guardia giurata, una donna delle pulizie e un ricevente. Sono tutti io. Il controllo della versione di origine è DEVE sempre.

Lavoro a molti progetti da solo e utilizzo ancora il controllo delle versioni. Le dimensioni non contano. Aiuta sempre ad avere il controllo della versione.

C'è una ragione per cui è il numero 1 in The Joel Test: http://www.joelonsoftware.com/articles/fog000000000043.html

Inoltre, rende possibile il numero 2 e il numero 3 nell'elenco.

Eravamo in una posizione simile con un team di 6 persone alcuni anni fa. Uno degli sviluppatori ha fatto il passo dell'installazione di SVN su un server di sviluppo in cui si trovava la cartella condivisa e ha appena iniziato a usarla.

Tutti ne seguirono l'esempio e non passò molto tempo prima che implementassimo CI ( CruiseControl ) e rivoluzionammo il nostro processo di costruzione e rilascio includendo automazione e controlli di qualità.

WTF ?! Questa potrebbe essere la domanda più ridicola che abbia mai visto. Devi trovare un nuovo lavoro. 15 sviluppatori ?! Pensi che sia una piccola squadra? Questo è folle. Manager dovrebbe essere immediatamente terminato. Onestamente, avrò degli incubi dopo aver letto questa domanda. Ti preghiamo di comunicarci il prodotto che vendi, quindi sappiamo tutti di non acquistarlo! Non so cosa sia più spaventoso, questa domanda o le risposte dicendo che questo non è insolito!

Non riesco a immaginare come 15 sviluppatori possano lavorare senza alcun controllo del codice sorgente. Tuttavia, da:

(...) utilizza una condivisione di rete per ospitare il suo codice sorgente (...)

Suppongo che tu abbia creato il controllo della versione del tuo povero come VSS (anche basato sulla cartella condivisa). È rischioso e non efficiente.

Spiega al tuo capo quanto è brutto, investi in qualche training SVN o GIT di 2 giorni e inizia a utilizzare il sistema di controllo della versione reale mentre hai ancora il codice in una forma ragionevole.

Se non mi impegno più volte al giorno, o almeno prima di partire per casa, mi sento come ... qualcosa che manca, qualcosa di sbagliato.

Una volta ho lavorato in un'azienda con solo 2 sviluppatori (io + un ragazzo con i capelli lunghi), nel 1998. Anche allora abbiamo usato svn. È così conveniente.

Diverse volte nella mia carriera ho perso un giorno di lavoro perché ho fatto qualcosa come mv invece di cp e poi rm -rf. Mi ha fatto piangere e vagare per le strade della città, disperato.

Ho lavorato in 5 aziende durante i miei 13 anni in SE, ho partecipato ad alcune conferenze e non ho mai incontrato un'azienda che non utilizzava il controllo delle versioni.

Tuttavia, la mia società di interior design preferita, 20 dipendenti, utilizza una lavagna bianca per la gestione del progetto + collaborazione. Sanno che è chiaramente sbagliato, ma non sembrano trovare il tempo per l'aggiornamento. In qualche modo funziona però. Non chiedermi come.

Sii un leader. Essere un leader significa fare ciò che è giusto; risoluzione proattiva dei problemi. La leadership non sta facendo nulla perché non c'è abbastanza consenso. E un buon leader impara a riconoscere le situazioni in cui si dovrebbe creare consenso e quando farlo. Questa è chiaramente una situazione positiva. La mancanza di controllo del codice esploderà in faccia prima o poi.

I leader spesso non ricoprono posizioni dirigenziali ufficiali. Le persone seguiranno leader buoni e decisi indipendentemente dal titolo.

Se i tuoi sforzi decisivi vengono bloccati, soprattutto se provengono dalla direzione, allora è un chiaro segno per te di andartene da lì. È un freno per il tuo sviluppo professionale; e gli sviluppatori competenti e la gestione incompetente non si mescolano e un incompetente con il potere ti rovinerà.

OK, i flashback mi stanno arrivando. Firmando. In bocca al lupo.

1. Ottieni un cronometro,
   • Conta il tempo speso nel foglio di calcolo solo per sincronizzare le versioni
   • Conta il tempo impiegato a riparare le versioni non funzionanti
   • conta il numero di volte che le persone gridano nel corridoio " sto modificando main.c !, solo per assicurarmi che nessun altro sia in questo momento!" .
   • contare il numero di reclami ricevuti dai clienti perché la loro correzione di bug conteneva altre modifiche
   • contare il ritardo del rilascio solo perché non è stato possibile sincronizzare le versioni
2. Crea un powerpoint con questi dati, confronta con come funzionerebbe vcs.
3. Mostra gestione

Questo è solo un incidente in attesa di accadere. Non hai una cronologia del codice e in un attimo uno dei tuoi sviluppatori potrebbe cancellare mesi di lavoro. Come piccola azienda non puoi permetterti questo tipo di battute d'arresto.

Sei anche molto esposto su quell'unità di condivisione. Anche con un buon backup, per quanto tempo puoi permetterti di non funzionare. 1 ora, 1 giorno, 1 settimana. Quanto tempo ci vorrebbe per installare un nuovo server, ripristinarlo dal backup, ecc. Ancora una volta, come piccola azienda, probabilmente non hai hardware aggiuntivo in standby e potresti non essere in grado di far cadere facilmente i soldi per ottenere spedizioni rapide ecc.

Pensa anche allo storage fuori sede. Un'alluvione o un incendio non è poi così insolito. Cosa accadrebbe se ci fosse un incendio nell'edificio dopo ore. Quanti mesi di lavoro andrebbero persi. Un repository di codice gestito come github sarebbe utile per questo. Anche l'utilizzo di un semplice server SVN su un servizio ospitato sarebbe un passo avanti in quest'area.

LordScree, sono in una situazione quasi identica a te, il mio team immediato è composto da circa 15 sviluppatori. Sono incredulo (quasi horror) che il controllo del codice sorgente non venga utilizzato. La mia risposta iniziale a "dovremmo usare il controllo del codice sorgente" è stata "non abbiamo tempo di implementare". Per me, come indossare biancheria intima, il controllo del codice sorgente non è facoltativo. Dopo alcuni mesi, anch'io ho l'approvazione per implementare TFS, scelto dall'organizzazione perché è MS e viene fornito con una prova di 90 giorni. In conclusione, è molto difficile convincere un'organizzazione della necessità del controllo del codice sorgente quando si sono dileguati senza di essa. Dico agli sviluppatori che ogni volta che ti ritrovi a eseguire il backup dei file, in particolare con una data nel nome o nella directory del backup, è un esempio di quando metti qualcosa nel controllo del codice sorgente. Io non Non ho risposte brillanti per te, ma credo che questo sia raro. Sto combattendo la stessa battaglia e ti terrò aggiornato sui progressi. E, si spera, ci saranno progressi altrimenti potrei cercare altrove perché non posso lavorare nel caos!

abbiamo 3 membri del personale di sviluppo e utilizziamo il controllo del codice sorgente. Sui miei progetti personali ho uno sviluppatore e utilizzo il controllo del codice sorgente. Non è solo utile per la gestione del team, è utile per essere in grado di fare un lavoro sperimentale senza temere che tu stia distruggendo qualcosa.

Il modo più semplice per convincere il management? Ci sono meno rischi per il prodotto complessivo e aumenterà la produttività degli sviluppatori a lungo termine. Entrambi sono anche veri ed entrambi fanno appello ai manager.

Non è affatto uno scenario normale e penso che dovresti combattere duramente per ottenere questa configurazione nella tua azienda. Ha benefici di vasta portata e non ha senso realizzarlo quando ti avvicini al giorno del giudizio e non è la situazione che cade Se non è rotto, non aggiustarlo

Qualsiasi motivo per non implementarlo potrebbe essere solo una scusa per un cattivo lavoro o un errore in attesa di accadere.

Dì loro quanto è bello trovare l'app il 1 gennaio di quest'anno

che ne dici di ehi questa funzionalità è stata aggiunta a marzo, penso che dobbiamo espandere un po 'di più su questo.

Wow, questo bug 154256 è stato corretto in questo commit.

posso diramare l'app e inviare la distribuzione senza problemi ragazzi, potete continuare a lavorare.

Questo può continuare all'infinito ... (ricordati di aggiungere commenti sugli commit in seguito che verrebbero inseriti come un'altra domanda)

Uso il controllo della versione per i miei progetti personali e per i miei progetti di lavoro, in cui abbiamo più di 30-40 persone che lavorano contemporaneamente sullo stesso codice. Il controllo della versione ha i suoi vantaggi organizzativi, ma la possibilità di ripristinare file e riporre le modifiche può davvero eliminare il mal di testa dalla gestione del codice ... e alla fine questo è lo scenario migliore per un programmatore, quindi possono concentrarsi solo sulla codifica.

I motivi per cui non si utilizza il controllo versione sono abbastanza limitati. Tutto quello a cui riesco a pensare è l'aspetto tecnico delle cose.

• C'è troppo di una curva di apprendimento per convertire l'intero flusso di lavoro del personale per incorporare un sistema di controllo delle versioni per essere conveniente.
• Il project manager non ritiene che sarebbe utile introdurre l'overhead nel flusso di lavoro di gestione e manutenzione di un repository. (Principalmente un problema con i vecchi sistemi di versioning)

Esistono molti motivi per utilizzare un sistema di controllo delle versioni. Per lo meno smetti di muovere le cose. Lavora con le patch. I sistemi di versioning possono fare esattamente quello che dici di fare.

• Puoi lavorare alla versione successiva contemporaneamente a correzioni di bug e rilasciarle separatamente.
• Invece di spostare i file da una posizione all'altra per lavorarci sopra, puoi creare un ramo e unirlo al master al completamento.
• Ogni sviluppatore può avere la propria copia del codice sorgente per impedire che i problemi con lo stesso progetto si aprano su più macchine.
• Gli incidenti accadono, se il codice viene gravemente violato tutto ciò che serve per eseguire il rollback all'ultimo numero di revisione funzionante.
• Il controllo della versione funziona bene abbinato a bug tracker e sistemi di integrazione continua.

Personalmente, come team di una sola persona utilizzo il controllo delle versioni, il monitoraggio dei bug, l'integrazione continua, la revisione del codice, il controllo della coerenza del codice, il test dell'unità, i test del selenio, l'analisi del codice sorgente e potrebbero essercene altri che sto dimenticando. Lo ammetto, c'è una leggera curva di apprendimento. C'è anche un compromesso di tempo di amministrazione aggiuntivo necessario per i passaggi aggiuntivi che automatizzi. Nella mia esperienza, lo sforzo risparmiato supera i tempi di amministrazione aggiuntivi.

Nel mio primo lavoro serio nel 1990 ero l'unico sviluppatore che lavorava nel mio dipartimento e non sapevo usare il controllo del codice sorgente.

Poco dopo ho appreso, da allora in poi non ho mai visto un progetto che non lo rendesse una delle prime cose che hanno creato.

Ho quasi perso tutto il mio lavoro in quel lavoro perché ho eliminato una cartella al livello sbagliato. Fortunatamente avevo portato una copia a casa su un floppy da 5 "la settimana prima e sono stato in grado di ricreare le settimane di lavoro in pochi lunghi giorni.

Quindi immagino che lo riterrei accettabile se fosse il primo progetto per tutti i membri del team e nessuno lo sapesse meglio, ma se anche una sola persona potesse effettivamente spiegare i vantaggi e il team non ascolterebbe ancora, riclassificare il mio l'opinione del gruppo da "ingenua" a "pericolosamente incompetente" (la resistenza all'uso di uno strumento con tali benefici ampiamente dimostrati è quasi criminale - è come se la tua squadra non si fidasse dei "compilatori" e insistesse nel fare tutto in linguaggio assembly ).

L'ho incantato molto ... in piccole società di ingegneria / elettroniche dove fanno molto software / hardware incorporato.

In questi luoghi SCM non fa parte della cultura dell'ingegneria elettronica. Di solito hanno un ingegnere per progetto, che deve solo eseguire il backup dell'ultima versione.

Quindi ramificare / unire e persino condividere il codice è considerato irrilevante. Inoltre, queste società sono probabilmente ISO9000, quindi il processo, albiet strano, è probabilmente documentato.

In ogni caso I / altri sviluppatori hanno appena iniziato a utilizzare SCM personalmente.

Dove lavoro, abbiamo lo stesso problema. Attualmente sto cercando di far scorrere il controllo della sorgente in "under the radar" per aggirare gli stessi problemi che hai. Uso i fossili per i progetti che sviluppo personalmente.

Di recente ho installato un server fossile sulla LAN aziendale, quindi ora è ancora più conveniente. Spero che, quando dimostrerò l'utilità su alcuni progetti più piccoli, minerò la resistenza e ci allontaneremo dallo status quo delle cartelle di rete.

I motivi principali che ho sentito per non usare fossili o altri VCS sono:

1. Molti dei "programmatori" sono kiddie di script e non capiranno come usarlo
2. Coloro che potrebbero imparare, pensano che sia una seccatura da usare
3. Queste persone sono la vecchia guardia, a proprio agio con le cartelle di rete, quindi tutti dovrebbero esserlo
4. Nessuno ha il tempo di configurarlo nel modo giusto o imparare a usarlo
5. Sebbene le funzionalità possano essere eccezionali, nessuna di esse è necessaria

Come puoi vedere, sto cercando di aggirare questi dimostrando che è semplice da usare, già configurato, facile da imparare e le funzionalità ne valgono la pena.

Infine, anche se non riesci a farli usare il controllo del codice sorgente, è tutto in un albero di rete. Fossil può eseguire la versione di tutto nell'intero albero e puoi configurarlo per l'esecuzione ogni volta che si verifica una modifica del file o almeno ogni ora. L'ho fatto per alcuni dei nostri progetti che "non avevano bisogno del controllo del codice sorgente" e alla fine mi hanno permesso di tornare a una buona versione quando qualcosa è andato storto.

Fallo nel modo giusto e non sapranno nemmeno che l'hai fatto. Quindi puoi essere l'eroe che ripristina la build rotta e dimostra quanto sia utile il tuo strumento.

Ora che strumenti DVCS come Git e Mercurial sono disponibili e incredibilmente facili da configurare e utilizzare, non c'è davvero alcuna scusa anche per una squadra di 1 (!) Non usare il controllo del codice sorgente. Non si tratta di dimensioni del team, si tratta di avere una cronologia commentata delle modifiche e la capacità di supportare flussi di lavoro come risolvere problemi di produzione mentre si lavora su una nuova versione e tenere traccia dello stato del codice sorgente per diverse versioni.

Se mi fosse offerto un lavoro in un team che era arrivato a quella dimensione, e nessuno degli sviluppatori mi aveva suggerito di usare un VCS, o se la "gestione" li avesse impediti, l'avrei rifiutato. Al momento non è un modo accettabile di lavorare.

Dovresti procurarti immediatamente un controllo della versione GIT. Puoi usarlo anche da Google Code Project Hosting. Quando gli altri ti vedono impegnare le modifiche in un solo clic mentre copiano manualmente le cose, forse cambiano idea.

Wow solo Wow. Anche se non penso che sia il modo migliore per gestire il controllo del codice, non è del tutto insolito che abbia lavorato in un'azienda con 6 sviluppatori e non è stato utilizzato alcun controllo del codice sorgente, in qualche modo avevano il loro modo interno di gestire i file, un gestore delle versioni e ciò che non sovrintenderebbe a tutte le modifiche. In realtà il mantra era che si potevano aggiungere nuove funzionalità ai progetti purché una sorta di interruttore fosse avvolto attorno alla funzionalità.

Ad esempio, stavamo lavorando su un social network di livello ab scritto in PHP e il cliente desiderava che la funzionalità fosse in grado di iscriversi a un profilo utente. Fondamentalmente la funzionalità è stata racchiusa in un segno di spunta come questo se (ENABLE_SUBSCRIBE_FUNCTIONALITY == true) {quindi esegui il codice}

Il posto in cui ho lavorato non ha mai avuto più di uno sviluppatore alla volta che lavorava su un determinato file, per lo più tutto era modulare quindi in quel caso non era necessario il controllo del codice sorgente. Tuttavia, credo che i vantaggi del controllo del codice sorgente superino di gran lunga gli svantaggi di non averlo nella maggior parte dei casi.

Il fatto stesso che la tua azienda stia ricorrendo a fogli di calcolo che documentano le modifiche ai file e ciò che è stato cambiato quando qualcosa come Git o Subversion può gestirlo per te è assolutamente ridicolo.

Sembra che tu sia un po 'convinto, ma qualcuno nell'organizzazione non ti autorizza a farlo. Come puoi leggere dagli altri commenti, dovresti farlo.

Puoi trovare alcune informazioni qui: http://www.internetcontact.be/scm/?page_id=358

Il fattore più importante è che i tuoi clienti sono costretti all'ultima filiale "instabile" e se i tuoi contratti con i tuoi clienti ti rendono responsabile dell'implementazione di versioni instabili, la tua azienda sta perdendo denaro. Dovresti davvero concentrarti sulla stabilità di rilascio qui. Questo è il motivo principale per il controllo del codice sorgente e come sembra il tuo errore principale. Gli altri non saranno migliorati così tanto usando il controllo del codice sorgente in quanto disponi già di sistemi alternativi.