Je dois apporter un site au contrôle de version et configurer l'environnement d'intégration continue.

Je suis un entrepreneur avec un projet Drupal 6x qui a démarré suffisamment petit pour ne pas avoir besoin de contrôle de version (par développeur), mais je suis maintenant convaincu qu'il n'y a pas moyen de s'en passer. Il existe une documentation complète sur JIRA, avec des histoires d'utilisateurs bien rédigées couvrant tout. J'ai lu un peu sur la façon dont cela pourrait être fait et j'ai élaboré le plan suivant -

1. Séparez le code de site de la base de données à l'aide de modules
   1. Le contexte
   2. traits
   3. Bras fort
   4. Profiler
2. Placez le code dans un référentiel SVN et créez un site intermédiaire
3. Créer un miroir du serveur de transfert sur le serveur de production EC2
4. Créez des tests Selenium et exécutez-les sur le cloud avec Saucelabs
5. Créez un flux de production dans JIRA Studio en utilisant Elastic Bamboo pour exécuter des mises à jour automatiques.
6. Mettre à jour et installer des profils avec Drush Make
7. Exécuter des mises à jour sur le serveur de production (je ne sais pas comment)

Pour commencer, j'ai dressé une liste d'environ 50 "fonctionnalités", chacune avec ses composants (vues, types de contenu, modules, etc.). Cela constituera sans aucun doute un défi, car le site contient environ une douzaine de modules et de services Web personnalisés, sans oublier une douzaine d'autres occurrences du type de contenu "application" contenant du code personnalisé (dont la plupart que je souhaiterais avoir converties en vues ou modules pouvant être mis à niveau). . La bonne chose est que le site n'est pas encore en production, le risque est donc encore limité.

Quelqu'un a-t-il déjà fait quelque chose de similaire? Quels pièges et limites dois-je m'attendre à rencontrer? J'apprécierais grandement toutes suggestions pour améliorer / corriger le plan ci-dessus, ainsi que toute idée ou conseil que vos experts pourraient avoir pour moi.

Ok, je vais essayer ceci :) Je ne serai pas en mesure de répondre complètement à votre question, mais je vous donnerai peut-être quelques indices intéressants. Notez que ma numérotation ne répond pas directement à la vôtre :)

1. Comme je l'ai déjà mentionné dans le commentaire, aucun projet n'est trop petit pour le contrôle de version. Personnellement, je recommande Git. Les raisons en sont la rapidité incroyable (le temps d’attente dans git est mesuré en millisecondes et non en secondes) et l’énorme quantité de fonctionnalités. Il peut être un peu difficile à ramasser, à cause des noms étranges et des arguments , mais les documents suivants explique un grand nombre d'entre eux vraiment bien: http://www.eecs.harvard.edu/~cduan/technical/git/ . Une autre raison est qu’il est maintenant utilisé par drupal.org, donc connaître git vous aidera à contribuer à nouveau (fournir des correctifs, tester des correctifs, publier des modules, ...).

2. Cela dit, si vous souhaitez utiliser SVN pour une raison quelconque (telle que l'intégration avec les services que vous prévoyez d'utiliser), allez-y. SVN fonctionne bien aussi et est bien meilleur qu'aucun contrôle de source. (Sauf si vous demandez à Linus Torvalds ..). En outre, il existe souvent des moyens de migrer d'un VCS à un autre si vous changez d'avis. SVN -> Git fonctionne bien, par exemple.

3. Troisièmement, approchez-vous étape par étape. N'essayez pas de tout faire en même temps. Donnez-vous (et à vos développeurs) le temps d'apprendre les nouveaux outils.

4. Passer de Drupal 6 à Drupal 7 n’est pas une mince affaire. Surtout avec beaucoup de code personnalisé. Notez que s'il y a des tonnes de changements dans l'API et de nouveaux concepts (comme l'entité / le système de terrain), il y a aussi le fait que de nombreux modules contribués ne sont pas encore complètement prêts.

5. La gestion de déploiement est l’ un des points faibles de Drupal, qui n’a également pas beaucoup changé dans Drupal 7. Nous sommes conscients du problème et les gens travaillent dur pour le résoudre pour Drupal 8: http://groups.drupal.org / build-systems-change-management / cmi . Les fonctionnalités, etc. aident, mais ce n'est pas une solution miracle. Tout ne peut pas être exporté en tant que fonctionnalité.

6. Il existe également quelques options spécifiques à Drupal pour le déploiement de sites de transfert et de production. Pantheon (toujours en version bêta) et Acquia Dev Cloud mériteraient peut-être d'être visités.

7. L'intégration continue, les tests automatisés sont importants et vraiment utiles, mais nécessitent également du temps pour configurer, rédiger les tests, etc. Temps que vous pourriez avoir ou ne pas avoir à ce stade. Mais les tests automatisés en particulier constituent un domaine dans lequel il est facile d’apporter des améliorations progressives. Une fois que vous avez un environnement configuré pour les exécuter, vous pouvez écrire de plus en plus de tests si le temps le permet.

Donc, voici ma recommandation pour la question mise à jour dans le commentaire:

Terminez et libérez tel quel, mais commencez à utiliser un VCS (système de contrôle de version) pour Drupal 6 maintenant. Créez un environnement de transfert pour votre site. Examinez les modules (contribués) que vous utilisez et vérifiez si un port vers Drupal 7 est réalisable à ce stade. Ne sous-estimez pas le temps que cela prendra. Commencez également à améliorer le processus de test / déploiement, en commençant par ce qui, selon vous, vous apportera le plus d'avantages / coûts.

Vous pouvez également créer des questions de suivi plus spécifiques ou consulter celles qui existent déjà. Comme vous pouvez le constater, donner seulement quelques indices à une question comme celle-ci peut devenir énorme et prendre un certain temps.