Avec l'arrivée de Drupal 7, la communauté a laissé tomber CVS pour passer à Git, c'est aussi une bonne occasion de notre coté de passer à Git. Git est fondatellement différent de CSV et SVN, et demande une reflexion sur le worflow à avoir sur le développement des projets.

Après quelques semaines, nous avons commencé à mettre en place Git et quelques autres services pour améliorer notre productivité et le développement de projet avec des équipe délocalisés, en l'occurence nous avons des développeurs un peu partout en Europe.

Pour ce qui est de l'hébergement des repository, nous avons fait le choix d'utiliser Beanstalks, qui a l'avantage de proposer un service simple et le déploiement. En effet, comme nous gérons pas l'hébergement, le plus souvent nous avons que des accès FTP et PHPMyAdmin, l'avantage est que nous pouvons avoir des états de nos projets et savoir précisemment lequel est en production.

Worflow Git

Notre Worflow est relativement simple, je me suis basé sur ce qui a été écrit dans le livre ProGit disponible gratuitement sur Internet. Notre repository Git possède deux branches, la origin/master (qui est le site en production) et la origin/development qui correspond à une version preprod de notre site (hébergé sur un serveur qui permet à notre client de valider les modifications avant la mise en production).

Quand un développeur souhaite faire une modification, celui-ci va créer une branch locale avec le nom de son fix et se baser sur la origin/development. Après quoi, il pourra faire ses modifications et tester sur sa propre machine (c'est notre serveur de développement et unique à chaque développeur). Une fois les modifications faites et testées, il va merger sa branche avec la origin/development. Avec Beanstalks nous pouvons créer une déploiement de façon automatique, soit on peut retrouver les modifications directement sur le serveur de preprod après quelques minutes.

Une fois sur la preprod à jour avec les modifications, le développeur test à nouveau et met à jour le ticket ou envoi un mail au client pour valider les confirmations. Quand les modifications sont validées par le client, le Lead Developer va merger la branche origin/development avec origin/master et lancer (manuellement dans notre cas) le déploiement sur la production.

C'est sûrement pas la meilleure façon de faire, mais j'ai trouvé cette solution relativement pratique et simple à mettre en place.

Références

• ProGit
• Beanstalk