La settimana scorsa, con l'aiuto dei bravi ragazzi di Red Gate, ho creato una piccola competizione per dare via 5 licenze del loro molto eccellente controllo del codice sorgente SQL prodotto. I criteri di ingresso era semplice - condividi la tua esperienza più dolorosa che avrebbe potuto essere evitato utilizzando controllo del codice sorgente.
Molte storie dolorose emerse ma ho pensato che vale la pena condividere e commentare i 5 vincitori, come ho sentito questa volta il dolore e più volte negli anni passati. Così, godetevi queste storie e, auspicabilmente, portare via un po 'di pepite di conoscenza che potrebbe aiutare a evitare le trappole stesse in futuro.
Per i vincitori: si spera tali licenze saranno contribuire ad alleviare i dolorosi ricordi di errori passati! Sarò in contatto con i premi a breve.
1. Controllo del codice sorgente tramite CTRL-Z
La prima storia arriva per gentile concessione di MyChickenNinja e fa male letteralmente la testa per leggere! In questo caso particolare, le applicazioni sono stati sabotati da un ex-dipendente, che sta andando sempre essere doloroso, ma almeno ci sono di solito più mezzi di ristabilire il codice, se non i dati.
Il primo problema era backup che erano 3 settimane che in sé è una lezione - sono i vostri ambienti effettivamente eseguito il backup? Torneremo a quello di altre storie poco, la Pearler reale era il quasi-source controllo via via di CTRL-Z:
Corsero il loro codice, che hanno aggiornato costantemente, come il loro ambiente di produzione e usate Ctrl-Z per annullare le modifiche cattivi.
Ora, questo è seriamente mindboggling - cosa succede se l'applicazione che ha fatto la modifica è chiusa? O anche a PC spento? E appendere -? Ti ha appena detto hanno usato l'ambiente in cui si cura il codice come il loro ambiente di produzione UNDO NON CONTROLLO FONTE!
2. Basi di dati multiple e dolori di integrazione
La seconda storia è tramite Brandon Thompson dove ha avuto il dispiacere estremo di lavorare in un ambiente con molte fonti della banca di dati in fase di sviluppo attivo e nessun processo di integrazione reale al di là Yakka duro . Questo significava che fare con i backup del database multipli tra cui un gruppo si trova in mare aperto:
Il nostro team di sviluppo è stato in mare aperto, in modo che anche avuto una propria serie di banche dati che non ho mai visto, ma che avrebbero mandato su file con le modifiche da applicare ai nostri ambienti di sviluppo.
Quello che trovo più doloroso di questo è il lavoro manuale coinvolta semplicemente per chiunque voglia giocare bene insieme. Questo è lo sforzo che non va in innovazione o qualsiasi tipo di attività a valore aggiunto come la costruzione di nuove caratteristiche, è lo sforzo che si traduce in nulla da mostrare per esso al di là di codice che è stato già scritto in realtà di lavoro!
Controllo del codice sorgente è uno di quei grassi che si limita a tenere tutto funziona senza problemi insieme. E 'la stessa cosa con un ambiente di integrazione continua e la possibilità di distribuire automaticamente. Si tratta di "pane e burro" di sviluppo del software e devonoessere il fondamento su cui ogni squadra di successo scrive il codice.
3. A seconda del backup non testate
Il prossimo è Barry Anderson che ha realizzato un dolore che molti di noi hanno sperimentato prima, non essere in grado di ripristinare dal backup. Infatti in caso di Barry, i backup non era ancora accaduto per i mesi scorsi che di per sé, era male, ma è chiaro che coloro che dipendevano i backup, inoltre, non erano a conoscenza di un tale controllo critico.
Sicuramente c'è una buona ragione per tale controllo? Barry spiega:
Il nostro manager (non la squadra di archiviazione (!)) Poi ci ha detto che non c'era né il tempo né lo spazio per ripristini di prova!
Backup è una cosa, ma non meno importante, essere in grado di ripristinare da tali copie di backup è altrettanto importante. Recentemente ho avuto una esperienza nella configurazione di un certo numero di nuovi ambienti in cui sono stati i backup dovrebberoaccadere, ma semplicemente non lo erano. Solo insistendo su un funzionamento a secco di ripristino è stato il problema emerso. Per molte altre persone, il problema è emerso quando sono in realtà cercando di recuperare da un grave problema di perdita di dati. Verifica il tuo backup e ripristino gente e nessuno fiducia!
4. Lo strumento di unione umana
Da Graham Sutherland arriva una storia di uomo che fa lavoro di macchina:
Abbiamo avuto solo un paio di sviluppatori, e ognuno aveva una copia di tutto il progetto sul proprio disco. Ogni volta che un cambiamento è stato quello di essere spinto, abbiamo scaricato una copia del codice sorgente del dev lead (il suo codice di sviluppo in tempo reale) e utilizzato diff per identificare le modifiche, quindi aggiornato manualmente. Riga per riga. Tutto a mano.
Per quanto strano possa sembrare, in realtà ho visto fare prima, quando il controllo di origineha esiste! Perplesso sul motivo per cui un solo membro del team in mare aperto sembrava commettere, una discussione inglese maccheronico seguì nel corso della quale la logica è stato spiegato: lo sviluppatore principale necessario per verificare il lavoro degli sviluppatori di altri prima di essere commesso. Di sola andata "discussione" in chiaro, diretto inglese australiano seguito rapidamente.
Questo è davvero analoga a quella precedente punto di avere più database da integrare, abbiamo la tecnologia per risolvere questi problemi! Ogni volta che un essere umano si impegna in qualsiasi intensità di lavoro, durante il processo per fasi successive di sviluppo del software, è davvero di fermarsi e chiedere "C'è un modo migliore"? Di solito c'è.
5. Tagliare e incollare versioni
Storia di Robin Vessey è in risonanza con me perché è la forma più comune di quasi-VCS in corso, di taglio (o la copia) e incolla in nuove posizioni. Spesso il modello comporta effettivamente duplicare la directory che contiene il codice di denominazione poi la copia con una data o qualche altra forma di identificatore per indicare un periodo di tempo.
Nel caso di Robin, che stava cercando di spostare una struttura di directory in una rete:
È semplice ma efficace. Ho fatto un copia e incolla di un albero di directory, tutto ciò che, attraverso la rete ... i file lasciato il mio fianco, non sono mai arrivati dall'altra parte, ancora non so perché.
Devo ammettere, mi avvicino ogni taglia e incolla file dell'azione estrema cautela, perché ho visto accadere tante volte anche su un file system locale e tanto meno attraverso le idiosincrasie di una rete.
Il pungiglione nella coda della storia di Robin era che non c'erano backup stanno prendendo per il ripristino da perché avevano "fermato il backup di qualche tempo fa, perché non abbiamo avuto più spazio". Chiunque vedere un modello emergente qui?!
Riassunto
Se si lavora senza tutto sia sotto controllo del codice sorgente non è allo stesso tempo un pensiero spaventoso e un ricordo lontano - E smetti di giocare! Scherzi a parte gente, siamo veramente bene e al di là di questo come una professione e ora ci sono prodotti così tanti grandi VCS, servizi ospitati e strumenti di integrazione a disposizione non c'è davvero nessuna scusa per non avere tutto il codice - compreso il vostro database - sotto controllo del codice sorgente.
La maggior parte di questi sono gratuiti, alcuni sono dotati di uscite finanziarie e fatica molto minimale. Se ti è stato detto che non c'è le risorse per farlo (o testare i backup, in questo caso), poi qualcuno proprio non lo capisco. Onestamente, questi strumenti non sono più negoziabili che dare agli sviluppatori una sedia per sedersi e le cinque storie di cui sopra (più quelli formare i secondi classificati), dovrebbe servire come prova di questo.
Nessun commento:
Posta un commento