Utiliser des déploiements basés sur des branches dans votre pipeline de livraison continue

L'une des questions que nous devons nous poser est la suivante : la livraison continue vers où ? Et à partir d'où, d'ailleurs.

Sarah Goff-Dupont Sarah Goff-Dupont

Nous utilisons souvent des termes tels que « pipeline » pour décrire le flux continu de code de votre dépôt vers vos utilisateurs. Mais lorsque vous le cartographiez sur papier, ce pipeline ressemblera plus à un réseau, surtout si vous utilisez un workflow « branch-and-merge » (ce que nous vous recommandons fortement).

Si vous développez sur une branche, il est logique que cette branche dispose de son propre chemin de déploiement afin que les changements puissent être testés de manière approfondie avant d'être mergés dans la branche principale, ou même livrés directement aux clients. Les outils de développement Atlassian prennent plutôt bien en charge le déploiement de branches, comme vous le verrez.

Je vais commencer par passer en revue les trois principaux cas d'usage, puis je présenterai les intégrations entre Jira Software, Bitbucket et Bamboo qui vous aident à les mettre en pratique.

Le cas des déploiements basés sur des branches

Au fond, l'intégration de votre réseau de branches à votre pipeline de livraison continue se justifie par sa commodité. Si vous partagez un environnement de test avec d'autres membres de l'équipe, il est plus simple de coordonner une cadence de déploiements représentant des flux de travail distincts que de merger tous les flux avant de les déployer en environnement de test et de devoir les démêler lorsque de nouveaux changements sont (inévitablement) nécessaires.

Si vous avez la chance de disposer de plusieurs environnements de test, c'est encore plus simple. Il en va de même pour la livraison aux clients. En effet, certaines équipes aiment livrer directement à partir de branches, puis merger les mises à jour de leurs branches vers la branche principale.

Déclenchez automatiquement les déploiements à partir d'une branche de fonctionnalités

L'utilisation de branches de fonctionnalités pour les user stories et les corrections de bugs est un excellent moyen de pusher les changements vers votre dépôt dans Bitbucket (permettant ainsi à l'intégration continue d'y fonctionner) sans soumettre le reste de votre équipe à des builds non fonctionnels et à des échecs de test pendant que le travail est en cours.

Si votre équipe préfère la livraison à partir de la branche principale, vous souhaiterez probablement déployer ce code dans des environnements internes pour des tests exploratoires et d'acceptation. Cela fonctionne mieux lorsque votre équipe peut déployer du code dans une poignée d'environnements de test, car cela évite de devoir attendre son tour pour utiliser un environnement unique et partagé.

Grâce aux déploiements de branches dans Bamboo, vous pouvez configurer le déclencheur de déploiement pour tout environnement afin de déployer automatiquement les artefacts conçus sur une branche donnée, soit à intervalles planifiés, soit à chaque build de CI fonctionnel de cette branche. Vous pouvez même utiliser conjointement les deux types de déclencheur.

Capture d'écran d'un environnement de test

Imaginons que vous ayez un environnement unique de test des performances que tout le monde partage. Tout au long de la journée, déployez la branche principale partout où le build est fonctionnel. Pour la plupart des équipes qui apprécient les branches, les builds de la branche principale sont habituellement le résultat de nouvelles tâches mergées, donc vous devriez évaluer les performances immédiatement.

Ensuite, pendant la nuit, lorsque le dépôt est inactif, planifiez des déploiements à partir de la branche de chaque développeur à des intervalles appropriés afin que tout le monde reçoive du feedback de performance sur son travail au moins une fois par jour. (Les tâches de déploiement sur Bamboo peuvent se conclure par un script ou une tâche Ant ou Maven qui lance des tests de performance.) Pendant ce temps, les développeurs peuvent utiliser des déclencheurs de déploiement automatique pour envoyer des builds à leurs environnements de test individuels dès que le build de leur branche de fonctionnalité est fonctionnel.

