Ci sono aziende serie che non usano il controllo delle versioni e l'integrazione continua? Perché?

Un mio collega aveva l'impressione che il nostro reparto software fosse altamente avanzato, poiché utilizzavamo sia un server di build con integrazione continua, sia un software di controllo della versione. Questo non corrispondeva al mio punto di vista, poiché conosco solo una società che ha realizzato software serio e che non aveva nemmeno. Tuttavia, la mia esperienza è limitata a poche aziende.

Qualcuno conosce una vera azienda (più grande di 3 programmatori) , che è nel settore del software e non utilizza questi strumenti? Se esiste una società del genere, ci sono buone ragioni per non farlo?

Non sono sicuro che li chiameresti un atto serio, ma MySpace è piuttosto povero su questo fronte: vedi http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill- myspace.html .

Saresti sorpreso di vedere cosa può fare la realtà al buon senso ;-)

Penso che ci siano ancora alcune aziende là fuori che non utilizzano un sistema di controllo della versione. È interessante notare che in tutti i casi che ho visto finora non è perché si oppongono volontariamente all'uso di tali sistemi, ma piuttosto perché non sanno che esiste qualcosa come SVN! Quanto a me: sono totalmente d'accordo con te e non posso immaginare una situazione in cui non voglio usare alcun tipo di controllo di versione. Inferno, sto persino spingendo i miei file personali (documenti word, ecc.) Sul mio PC di casa in un repository GIT.

Nel caso del sistema di integrazione continua è un po 'più comune non impiegarli nelle operazioni quotidiane. A volte anche perché le persone non sanno che tale sistema esiste ma ho anche visto casi in cui la scusa - molto discutibile - per non usarli è che "non siamo abbastanza complessi" o "funziona molto bene senza integrazione continua, allora perché preoccuparsi di aggiungere un'altra tecnologia? " Ovviamente ciò non regge una valutazione realistica, ma per rispondere alla domanda originale: non è poi così raro.

Quasi tutte le società del mio settore (bancario) attualmente utilizzano il controllo delle versioni. Ma è certamente possibile sviluppare software con successo senza controllo della versione. 20-30 anni fa. abbiamo fatto esattamente questo.

Direi che molte banche, forse anche la maggioranza, non usano un server di build con integrazione continua. Se stai già fornendo software con successo senza integrazione continua, è perfettamente razionale continuare su questa strada.

Giusto per mettere in evidenza la risposta di @ RoadWarrior:

Lavoro per una banca. Ho trascorso gli ultimi 3 anni a implementare il controllo della versione e ora sono riuscito a ottenerlo su circa il 20% della nostra base di codice (che è piuttosto grande, abbiamo circa 20 sviluppatori e abbiamo sviluppato i nostri sistemi per> 16 anni)

Attraverso i miei contatti nel settore (bancario), conosco un sacco di altri istituti finanziari che non hanno ciò che qualsiasi persona sana di mente chiamerebbe controllo di versione.

Sì, il nostro settore (sviluppo software) è molto più triste di quanto la maggior parte vorrebbe ammettere.

controllo versione: nel mio primo lavoro 25 anni fa non esisteva un sistema di controllo versione in quanto tale, ma questo era RSX11 su PDP-11s. Tuttavia, c'era un livello molto alto di controllo di qualità con revisioni formali di progettazione e codice (questo era nell'industria nucleare).

Da allora ogni lavoro ha utilizzato sistemi di controllo della versione, tra cui SCCS, PVC, clearcase, cvs e perforce.

Quindi, nella mia esperienza, l'uso del controllo di versione è praticamente universale nello sviluppo di software serio.

integrazione continua: questo è più un problema, specialmente in luoghi che hanno un sacco di codice legacy che probabilmente non ha nemmeno molto in termini di test automatizzati. Ci vuole un investimento molto grande per spostare il codice esistente in un ambiente CI e, sebbene alla fine probabilmente ripaghi, è difficile convincere la direzione a impegnarsi in un investimento del genere senza guadagno a breve termine.

