Chez Yproximité, même si nous sommes une petite équipe, nous validons les fonctionnalités avant et après leur merge. Pour y arriver, il vous faut un processus génial : « le pull request builder ».
En gros, le pull request builder rend votre pull request accessible sur un environnement isolé de la production.
Pourquoi builder une pull request ?
- Je suis votre client : je veux m’assurer que vous m’avez bien compris quand j’ai rédigé ces « specs »
- Je suis la QA (les gens de la qualité) : je veux vérifier que rien n’est déjà cassé
- Je suis le lead developer : je veux essayer votre fonctionnalité pendant que j’en fais la revue de code
- Ajoutez ici tous vos autres cas…
De quoi avez-vous besoin ?
- Github
- Ansible
- N’importe quel projet, dans n’importe quel langage (PHP/Symfony2 chez nous)
- Tower, une interface graphique pour Ansible, même si elle n’est pas indispensable
- Tower-cli, un outil pour dialoguer avec l’API REST de Tower
- Un ou plusieurs serveurs de préproduction sur lesquels déployer vos PR
Pour vous faciliter le démarrage, j’ai publié en open source un peu de code de base (rien de bien sophistiqué, cela dit).
Une fois le hook configuré sur Github, il vous faudra un script pour traiter l’événement (pull request ouverte, mise à jour ou fermée) :
gist.github.com/616a1758044ac4b54206
Regardez ensuite celui-ci :
gist.github.com/5d8189fd23ebcfee12b4
À partir de là, Ansible joue le playbook de déploiement. Si vous avez besoin de vous mettre à niveau sur Ansible, vous pouvez jeter un œil à ma présentation d’Ansible.
En 20 minutes (ou 5 minutes s’il s’agit d’une mise à jour de la pull request), l’équipe reçoit une notification pour accéder à l’environnement dédié.
On peut aller encore plus loin, jouer avec des conteneurs Docker et déployer la pull request sur une VM temporaire, chez RunAbove ou Amazon EC2 par exemple.