Pour mettre tout cela en place, vous pouvez soit créer un projet de déploiement distinct dans Bamboo pour votre branche de développement, soit associer votre branche à un environnement dans un projet de déploiement en personnalisant la façon dont les déploiements vers l'environnement sont déclenchés.

Capture d'écran d'une création de projet de déploiement

Consultez la documentation Bamboo pour obtenir des instructions détaillées sur l'association d'un projet de déploiement à une branche ainsi que sur la personnalisation des déclencheurs de déploiement.

Livrez depuis une branche de version

Pour les équipes qui préfèrent ajouter le travail en cours directement sur la ligne de code principale, la livraison à partir d'une branche est plus attrayante. Pendant que la branche principale ou trunk est déployée dans l'environnement de test, les branches de version sont celles que vous déployez en staging, puis en production. Elles peuvent également être utilisées dans le cadre de l'approche Gitflow.

Capture d'écran Gitflow

Les branches de version sont régulièrement coupées, et les changements sont livrés à partir de là. La plupart des équipes souhaitent une prise de décision humaine quant au moment et à l'endroit où déployer une branche de version, plutôt qu'un déclencheur automatique. Pas de problème.

Bamboo propose ce concept de « versions ». Il s'agit d'entités au sein de Bamboo qui intègrent les artefacts les plus récents développés à partir d'une certaine branche, ainsi que tous les commits, résultats des tests, et tickets Jira associés à tous les builds sur cette branche depuis la dernière création d'une version. Ainsi, une version se compose essentiellement de vos artefacts sous forme de package ainsi que d'un grand nombre de métadonnées.

Nous souhaitons faire en sorte que toutes ces données riches et précieuses circulent dans votre pipeline de livraison continue avec les artefacts associés pour que vous puissiez remonter jusqu'au premier commit et à la user story initiale. (Je crois que Geoffrey Chaucer a été le premier à dire : « Tous les chemins mènent à Jira Software. ») Du point de vue conceptuel, plus qu'un simple build, il s'agit donc de la version que vous promouvez dans vos environnements. Et c'est cette version qui apparaîtra dans l'interface utilisateur de Bamboo.

Capture d'écran des versions dans l'environnement de staging Bamboo

Quoi qu'il en soit, revenons aux déclencheurs. Lorsque les déploiements sont déclenchés automatiquement, comme dans le cas ci-dessus, une version est automatiquement créée par Bamboo.

Mais les déploiements par simple pression d'un bouton sont différents. Dans ce cas, créez la version (vous pouvez le faire à partir de l'écran des résultats des builds ou à partir d'un projet de déploiement), donnez-lui un nom, puis sélectionnez le build à partir duquel extraire les artefacts. Une fois la version créée, vous pouvez la déployer dans n'importe quel environnement, et même directement en production, si c'est inévitable. Les équipes qui utilisent cette approche créent généralement plusieurs versions (des versions candidates, en réalité) avant d'en approuver une et de la faire avancer dans le pipeline.

Au moment de promouvoir la version vers l'environnement suivant, accédez à l'écran All deployment projects (Tous les projets de déploiement), où vous verrez tous vos projets de déploiement (sérieusement ?) ainsi que tous les environnements associés à chaque projet. Cliquez sur l'icône Deploy (Déployer) en regard de votre environnement cible, puis parcourez l'assistant de prévisualisation du déploiement, en sélectionnant l'option Deploy an existing release (Déployer une version existante) comme décrit plus en détail sur la page liée.

Livrez des mises à jour des versions prises en charge

Si vous ne fonctionnez pas en SaaS, vous devez probablement prendre en charge plusieurs versions de votre logiciel simultanément, et livrer occasionnellement des corrections critiques, ou encore des mises à jour de sécurité de rétroportage. Cela signifie que vous devez maintenir des branches de version stables pendant une très longue période, des années très probablement. Les builds de ces branches sont généralement déployés dans un emplacement commun, tel qu'un site web ou un dépôt externe, où les clients peuvent faire des pulls des mises à jour vers les versions qu'ils utilisent.

