Come posso ottenere da un processo altamente manuale di sviluppo e implementazione all'integrazione continua?

L'approccio che prenderei dipende dalle tue attuali esigenze. Dal momento che stai apportando un cambiamento di processo, sembra che ci sia un problema che stai cercando di risolvere. Quale problema / i che stai cercando di risolvere cambierà l'approccio che prenderai. Alla fine, per ottenere un buon ambiente di integrazione continua, dovresti affrontare tutti questi problemi.

Puoi costruire facilmente? La tua build dovrebbe essere eseguita da un singolo comando a qualcosa come un Makefile o uno script Ant o Maven, a seconda della lingua e della piattaforma di destinazione. Semplicemente eseguendo questo script dovresti eseguire una ricostruzione completa ed eseguire qualsiasi test tu abbia. Se non hai questo, crearne uno renderebbe il processo manuale meno doloroso.

La tua build è lenta? Se la tua build è lenta, darei un'occhiata a una build regolare (notturna?) O al miglioramento del tempo di costruzione come primo passo. Se effettui il check-in in una filiale di integrazione o alpha almeno una volta al giorno, una compilazione notturna sarebbe sufficiente. Ogni notte, inizia la costruzione e il team addetto all'assicurazione della qualità ha una nuova build da lavorare ogni mattina, senza tempi morti, in attesa che la costruzione venga avviata manualmente. Se non effettui il check-in tutti i giorni, sarebbe probabilmente meglio controllare se ci sono aggiornamenti prima di costruire. L'altra opzione sarebbe migliorare le prestazioni di build in modo che le build manuali richiedano meno tempo per l'esecuzione. Quando passi all'automazione, ti permetterà di vedere i risultati del ciclo di build / test più velocemente.

La tua qualità è scarsa? Se hai scarsa qualità (software instabile, difetti rilevati dopo la spedizione), concentrati sul miglioramento e sull'automatizzazione dei test. Crea test unitari che possono essere eseguiti automaticamente (una volta automatizzato il processo di compilazione) e fornire un feedback immediato agli sviluppatori. Inoltre, lavora per automatizzare il più possibile i test di integrazione e accettazione, in modo che possano essere eseguiti e fornire feedback agli sviluppatori e ai team di controllo della qualità.

Probabilmente ci sono altre domande che puoi chiedere, a seconda della tua situazione individuale. Ma prendilo piano. Implementa un aspetto di una cultura dell'integrazione continua alla volta: build automatizzati, test automatizzati, build rapidi, feedback istantanei, risultati visibili dei cicli di build / test e implementazione automatizzata - a partire da quelli che aggiungeranno più valore al tuo team.

Come hai commentato che stai usando PHP - l'installazione di Netbeans per PHP potrebbe essere un buon modo per andare.

1. Sembra che tu abbia il controllo del codice sorgente, il primo passo ovvio
2. Il prossimo passo ovvio è assicurarsi che i blocchi di documenti siano scritti per ogni nuova funzione e ogni funzione che si modifica, che Netbeans aiuterà ad automatizzare
3. Oltre a ciò Netbeans fornisce buone istruzioni su come integrare tutti i componenti necessari per l'elemento della configurazione.
4. A partire da PHPUnit
5. a PhpDocumentor
6. attraverso il server CI Hudson ( Jenkins ) - sono tutti raggruppati nelle opzioni PHP per Netbeans.

Suggerisco di utilizzare Jenkins che consente di aggiungere script di build, ma anche di eseguire il commit su ogni commit. Non è necessario configurare l'intera build in un giorno ma è possibile eseguire piccoli passaggi ogni giorno.

Ad esempio, puoi migliorare il tuo script di build ogni volta che hai tempo e puoi integrare più report di build o test unitari mentre vai avanti. All'inizio Jenkins creerà una build automatica su ogni commit e la build verrà eseguita entro un secondo perché non hai ancora specificato alcun lavoro. Questo ti assicura che il sistema funziona e puoi iniziare a lavorare con il sistema di generazione che desideri.

