Consultez nos archives

Intégration continue avec Jenkins

Intégration continue

Mon équipe a commencé à jouer avec Jenkins pour les tests automatisés. Nous sommes passés de ça à l’intégration continue complète sur ​​une série de sprints dédiés à l’amélioration de notre processus de déploiement. Ce billet va dans les détails de notre configuration et recense certains des défis que nous avons relevés le long du chemin.

Nous avons des logiciels, et des tests d’unités, et des environnements, mais rien pour les lier tous ensemble. Puis arriva Jenkins, probablement l’outil d’intégration continue le plus largement utilisé. Je n’étais pas un grand fan de Jenkins, mais il a su gagner mon admiration. Plus je l’utilise, plus je me rends compte que c’était mon propre biais et non Jenkins qui était le problème.

Tests d’unités

C’était notre première incursion dans CI, nous avions d’abord configuré Jenkins pour avoir des tests unitaires automatisés. Chaque fois qu’un développeur pousse du code vers le master, nous lançons un appel en boucle vers Jenkins qui déclenche la compilation d’une version de notre projet principal. Avant cela, les tests d’unitaires étaient exécutés par chaque développeur, avant de commettre parfois rarement.

Déployer à $ENVIRONNEMENT

Nous avons 4 environnements, DEVELOPMENT qui est une machine virtuelle que chaque développeur a où les changements de code sont fabriqués et testés par les personnes qui font le travail. INTÉGRATION où le code de plusieurs développeurs est vérifié et testé ensemble pour rechercher des régressions. STAGING où tout est préparé et testé pour la prochaine version dans un environnement « aussi près que possible de la production», et enfin PRODUCTION où le code en direct vit. Nous avons configuré le plugin « deploy pipeline » et configuré chaque étape de la construction Jenkins pour déployer du code vers le prochain environnement. Maintenant, dès que nous avons une compilation qui passe les tests, Jenkins pousse automatiquement à l’intégration, où nous pouvons faire nos tests de fumée interne. Actuellement, un processus manuel (cliquer sur un bouton) est nécessaire pour déployer cette compilation vers le STAGING, et un second clic est nécessaire pour déployer *ce code* à la PRODUCTION. Nous ne sommes pas tout à fait assez à l’aise avec nos tests unitaires et avec notre couverture de tests fonctionnels pour laisser Jenkins déploie cela pour nous, mais peut-être un jour.

Après chaque étape du déploiement, Jenkins peut exécuter des scripts ou des actions supplémentaires pour faire des choses comme nettoyer  Memcached, ou redémarrer Apache pour assurer un cache APC propre. Nous l’utilisons pour faire ces deux choses, et en plus pour informer New Relic que nous venons de faire un déploiement de production.

Mises en garde

Je n’ai pas vu un moyen d’utiliser rsync sur ssh pour copier des artefacts de compilation. Actuellement, autant que je sache, nous ne pouvons utiliser que scp, et vous pouvez oublier les liens symboliques, ils ne sont pas suivis, leurs destinations sont copiées. Il s’agit en fait d’un problème avec scp et non pas avec Jenkins.

Je n’ai pas trouvé un bon moyen de déployer des artefacts tout en maintenant des liens symboliques. Heureusement, nous avons seulement 1 lien symbolique essentiel à notre projet, qui est assez facile à recréer en utilisant un script que Jenkins appelle après un déploiement réussi vers le nouvel environnement.

Améliorations

Je serais ravi que Jenkins exécute automatiquement nos tests fonctionnels d’intégration pour nous, nous permettant de déployer vers le STAGING. Puisque nous utilisons Behat à l’interne pour nos tests fonctionnels, et que Behat peut formater sa sortie dans le style de Junit, ça ne devrait pas être difficile à faire. Nous avons juste besoin de trouver le temps.

Vous voulez aider?

Vous voulez nous aider à aller jusqu’au déploiement continu?
Nous recrutons: seedbox.com/carrieres

– Gabriel G.

Comments

comments