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

Non sono sicuro che chiameresti un atto serio, ma MySpace è piuttosto povero su questo fronte: vedi link .

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

Penso che ci siano ancora alcune aziende là fuori che non usano un sistema di controllo della versione. È interessante notare che in tutti i casi che ho visto finora non è perché si oppongono volentieri 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. Diavolo, sto persino spingendo i miei file personali (documenti di parole, ecc.) Sul mio PC di casa in un repository GIT.

Nel caso di un sistema di integrazione continua è un po 'più comune non utilizzarli nelle operazioni quotidiane. A volte anche perché la gente non sa che esiste un tale sistema, ma ho visto anche casi in cui la scusa - molto discutibile - per non usarli è che "non siamo abbastanza complessi" o "funziona molto bene senza un'integrazione continua, quindi perché preoccuparsi di aggiungere un'altra tecnologia? " Certo che non sopporta una valutazione realistica - ma per rispondere alla domanda originale: non è tutto che non comune.

Quasi tutte le aziende nel mio settore (bancario) attualmente utilizzano il controllo della versione. Ma è certamente possibile sviluppare software con successo senza il 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à distribuendo il software con successo senza un'integrazione continua, è perfettamente logico continuare su questa strada.

Solo per mettere un contro-commento alla risposta di @ RoadWarrior:

Lavoro per una banca. Ho passato gli ultimi 3 anni a implementare il controllo della versione e ora sono riuscito a farcela su circa il 20% del nostro codebase (che è abbastanza grande, abbiamo circa 20 sviluppatori e abbiamo sviluppato i nostri sistemi per > 16 anni)

Attraverso i miei contatti nel settore (bancario), conosco una tonnellata 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 della versione: Nel mio primo lavoro 25 anni fa non esisteva il sistema di controllo della versione in quanto tale, ma questo era RSX11 su PDP-11s. Tuttavia, c'era un molto livello di controllo di qualità molto elevato con revisioni formali di design e codice (questo era nell'industria nucleare).

Ogni lavoro da allora utilizza sistemi di controllo delle versioni, inclusi SCCS, PVCS, clearcase, cvs e perforce.

Quindi, secondo la mia esperienza, l'uso del controllo della 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 automatici. Ci vuole un investimento molto grande per spostare il codice esistente in un ambiente CI e, anche se probabilmente alla fine ci ripaga, è difficile convincere la direzione a impegnarsi in tale investimento senza alcun guadagno a breve termine.

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

Immaginerei che le MIGLIORI aziende non usino queste cose, perché non ne capiscono i benefici ei loro sviluppatori non vogliono imparare o hanno paura di "mescolare il piatto" facendo cose diverse da come è stato fatto prima.

Anche se ora sono un impiegato, ero un libero professionista come consulente di database. Durante quei molti, molti anni, mi trovavo da qualche parte tra le 800 e le 1000 aziende, da livello mamma-e-pop a Fortune 100.

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

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

A colleague of mine was under the impression that our software department was highly advanced as we used both a build server with continuous integration, and a version control software.

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 (soprattutto negozi non software) non capiscono perché è 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 persona o due persone puoi cavartela (non bene) senza di essa perché puoi essere in comunicazione quasi costante l'una con l'altra.

La costruzione continua è un caso completamente diverso. Se dovessi indovinare, scommetterei che quasi il 90% dei luoghi in cui viene eseguito lo sviluppo non ha una soluzione CI. Vado alle conferenze e la maggior parte della gente è sorpresa che un'organizzazione che non sia un MS o Google ce l'abbia. Quello che ho trovato è che il management non vuole spendere una piccola somma di denaro per farlo funzionare, anche se può risparmiare un sacco di tempo.

I motivi principali che ho trovato sono:

1. Le persone in gestione sono cresciute attraverso i ranghi della stessa organizzazione. Non hanno mai usato e non ne hanno avuto bisogno, perché avrebbero bisogno di cambiare ora? Alcuni che ho trovato hanno solo paura del cambiamento. Qualcosa di nuovo fa paura, e impedirebbe loro di rispolverare il vecchio compilatore e aiutare i più giovani nel momento del bisogno. Altre volte (e più spesso), hanno dei budget sempre stretti e devono prendere decisioni su dove spendere soldi. Per noi implementarle è un'esigenza ovvia, ma è perché le abbiamo già utilizzate. Conosciamo i vantaggi, loro no.

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

La maggior parte degli argomenti che ho ascoltato dalla gente si concentra sulle migliori pratiche ecc. e quelle sono vere, ma ciò che la maggior parte degli sviluppatori non capiscono è che devi inquadrarlo in termini di situazione finanziaria in questo scenario. Con questa somma di denaro che hai intenzione di spendere, stiamo andando a risparmiare X quantità di tempo, e hai bisogno di numeri per 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 codificarsi da soli e sono abituati a eseguire il backup periodico del database su un server centrale o su un disco rigido USB periodicamente. Mi sono imposto circa un anno fa per iniziare a usare SVN perché sapevo che sarebbe stato utile a lungo termine. Ci è voluto un po 'per abituarsi, ma ora ho un sacco di cronologia del codice che posso costantemente riferimento. Ora vorrei 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 trarremo vantaggio dall'integrazione continua perché lavoriamo sul nostro software da soli.

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

Molte aziende fanno il minimo richiesto, perché è tutto ciò che veramente ha bisogno . Se funziona, e ottieni buone versioni riproducibili senza grandi sforzi, allora non c'è nulla che debba essere corretto. 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 configurare e amministrare i nuovi server e creare sistemi.

Tuttavia, alcune aziende richiedono sistemi un po 'più rigidi, una volta che non solo fanno la build, ma controllano i requisiti fino alla distribuzione attraverso piani di test e risultati dei test, tenendo conto della revisione del codice, in stile del flusso di lavoro procedure di check-in e gestione dei pacchetti di lavoro designati dal team leader. Questa è la vera gestione della configurazione ed è dannatamente felice che tu non debba lavorare in quel tipo di ambiente!

Ho lavorato in alcune aziende, e non riesco a pensare a nessuno che non avesse una qualche forma di SCM. Alcuni di essi 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 si lavora su applicazioni complesse e un elenco di attività può essere difficile non martellare le modifiche reciproche.

Anche il nostro vecchio software di gestione dei rilasci mostrava i cambiamenti fianco a fianco e permetteva loro di essere applicati in entrambe le direzioni. Le modifiche sarebbero state perse in più di un'occasione senza di essa.

Vedo un certo numero di vantaggi che provengono dalla CI, ma non riesco a immaginare perché nessuna azienda possa utilizzare il software di controllo della versione.

L'ultimo lavoro a cui ho lavorato senza controllo delle versioni è stato nel 2006 (sono uno sviluppatore Web, FWIW). La compagnia aveva solo circa 2 o 3 sviluppatori prima di assumermi, ma io ero il primo di 10 o più sviluppatori assunti in appena un paio di mesi. Una delle prime cose che ho fatto quando ho assunto è stato introdurre il controllo della versione (CVS, perché al momento non sapevo quanto fosse faticoso!), Ma molti degli sviluppatori assunti dopo di me non riuscivano a farlo funzionare sul loro dev 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 automatico, ovviamente. Rabbrividisco quando ci ripenso.

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

Ora uso Git per tutti i miei progetti one-man, e anche i miei ultimi lavori diversi lo hanno usato.

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

Ho sicuramente incontrato alcuni qua e là, ma per lo più piccole aziende. Il problema che vedo più frequentemente sono le aziende che hanno effettivamente SCM, ma ritengono che molti progetti siano troppo piccoli o poco importanti per tenerne traccia.