Ho lavorato in un unico posto (una grande banca) che disponeva di CI per alcuni progetti e sul nostro progetto abbiamo implementato un tipo di sistema di CI che ha reso le cose molto più facili, ma ci sono voluti circa 6 mesi.

Immagino che la maggior parte delle aziende non usa queste cose, perché non capiscono i vantaggi e i loro sviluppatori non vogliono imparare o hanno paura di "mescolare il piatto" facendo cose diverse da come sono state fatto prima.

Anche se ora sono un dipendente, ero un lavoratore autonomo come consulente di database. Durante quei tanti, molti anni, mi trovavo in qualche luogo tra le 800 e le 1000 aziende, dal livello mamma-e-pop ai Fortune 100.

Ho visto relativamente pochi posti che hanno fatto un'integrazione continua, ma non ricordo di aver mai visto un'azienda che non utilizzava il controllo delle versioni. Ne ho visti alcuni in cui non esisteva un repository centralizzato per il codice controllato dalla versione. I singoli programmatori utilizzavano il controllo della versione sul proprio computer o mantenevano il codice controllato dalla versione da qualche parte sotto la loro home directory sul server.

Non credo che nessuna di queste aziende fosse nel settore del software, ma i loro programmatori lo erano sicuramente.

Un mio collega aveva l'impressione che il nostro reparto software fosse altamente avanzato poiché utilizzavamo sia un server di build con integrazione continua, sia un software di controllo della versione.

No, odio dirlo, ma questo è vero. Negli ultimi due posti in cui ho lavorato (una divisione di una banca e una società finanziaria), sono stato io a implementare il sistema di controllo della versione. Un certo numero di luoghi (in particolare i negozi non software) non capiscono perché sia ​​davvero necessario per lo sviluppo a lungo termine. La squadra normalmente inizia come una o due persone e poi cresce da lì, anche se dolorosamente. Con una o due persone puoi cavartela (non bene) senza di essa perché puoi essere in comunicazione quasi costante l'una con l'altra.

La generazione continua è un caso completamente diverso. Se dovessi indovinare, scommetterei che quasi il 90% dei luoghi in cui viene svolto lo sviluppo non dispone di una soluzione CI. Vado a conferenze e la maggior parte delle persone è sorpresa che un'organizzazione diversa da uno Stato membro o da Google ce l'abbia. Quello che ho scoperto è che il management non vuole spendere la piccola somma di denaro per farlo funzionare, anche se può risparmiare molto tempo.

I principali motivi che ho trovato per questo sono:

1. Le persone nella direzione sono salite di livello nella stessa organizzazione. Non hanno mai usato e non ne hanno avuto bisogno, perché dovrebbero cambiare adesso? Alcuni che ho trovato hanno solo paura del cambiamento. Qualcosa di nuovo fa paura, e impedirebbe loro di rispolverare il vecchio compilatore e aiuterebbe i più piccoli in caso di necessità. Altre volte (e più spesso), hanno budget che sono sempre limitati e devono prendere decisioni su dove spendere soldi. Per noi l'implementazione di questi è un'esigenza ovvia, ma è perché li abbiamo già usati in precedenza. Conosciamo i benefici, loro no.

2. I manager sono persone non IT e tutto ciò che qui è è che vuoi spendere soldi per qualcosa che non è stato necessario prima.

La maggior parte degli argomenti che ho sentito dalle persone si concentrano sulle migliori pratiche ecc. E quelle sono vere, ma ciò che la maggior parte degli sviluppatori non capisce è che devi inquadrare in termini di una situazione finanziaria in questo scenario. Con questa somma di denaro che stai per spendere, risparmieremo X quantità di tempo e avrai bisogno di numeri per eseguirne il backup. Questo non è sempre vero, ma è stata la mia esperienza in passato.

Direi che molte persone non usano il controllo del codice sorgente perché potrebbero codificare da sole e sono abituate a eseguire periodicamente il backup della base di codice su un server centrale o sul disco rigido USB. Mi sono costretto circa un anno fa a iniziare a utilizzare SVN perché sapevo che sarebbe stato utile a lungo termine. Ci è voluto un po 'di tempo per abituarmi, ma ora ho tonnellate di cronologia del codice a cui posso costantemente fare riferimento. Vorrei ora averlo implementato quattro anni fa quando ho iniziato.

