🧩 Bitbucket Pipelines — CI/CD Atlassian

Pipeline type : fast PR + full main + deploy

pipelines:
  pull-requests:
    "**":
      - step: { name: "Lint+Unit", script: ["ruff check .", "pytest -q"] }

  branches:
    main:
      - step: { name: "Build", script: ["python -m build"], artifacts: ["dist/**"] }
      - step:
          name: "Deploy Staging"
          deployment: staging
          script: ["./deploy.sh staging"]
      - step:
          name: "Deploy Prod"
          deployment: production
          script: ["./deploy.sh production"]
        

Écosystème Atlassian (où Pipelines s’aligne bien)

• Bitbucket + Jira : traçabilité tickets ↔ commits ↔ builds (dans les pratiques d’équipe).
• Standardisation : conventions pipeline par repo/workspace (templates internes).
• Gouvernance : secrets masqués + runners isolés + “deployment variables”. :contentReference[oaicite:9]{index=9}

Types de pipelines (pattern d’équipe)

Services (DB / Redis / etc.) — concept

Les services permettent de démarrer des conteneurs auxiliaires (ex : Postgres) accessibles depuis le step. Voir la configuration reference pour les options exactes. :contentReference[oaicite:11]{index=11}

definitions:
  services:
    postgres:
      image: postgres:16
      variables:
        POSTGRES_PASSWORD: "postgres"
        

Anchors YAML = DRY simple

# Exemple concept
definitions:
  steps:
    - step: &lint_test
        name: "Lint+Unit"
        image: python:3.12
        script:
          - pip install -r requirements.txt
          - ruff check .
          - pytest -q

pipelines:
  pull-requests:
    "**":
      - step: *lint_test
        

Step options (caches / artifacts / etc.)

Atlassian documente les options de step, dont la gestion des artifacts (paths, download) et les patterns glob. :contentReference[oaicite:13]{index=13}

- step:
    name: "Package"
    script:
      - python -m build
    artifacts:
      - "dist/**"
        

Exemple Django (lint + tests + report)

image: python:3.12

pipelines:
  pull-requests:
    "**":
      - step:
          name: "Lint + Unit"
          caches:
            - pip
          script:
            - pip install -U pip
            - pip install -r requirements.txt
            - ruff check .
            - pytest -q --maxfail=1
  branches:
    main:
      - step:
          name: "Build"
          caches:
            - pip
          script:
            - pip install -U pip
            - pip install -r requirements.txt
            - python -m build
          artifacts:
            - "dist/**"
        

Déploiement (deployment env)

La doc référence couvre les options associées aux déploiements, et Atlassian explique aussi les variables/secrets et leur portée (repository/deployment). :contentReference[oaicite:15]{index=15}

pipelines:
  branches:
    main:
      - step:
          name: "Deploy Staging"
          deployment: staging
          script:
            - ./deploy.sh staging
      - step:
          name: "Deploy Prod"
          deployment: production
          script:
            - ./deploy.sh production
        

Artifacts (partage entre steps)

Atlassian détaille l’option artifacts et les “artifact paths” via les step options. :contentReference[oaicite:16]{index=16}

- step:
    name: "Build"
    script:
      - make build
    artifacts:
      - "dist/**"
      - "reports/**"
        

3 quick wins

• Cache deps + lockfiles (pip/poetry/npm) → baisse drastique du temps.
• Artifacts = uniquement l’output utile pour deploy (pas tout le workspace).
• Conserver reports tests → debug “instant”.

Exemple (concept) : utilisation d’un pipe

- step:
    name: "Deploy via Pipe"
    script:
      - pipe: atlassian/some-pipe:1.2.3
        variables:
          VAR1: $VAR1
          VAR2: $VAR2
        

Gouvernance supply chain (pratique)

• Éviter pipes inconnus non maintenus (risque supply chain).
• Pin version + review de la config (comme une dépendance code).
• Limiter secrets exposés aux pipes (scope minimal).

