Devo portare un sito al controllo della versione e impostare l'ambiente di integrazione continua

Sono un imprenditore con un progetto Drupal 6x che è iniziato abbastanza piccolo da non richiedere il controllo della versione (per sviluppatori), ma ora sono convinto che senza di esso non c'è modo. C'è una vasta documentazione su JIRA, completa di User Story ben scritte che coprono tutto. Ho letto un po 'di come questo potrebbe essere fatto e ho escogitato il seguente piano -

1. Separare il codice del sito dal database utilizzando i moduli
   1. Contesto
   2. Caratteristiche
   3. Braccio forte
   4. Profiler
2. Inserire il codice in un repository SVN e creare un sito di gestione temporanea
3. Creare un mirror del server di gestione temporanea sul server di produzione EC2
4. Crea test di selenio ed eseguili sul cloud usando Saucelabs
5. Crea un flusso di lavoro di build in JIRA Studio utilizzando Elastic Bamboo per eseguire gli aggiornamenti automatici
6. Aggiorna e installa i profili utilizzando Drush Make
7. Esegui aggiornamenti sul server di produzione (non sono sicuro di come)

Per cominciare, ho fatto un elenco di circa 50 "Funzioni", ciascuna con i suoi componenti (viste, tipi di contenuto, moduli ecc.). Questo sarà senza dubbio una sfida poiché il sito contiene circa una dozzina di moduli personalizzati e servizi web, per non parlare di un'altra dozzina di istanze di tipo di contenuto "applicazione" contenente codice personalizzato (la maggior parte delle quali vorrei convertire in visualizzazioni o moduli aggiornabili) . La cosa buona è che il sito non è ancora in produzione, quindi il rischio è ancora limitato.

Qualcuno ha qualche esperienza nel fare qualcosa di simile? Quali insidie ​​e limitazioni dovrei aspettarmi di incontrare? Gradirei qualsiasi suggerimento per migliorare / correggere il piano di cui sopra, o qualsiasi intuizione o consiglio che voi esperti là fuori potreste avere per me.

Ok, ci proverò :) Non sarò in grado di rispondere completamente alla tua domanda, ma forse ti darò qualche suggerimento interessante. Nota che la mia numerazione non è in risposta diretta alla tua :)

1. Come ho già detto nel commento, nessun progetto è troppo piccolo per il controllo della versione. Personalmente consiglio Git. Le ragioni sono la sua straordinaria velocità (il tempo di attesa in git è misurato in millisecondi, non in secondi) e l'enorme quantità di funzionalità. Può essere un po 'difficile da imparare, a causa di nomi e argomenti strani, ma la seguente documentazione spiega molti di loro davvero buoni: http://www.eecs.harvard.edu/~cduan/technical/git/ . Un altro motivo è che ora è utilizzato da drupal.org, quindi conoscere git ti aiuterà quando vuoi contribuire (fornendo patch, test di patch, moduli di rilascio, ...)

2. Detto questo, se desideri utilizzare SVN per qualche motivo (come l'integrazione con i servizi che prevedi di utilizzare), allora provaci. SVN funziona anche abbastanza bene ed è molto meglio di nessun controllo del codice sorgente. (A meno che non chiediate a Linus Torvalds ..). Inoltre, ci sono spesso modi per migrare da un VCS a un altro se cambi idea. SVN -> Git funziona bene, ad esempio.

3. Terzo, avvicina questo passo per passo. Non provare a fare tutto in una volta. Dai a te (e ai tuoi sviluppatori) il tempo per imparare i nuovi strumenti.

4. Passare da Drupal 6 a Drupal 7 non è cosa da poco. Soprattutto con un codice molto personalizzato. Nota solo che ci sono tonnellate di modifiche API e nuovi concetti (come l'entità / sistema di campo), c'è anche il punto che molti moduli forniti non sono ancora completamente pronti.

5. La gestione della distribuzione è uno dei punti deboli di Drupal, che non è cambiato molto in Drupal 7. Siamo consapevoli del problema e le persone stanno lavorando sodo per risolverlo per Drupal 8: http://groups.drupal.org / build-systems-change-management / cmi . Funzionalità ecc. Aiutano, ma non è un proiettile d'argento. Non tutto può essere esportato come funzionalità.

6. Esistono anche alcune opzioni specifiche di Drupal per la distribuzione di siti di produzione / staging. Pantheon (ancora in versione beta) e Acquia Dev Cloud potrebbero valere la pena di essere verificati.

7. Integrazione continua, test automatizzati sono importanti e molto utili, ma richiedono anche tempo per la configurazione, la scrittura dei test e così via. Tempo che potresti avere o non avere a questo punto. Ma soprattutto i test automatizzati sono un'area in cui è facile apportare miglioramenti incrementali. Una volta impostato un ambiente per eseguirli, è possibile scrivere sempre più test quando il tempo lo consente.

Quindi, ecco la mia raccomandazione per la domanda aggiornata nel commento:

Termina e rilascia così com'è, ma inizia subito a utilizzare un VCS (sistema di controllo della versione) per Drupal 6. Crea un ambiente di gestione temporanea per il tuo sito. Guarda quali moduli (contribuiti) stai utilizzando e controlla se una porta per Drupal 7 è fattibile a quel punto. Non sottovalutare il tempo che ci vorrà. Inoltre, inizia a migliorare il processo di test / implementazione, a partire da ciò che ritieni possa comportare il massimo beneficio / costo.

Puoi anche creare domande di follow-up più specifiche o cercare quelle già esistenti. Come puoi vedere, anche solo dare alcuni suggerimenti a una domanda come questa può diventare enorme e richiedere un bel po 'di tempo.