Integrazione continua? Usalo solo se ne hai bisogno. Per me, ci sono solo due ingegneri del software, quindi non trarremmo beneficio dall'integrazione continua perché lavoriamo sul nostro software da soli.

Ah, pensi di essere avanzato perché hai SCM e un sistema CI? Lascia che ti dica che è l'ora amatoriale quando si tratta di esso.

Molte aziende fanno il minimo richiesto, perché è tutto ciò di cui ha davvero bisogno . Se funziona e ottieni buone versioni riproducibili senza grandi sforzi, non c'è nulla che debba essere riparato. L'ultima cosa che vuoi fare in tali circostanze è iniziare a "sistemare" le cose, specialmente quando si tratta di togliere le risorse di amministrazione dal loro lavoro per impostare e amministrare i tuoi nuovi server e costruire sistemi.

Tuttavia, alcune aziende richiedono sistemi un po 'più rigorosi, una volta che non solo eseguono la compilazione, ma controllano i requisiti fino alla distribuzione tramite piani di test e risultati dei test, prendendo in esame il codice, procedure di check-in in stile flusso di lavoro e gestione del pacchetto di lavoro designato dal team leader. Questa è la vera gestione della configurazione, ed essere dannatamente felice di non dover lavorare in quel tipo di ambiente!

Ho lavorato in alcune aziende e non riesco a pensare a nessuna che non avesse una qualche forma di SCM. Alcuni erano più completi di altri, ma tutti avevano un sistema che funzionava bene per loro, anche quelli che utilizzavano VSS.

Anche con due programmatori quando lavori su applicazioni complesse e un elenco di attività, può essere difficile non dare una martellata le modifiche reciproche.

Anche il nostro vecchio software di gestione delle versioni mostrava le modifiche fianco a fianco e permetteva di applicarle in entrambe le direzioni. I cambiamenti sarebbero stati persi in più di un'occasione senza di essa.

Vedo una serie di vantaggi che derivano da CI, ma non riesco a immaginare il motivo per cui qualsiasi azienda non farebbe uso del software di controllo della versione.

L'ultimo lavoro a cui ho lavorato senza controllo della versione è stato nel 2006 (sono uno sviluppatore Web, FWIW). La società aveva solo circa 2 o 3 sviluppatori prima di assumermi, ma io ero il primo di circa 10 sviluppatori assunti in un paio di mesi. Una delle prime cose che ho fatto quando assunto è stato introdurre il controllo della versione (CVS, perché non sapevo al momento quanto facesse schifo!), Ma molti degli sviluppatori assunti dopo di me non sono riusciti a farlo funzionare sui loro sviluppatori ambienti, quindi non l'ho usato. Oh, ho detto che non avevano nemmeno istanze locali dell'applicazione in esecuzione? Hanno hackerato il codice sul server. E nessun test automatizzato, ovviamente. Mi arrabbio quando ci ripenso.

Prima di allora, ho fatto alcuni lavori di programmazione AS / 400 senza controllo della versione. Non so se un VCS decente fosse disponibile anche per quell'ambiente.

Ora uso Git per tutti i miei progetti personali e anche i miei ultimi lavori lo hanno usato.

L'IC è una questione diversa. È fantastico e lo incoraggio, ma è meno essenziale del controllo di versione, almeno per progetti più piccoli in lingue interpretate. Tuttavia, la maggior parte dei miei lavori recenti ha avuto server CI; tra le altre cose, significa che nessuno può dimenticare di eseguire l'intera suite di test prima della distribuzione.

Ne ho sicuramente incontrati alcuni qua e là, ma soprattutto piccole aziende. Il problema che vedo più frequentemente sono le aziende che in realtà hanno SCM, ma ritengono che molti progetti siano troppo piccoli o non importanti per poterli tracciare.