Configurer un runner dans le YAML

Atlassian décrit comment cibler un runner dans bitbucket-pipelines.yml et mentionne aussi la parité de ressources / version runner. :contentReference[oaicite:20]{index=20}

# Exemple concept (les champs exacts dépendent de ta config runner)
- step:
    name: "Build on Runner"
    runs-on:
      - "self.hosted"
      - "linux"
      - "prod-runner"
    script:
      - ./build.sh
        

Notes importantes

• Runners peuvent être ajoutés au niveau repo ou workspace (jusqu’à 100 selon la doc). :contentReference[oaicite:21]{index=21}
• Hardening obligatoire (réseau, patching, rotation).
• Éviter un runner “fourre-tout” partagé à la prod : isoler par labels/pool.

Masking des variables sécurisées

Pipelines masque les variables sécurisées dans les logs : si une valeur apparaît, elle est remplacée par $VARIABLE_NAME. :contentReference[oaicite:23]{index=23}

Pratiques recommandées (Atlassian)

Atlassian publie un article de bonnes pratiques sur la gestion des secrets : variables sécurisées, SSH keys, pratiques d’artifacts, etc. :contentReference[oaicite:24]{index=24}

• Secrets uniquement au niveau nécessaire (least privilege).
• Rotation périodique + audit des usages.
• Éviter de faire passer des secrets via artifacts (risque de fuite).

Scopes & precedence (utile en prod)

Atlassian détaille la notion de variables de dépôt et de déploiement et leur priorité (important pour éviter collisions). :contentReference[oaicite:25]{index=25}

Pattern recommandé:
- repo variables: CI non-sensibles + defaults
- deployment variables: secrets/env spécifiques (staging/prod)
- noms clairs: STAGING_*, PROD_*
        

Variables de déploiement (staging/prod)

Atlassian distingue les variables de repository et de deployment (et leur priorité). :contentReference[oaicite:27]{index=27}

Ex:
- deployment: staging
  uses variables: STAGING_DB_URL, STAGING_TOKEN (secured)

- deployment: production
  uses variables: PROD_DB_URL, PROD_TOKEN (secured)
        

Gates (processus)

• Gate “humain” (ex : validation release) : process interne + protection des secrets prod.
• Runner prod dédié + isolation réseau.
• Secrets prod uniquement dans “deployment variables” (pas repo variables).

Security baseline

• Appliquer les recommandations Atlassian pour secrets/SSH keys/artifacts. :contentReference[oaicite:33]{index=33}
• Ne jamais exposer secrets via logs (même si masqués, éviter d’imprimer).
• Runner hardening + segmentation réseau.

Phrase CV-ready

Industrialisation CI/CD sur Bitbucket Pipelines : pipelines as code (bitbucket-pipelines.yml),
stratégie PR “fast” + main “release-ready”, optimisation via caches + artifacts (handoff build→deploy),
intégrations standardisées via Pipes, sécurisation par variables “secured” masquées et variables de déploiement,
et exécution hybride cloud + runners self-hosted isolés (VPC/on-prem) pour déploiements sensibles.
        

Stratégie progressive (safe)

1. Pilote sur 1–2 repos (non critiques).
2. Reproduire la CI “fonctionnelle” avant d’optimiser.
3. Installer les conventions YAML (anchors, naming, structure).
4. Définir la politique secrets (repo vs deployment vars, secured).
5. Si besoin : déployer runners self-hosted (pool staging/prod). :contentReference[oaicite:39]{index=39}

Pièges fréquents

• Artifacts trop gros / mal ciblés → pipelines lents. :contentReference[oaicite:40]{index=40}
• Variables “secured” imprimées dans logs → masquées (confusion) et risque. :contentReference[oaicite:41]{index=41}
• Runner prod partagé avec repos non-prod → surface d’attaque.
• Pipes non contrôlés (supply chain) → pinning + review.

Checklist