Exécution de branches de fonctionnalités grâce à Bitbucket Pipelines

Découvrez comment réussir la livraison continue grâce à un Gitflow ou un workflow de branche par fonctionnalité. 

Sten Pittet Sten Pittet

Que vous utilisiez Gitflow ou simplement des branches de fonctionnalités avec une branche principale, vous pouvez facilement adopter la livraison continue (CD) grâce à Bitbucket Pipelines. Inutile de configurer un serveur d'intégration continue (CI) complexe, il vous suffit d'activer Pipelines et de définir vos workflows pour pouvoir exécuter des tests et des déploiements sur vos branches.

Pipeline Bitbucket

Dans ce tutoriel, nous verrons comment configurer simplement Bitbucket Pipelines pour exécuter différents pipelines pour différentes branches, et comment protéger vos branches contre les merges incorrects.

Étape 1 : Commencez par des pipelines par défaut à exécuter sur des branches de fonctionnalités

L'utilisation de branches de fonctionnalités est un excellent moyen d'empêcher les dysfonctionnements trop fréquents de la branche principale. Les développeurs peuvent travailler sur une amélioration spécifique d'une branche distincte et merger leurs changements lorsque leur build est fonctionnel. Cela dit, il est toujours essentiel de maintenir la stabilité de vos branches de fonctionnalités. Pour permettre une bonne collaboration, il est tout aussi important de garantir leur bon fonctionnement. L'utilisation de ces dernières permet de mieux comprendre les changements apportés pour résoudre un ticket spécifique. Elle ne doit pas être l'occasion de transiger sur la qualité.

Lors de l'activation des Bitbucket Pipelines, la première étape consiste donc à créer un pipeline par défaut qui exécutera des tests pour chaque branche. Pour ce faire, sélectionnez simplement l'un des modèles par défaut disponibles.

Configuration du pipeline JavaScript par défaut

Tous les modèles propres à la langue utilisent un pipeline par défaut sous le mot-clé par défaut qui sera exécuté pour chaque nouvelle branche pushée. Vous pouvez simplement commiter le fichier de configuration bitbucket-pipelines.yml dans votre dépôt pour que votre premier pipeline soit exécuté sur la branche principale.

Notre premier pipeline exécuté pour la branche master

Vous pouvez simplement faire un push d'une nouvelle branche comprenant des changements pour vérifier que le même pipeline s'exécute sur une branche différente.

Étape 2 : Ajoutez un nouveau pipeline pour la branche principale

Si vous pratiquez la livraison continue, vous voudrez sans doute que les changements pushés vers la branche principale soient automatiquement déployés dans un environnement de staging. Pour y parvenir, nous ajouterons un nouveau pipeline de branche qui déploie le code après avoir exécuté des tests et qui n'est exécuté que pour la branche principale.

image: node:4.6.0
   pipelines:
   default:
     - step:
         script:
           - npm install
           - npm test
   branches:
     main:
       - step:
           script:
             - npm install
             - npm test
             - ./deploy.sh  

Nous définissons le pipeline que nous souhaitons exécuter lorsque les changements sont pushés vers la branche principale dans la section branches du fichier de configuration YML ci-dessus.

Désormais, un push vers la branche principale déclenchera un déploiement après le développement et le test de l'app. Toute autre branche du dépôt va simplement développer et tester les nouveaux changements.

Étape 3 : Protégez vos branches de fonctionnalités

Une fois l'étape 2 exécutée, tout développeur peut lancer une version en production en mergeant simplement ses changements dans la branche principale. Cette situation est risquée, car quelqu'un pourrait déployer des changements qui n'ont pas encore été examinés par mégarde. Heureusement, vous pouvez facilement l'empêcher en ajoutant des autorisations à vos branches dans Bitbucket.

Accédez à Settings > Branch permissions ( Paramètres > Autorisations de branches) dans votre dépôt.

Autorisations de branches

Ajoutez une nouvelle autorisation pour la branche principale, en laissant l'accès en écriture vide (champ « Write Access ») pour empêcher les développeurs de faire un push directement vers cette branche. Ensuite, ajoutez-vous à l'autorisation de merge via une pull request (champ « Merge via pull request »).

Ajout d'une autorisation de branche

Avant d'enregistrer la nouvelle autorisation de branche, nous allons ajouter un contrôle de merge pour nous assurer que les merges ne sont pas autorisés, sauf si au moins un build est fonctionnel. Développez simplement la section des contrôles de merge pour activer la fonctionnalité correspondante.

Ajout d'une autorisation de branche

Après l'enregistrement, vous pouvez vérifier que la branche est correctement protégée. Aucun utilisateur ou groupe ne doit disposer d'un accès en écriture, et les merges via une pull request doivent être autorisés pour les membres de votre équipe en lesquels vous avez confiance.

Étape 4 : Utilisez des pull requests pour promouvoir les changements apportés en production

Comme vous ne pouvez plus faire un push directement vers la branche principale, vous devrez utiliser des pull requests pour déployer en production. Une fois la pull request créée, il vous suffit de merger les changements apportés dans la branche principale pour déclencher le pipeline de déploiement.

Pull request Bitbucket

Après le merge, vous pouvez accéder à la section Pipelines de votre dépôt pour voir le déploiement en action.

Journaux Bitbucket Pipelines

Nous avons vu les bases pour exécuter des branches de fonctionnalités grâce à Bitbucket Pipelines. Vous pouvez adapter cet exemple à vos besoins et créer votre propre pipeline de livraison continue. Vous pouvez également en apprendre davantage grâce à nos guides sur la livraison continue et le déploiement continu.