Scegli un obiettivo facile, ottieni successo e poi imposta un altro obiettivo. IMHO il tuo primo obiettivo dovrebbe essere una build notturna. Molto tempo fa abbiamo avuto problemi di distribuzione a causa di checkup trascurati, numerazione delle versioni errata, dipendenze sconosciute ecc. E una build notturna ha risolto molti di questi problemi. Ci ha dato un unico output affidabile per tester, installatori, implementazione ecc. Tutti potevano essere sicuri che la versione x.y.z fosse l'ultima build di successo. Non è più necessario testare le vecchie versioni.

La creazione di una build notturna può creare problemi con alcune persone, è necessario un strong sponsor per aiutarti. Colpisco molte obiezioni come "ma non è così che mi piace lavorare". Certo, ma agli utenti finali non piacciono gli errori nel tuo lavoro. Un buon sponsor ti assisterà con le obiezioni.

La creazione di una build automatizzata mostrerà altri problemi come i problemi di dipendenza. Quando inizi a girare le rocce, preparati a essere sorpreso da ciò che trovi sotto. Parte del dolore di arrivare all'automazione / nightly builds / CI sta portando tutti sulle stesse dipendenze / librerie. Magari avessimo già avuto delle risposte.

Sviluppa un tono per un processo di compilazione automatizzato. Prova a trovare segnalazioni di bug dai deployer o dagli utenti finali che potrebbero essere stati prevenuti.

Prima di tutto, non è necessario che tu stia facendo agile per andare in un ambiente di distribuzione CI.

We have a pretty intense development cycle

Bene, non lo facciamo tutti? Basta mordere il proiettile e farlo! Non più procrastinare, se la squadra vuole farlo, quindi assegnare qualcuno (o più) per farlo.

Se il management si lamenta di essere un uomo in meno per le funzionalità per una settimana, fornisci alcune statistiche su quanto tempo pensi che passare a CI ti salverà. Quanto ci vuole per costruire un manuale? quanto spesso una build manuale non funziona e deve essere rifatta? Quante volte un ambiente deve essere ricostruito a causa di una scarsa costruzione manuale ecc.

Una volta superati questi ostacoli, scopri:

• quale strumento CI, ci sono molti
• quali ambienti hai intenzione di avere
• quali server hai bisogno di questi e quanti
• identifica tutte le diverse "sezioni" disparate del tuo sistema, individua le dipendenze (probabilmente lo sai già) e immettile nel tuo ambiente CI.

Inizia automatizzando la tua build. Con PHP, questo sarà probabilmente uno script di shell. Dovrebbe fare le seguenti cose:

• Se stai usando un database, crea una nuova istanza di database e compilala con i dati iniziali. Non essere tentato di riutilizzare un'istanza esistente, poiché alla fine causerà errori spuri. IMO, questa è la fermata più importante per l'automazione di una build, indipendentemente dalla lingua; i tuoi dati sono ciò che guida il sistema.
• Estrarre il trunk in una directory pulita e applicare eventuali modifiche alla configurazione (ad esempio, puntando all'istanza del database appena creata).
• Configura il tuo server in modo che punti a questa directory e avvii il server.
• Esegui wget o curl per verificare che la tua home page sia accessibile.

Questo è uno script di integrazione continua di base, sebbene non esegua veri e propri test. Puoi eseguire questo script con cron o da un hook di commit sul tuo database.

Il prossimo passo è aggiungere test. In un mondo perfetto, hai separato la tua logica aziendale dalla presentazione e potresti scrivere script PHP che caricano i tuoi moduli e li esercitano. Immagino che questo non sia il tuo mondo.

In questo caso il tuo primo ciclo di test utilizzerà probabilmente wget o curl , insieme ad altri programmi di shell ( grep , forse) per verificare che stai ottenendo qualcosa di simile a quello che ti aspetti. Puoi anche scrivere script PHP che esercitano la tua app: distribuirli su un altro server e invocare dai tuoi script di compilazione. Quanto dettagliato vuoi ottenere dipende da te.

Per esercitare completamente la tua app, probabilmente vorrai uno strumento come Selenium .

Tuttavia, procedete, assicuratevi di inviare tutti i vostri sviluppatori quando la compilazione fallisce. Non vuoi lasciare la build rotta e la persona che ha rotto la build potrebbe non essere la persona migliore per risolverlo.