BitbucketCI/CDDevOpsAtlassian

Bitbucket Pipelines : de zéro à la CI/CD en production

18 juin 2026 · Sphinx-Digital

Bitbucket Pipelines est activé en un clic et ne nécessite aucune infrastructure à gérer. Pour une équipe déjà dans l’écosystème Atlassian, c’est souvent la voie la plus rapide vers une CI/CD opérationnelle. Voici le chemin complet, de zéro au déploiement automatisé.

Étape 1 : activer et comprendre les bases

Activez Pipelines dans Repository Settings → Pipelines → Settings. Dès lors, tout fichier nommé bitbucket-pipelines.yml à la racine du dépôt est interprété par Bitbucket.

Structure minimale :

image: python:3.12-slim   # image Docker utilisée pour les steps

pipelines:
  default:                # déclenché sur toutes les branches
    - step:
        name: Hello CI
        script:
          - echo "Premier pipeline Bitbucket !"
          - python --version

Commitez ce fichier — votre premier pipeline se déclenche immédiatement. Aucune configuration supplémentaire.

Étape 2 : ajouter des tests

image: python:3.12-slim

pipelines:
  default:
    - step:
        name: Tests
        caches:
          - pip            # cache des dépendances Python entre les runs
        script:
          - pip install -r requirements.txt
          - pytest tests/ --junitxml=test-results/report.xml --cov=src --cov-report=xml
        artifacts:
          - test-results/**   # conserver les rapports entre les steps
          - coverage.xml
        after-script:
          - pipe: atlassian/xunit-test-reporter:0.2.0
            variables:
              REPORT_PATHS: 'test-results/*.xml'

Le pipe xunit-test-reporter affiche les résultats de tests directement dans l’interface Bitbucket — les tests en échec apparaissent clairement sans avoir à lire les logs bruts.

Étape 3 : build et push d’une image Docker

image: python:3.12-slim

pipelines:
  default:
    - step:
        name: Tests
        caches: [pip]
        script:
          - pip install -r requirements.txt
          - pytest tests/ --cov=src --cov-report=xml
        artifacts: [coverage.xml]

  branches:
    main:
      - step:
          name: Tests
          caches: [pip]
          script:
            - pip install -r requirements.txt
            - pytest tests/
      - step:
          name: Build & Push Docker
          services:
            - docker           # active le daemon Docker dans ce step
          caches:
            - docker           # cache les layers Docker
          script:
            - echo $DOCKER_PASSWORD | docker login $DOCKER_REGISTRY
                -u $DOCKER_USERNAME --password-stdin
            - docker build
                --build-arg BUILD_DATE=$(date -u +%Y-%m-%dT%H:%M:%SZ)
                --build-arg GIT_SHA=$BITBUCKET_COMMIT
                -t $DOCKER_REGISTRY/myapp:$BITBUCKET_BUILD_NUMBER
                -t $DOCKER_REGISTRY/myapp:latest .
            - docker push $DOCKER_REGISTRY/myapp:$BITBUCKET_BUILD_NUMBER
            - docker push $DOCKER_REGISTRY/myapp:latest

Les variables $DOCKER_REGISTRY, $DOCKER_USERNAME et $DOCKER_PASSWORD sont définies dans Repository Settings → Pipelines → Repository variables, chiffrées et masquées dans les logs.

Étape 4 : déploiement multi-environnement

pipelines:
  branches:
    main:
      - step:
          name: Tests & Build
          script:
            - pytest tests/
            - docker build -t $REGISTRY/myapp:$BITBUCKET_BUILD_NUMBER .
            - docker push $REGISTRY/myapp:$BITBUCKET_BUILD_NUMBER

      - step:
          name: Deploy Staging
          deployment: staging           # lie ce step à l'env "staging"
          script:
            - pipe: atlassian/ssh-run:0.4.0
              variables:
                SSH_USER: $STAGING_USER
                SERVER: $STAGING_HOST
                COMMAND: |
                  docker pull $REGISTRY/myapp:$BITBUCKET_BUILD_NUMBER
                  docker stop myapp || true
                  docker run -d --name myapp --restart always
                    -p 8080:8080
                    $REGISTRY/myapp:$BITBUCKET_BUILD_NUMBER

      - step:
          name: Deploy Production
          deployment: production         # lié à l'env "production"
          trigger: manual               # validation humaine obligatoire
          script:
            - pipe: atlassian/ssh-run:0.4.0
              variables:
                SSH_USER: $PROD_USER
                SERVER: $PROD_HOST
                COMMAND: >
                  docker pull $REGISTRY/myapp:$BITBUCKET_BUILD_NUMBER &&
                  docker stop myapp || true &&
                  docker run -d --name myapp --restart always
                    -p 8080:8080
                    $REGISTRY/myapp:$BITBUCKET_BUILD_NUMBER

trigger: manual affiche un bouton dans l’interface Bitbucket. Le déploiement en production ne se fait qu’après validation humaine — le pipeline reste en attente indéfiniment jusqu’au clic.

Étape 5 : parallélisme et optimisation

Pour les suites de tests longues, le parallélisme réduit le temps d’attente :

- parallel:
    - step:
        name: Tests unitaires
        script: [pytest tests/unit/]
    - step:
        name: Tests d'intégration
        script: [pytest tests/integration/]
    - step:
        name: Lint & sécurité
        script:
          - ruff check .
          - bandit -r src/

Les trois steps s’exécutent simultanément. Si votre suite complète prend 12 minutes en séquentiel, le parallélisme peut la ramener à 5 minutes.

Étape 6 : intégration Jira

Ajoutez la référence du ticket Jira dans vos messages de commit :

git commit -m "PROJ-42 #done Ajouter l'authentification OAuth"

Bitbucket crée automatiquement un lien entre le commit, la Merge Request et le ticket Jira. Dans Jira, le ticket passe en « Done » et affiche les commits associés. La traçabilité code ↔ ticket est complète sans effort supplémentaire.

Récapitulatif des bonnes pratiques

  • Versionner le fichier YAML comme du code — chaque modification passe par une Merge Request
  • Ne jamais stocker de secrets dans le YAML — toujours utiliser les Repository Variables
  • Utiliser les caches (pip, npm, docker) — la différence de temps est significative
  • Séparer les pipelines par branche — strict sur main, plus permissif sur les features
  • Nommer les déploiements (deployment: staging/production) pour les tableaux de bord Bitbucket

Notre formation Bitbucket couvre Pipelines en détail avec des ateliers du premier pipeline jusqu’au déploiement multi-environnement dans l’écosystème Atlassian.