Capture d'écran d'un workflow de versions multiples

Pour ces branches, la façon la plus simple de transformer les builds en version est d'utiliser le bouton Create release (Créer une version) qui se trouve sur l'écran de résultat des builds pour le build que vous livrez. Bien sûr, vous pouvez commencer à l'écran All deployment projects (Tous les projets de déploiement) comme décrit ci-dessus. Mais parce que vous vous concentrez sur un build très spécifique que vous voulez livrer (qui n'est pas nécessairement le build le plus récent sur cette branche), commencer à partir de l'écran des résultats du build fournit, selon moi, une assurance supplémentaire quant au fait qu'il s'agit bien du build que vous souhaitez livrer.

Assemblez un pipeline de livraison continue à la fois

Les déploiements basés sur les branches sont l'extension naturelle des branches de plan de Bamboo qui, à leur tour, sont l'extension naturelle de tout système de branche que vous avez mis en place pour votre équipe dans Bitbucket. Comme je vous l'ai montré ici, et comme je l'ai longuement abordé

dans d'autres articles, vous pouvez faire un choix parmi plusieurs modèles compatibles avec la CD.

Votre système de branche doit refléter la manière dont votre équipe aborde et réalise le travail.

Passons maintenant en revue les différents éléments qui entrent en jeu :

  • Tickets Jira : n'oubliez pas, les clés de ticket sont magiques. Incluez-les dans le nom de vos branches et de vos messages de commit afin que tous les commits, les builds et les déploiements (même les pull requests !) renvoient vers le ticket.
  • Branches : saviez-vous que lorsque Bitbucket est connecté à Jira Software, chaque ticket comporte un lien pratique permettant de créer une branche ? Et que si vous suivez ce lien, la clé de ticket sera automatiquement ajoutée au nom de la branche ? Nous croyons réellement qu'il est utile de créer une branche pour chaque ticket sur lequel vous travaillez. Essayez lors de votre prochain sprint, ne serait-ce que pour vous amuser un peu.
  • Branches de planification : Bamboo détecte automatiquement les nouvelles branches dans vos dépôts Git, Mercurial et Subversion si vous activez la gestion automatique des branches. Au moment où vous exécutez votre premier commit, Bamboo a déjà lancé le test de cette branche.
  • Projets de déploiement : la phase de « livraison » de votre pipeline de livraison continue. Vous allez associer un dépôt et un ou plusieurs environnements avec chaque projet de déploiement.
  • Environnements : représentation par Bamboo des environnements de votre réseau. Chaque environnement peut être associé à différentes branches, utiliser divers déclencheurs de déploiement et différentes étapes (appelées tâches) pour exécuter un déploiement sans le moindre accroc.
  • Version : artefacts en package + métadonnées. En analysant une version donnée dans Bamboo, vous pourrez consulter tous les tickets Jira (les clés de ticket sont magiques !), les commits, les résultats de test et les artefacts associés. Vous pouvez même voir les environnements dans lesquels elle a été déployée et l'indiquer comme approuvée pour la promotion via le pipeline ou rejetée.

Chaque cas d'usage abordé ici est utilisé par au moins une équipe de développement d'Atlassian. Certaines équipes les combinent même. Pour être tout à fait honnête, la transition d'un pipeline de livraison continue unique (ou de l'absence de pipeline) à un réseau de pipelines basés sur des branches prendra plus de temps que vous ne l'escomptez, et mettra en évidence des aspects non optimaux de vos processus actuels sur lesquels vous devrez travailler.

Mais ce n'est pas un problème. Lancez-vous et faites-nous savoir comment ça se passe ! Envoyez-nous un tweet à @Atlassian, ou suivez le blog Atlassian pour en savoir plus sur Agile, Git et les outils de développement.