Bitbucket Pipelines : CI/CD natif sans infrastructure à gérer

Bitbucket Pipelines est souvent sous-estimé par les équipes qui utilisent déjà l’écosystème Atlassian. Il est pourtant capable de couvrir la grande majorité des besoins CI/CD sans infrastructure externe à gérer.

Anatomie d’un bitbucket-pipelines.yml

Le fichier de configuration vit à la racine du dépôt. Sa structure est proche de GitLab CI :

image: python:3.12-slim

pipelines:
  default:          # déclenché sur toutes les branches
    - step:
        name: Tests & Lint
        caches:
          - pip
        script:
          - pip install -r requirements.txt
          - ruff check .
          - pytest tests/ --junitxml=test-results/results.xml
        after-script:
          - pipe: atlassian/xunit-test-reporter:0.2.0
            variables:
              REPORT_PATHS: 'test-results/*.xml'

  branches:
    main:           # uniquement sur main
      - step:
          name: Tests
          script:
            - pip install -r requirements.txt
            - pytest tests/
      - step:
          name: Build & Push Docker
          services:
            - docker
          script:
            - docker build -t $DOCKER_REGISTRY/myapp:$BITBUCKET_BUILD_NUMBER .
            - docker push $DOCKER_REGISTRY/myapp:$BITBUCKET_BUILD_NUMBER
      - step:
          name: Déploiement Production
          deployment: production
          trigger: manual    # validation humaine requise
          script:
            - ./deploy.sh production $BITBUCKET_BUILD_NUMBER

Variables et secrets

Les secrets (tokens, mots de passe, clés API) se configurent dans Repository Settings → Pipelines → Repository variables. Ils sont chiffrés et ne s’affichent pas dans les logs. Les variables sont accessibles dans le pipeline comme des variables d’environnement.

Bitbucket expose aussi des variables automatiques utiles :

$BITBUCKET_BRANCH — la branche courante
$BITBUCKET_BUILD_NUMBER — numéro de build incrémental
$BITBUCKET_COMMIT — SHA du commit
$BITBUCKET_PR_ID — numéro de la pull request (si PR pipeline)

Caches et performances

Sans cache, chaque pipeline réinstalle toutes les dépendances depuis zéro. Bitbucket Pipelines supporte le cache natif :

definitions:
  caches:
    npm:                      # cache npm natif
      path: ~/.npm
    pip-custom:               # cache personnalisé
      path: ~/.cache/pip
    node-modules:
      path: node_modules      # cache du dossier node_modules

pipelines:
  default:
    - step:
        caches:
          - npm
          - node-modules
        script:
          - npm ci
          - npm test

Le cache est partagé entre les runs sur la même branche et réduit significativement le temps de pipeline.

Smart Commits : lier code et Jira

L’intégration Bitbucket-Jira permet de transitionner des tickets automatiquement depuis les messages de commit :

# Dans votre message de commit :
git commit -m "PROJ-123 #done Fix auth timeout"

# Résultat dans Jira :
# - Ticket PROJ-123 passé à "Done"
# - Commit lié au ticket

Syntaxe : <CLEF-TICKET> #<transition> <commentaire optionnel>. Les transitions disponibles (done, in-progress, resolve…) correspondent à votre workflow Jira.

Pipes : les actions réutilisables de Bitbucket

Les Pipes sont l’équivalent des Actions GitHub — des steps préconfigurés pour des tâches communes :

- pipe: atlassian/aws-ecs-deploy:1.0.0
  variables:
    AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
    AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
    AWS_DEFAULT_REGION: 'eu-west-1'
    CLUSTER_NAME: 'production'
    SERVICE_NAME: 'myapp'
    DOCKER_IMAGE: 'myapp:$BITBUCKET_BUILD_NUMBER'

Des pipes existent pour AWS, GCP, Azure, Slack, Datadog, SonarCloud et une quarantaine d’autres intégrations.

Notre formation Bitbucket couvre les Pipelines, les Pull Requests avancées et l’intégration complète dans l’écosystème Atlassian.