🎋 Bamboo (Atlassian) — Guide CI/CD DevOps

Quand Bamboo est un bon choix ?

Bamboo vs Jenkins vs GitLab CI (lecture rapide)

Liens officiels (Atlassian)

• Page produit Bamboo
• Documentation Bamboo (Confluence Atlassian)
• Atlassian Community

Artefacts : la sortie “immuable” du build

Un bon pipeline produit un artefact versionné et immuable (zip, wheel, jar, image docker). Ensuite, on promeut le même artefact en dev → stage → prod (plutôt que reconstruire).

                    Exemple “promote” :
                    - Build produit: app:1.2.3
                    - Deploy DEV : app:1.2.3
                    - Validation QA
                    - Promote STAGE : app:1.2.3
                    - Promote PROD : app:1.2.3  (zéro rebuild)
                

Branches, PR, déclencheurs

                            Branche feature/*
                            - CI rapide: lint + unit tests
                            Branche main
                            - CI complet: unit + integration + build image
                            Tag vX.Y.Z
                            - Release: publish + deploy staging + approval + prod
                        

Variables & Secrets (principes non négociables)

                            ❌ AWS_SECRET_ACCESS_KEY dans un script
                            ❌ Mot de passe DB en clair dans un repo
                            ❌ Même secret pour DEV et PROD
                            ❌ Logs qui affichent les tokens (echo $TOKEN)
                        

                            ✅ Variables par environnement
                            ✅ Rotation des secrets
                            ✅ Permissions minimales (least privilege)
                            ✅ Audit des accès
                        

Agents : le “compute layer” de Bamboo

                            Agent: build-linux-01
                            - docker=true
                            - java=17
                            - node=20
                            - python=3.12
                            - terraform=1.7
                            - awscli=2.x
                            - memory_gb=32
                        

                            Job "Build Docker Image"
                            - requires: docker=true, memory_gb>=16
                            Job "Backend Tests"
                            - requires: python=3.12
                            Job "Terraform Plan"
                            - requires: terraform=1.7, awscli=2.x
                        

Scalabilité & haute disponibilité (vision)

En entreprise, l’objectif est de rendre la CI/CD résiliente (pannes) et scalable (pics de builds). La stratégie la plus simple : multiplier les agents + bien dimensionner le serveur.

Artefacts & stockage

                            frontend-dist.zip
                            backend-wheel.whl
                            app.jar
                            docker image: registry/app:1.2.3
                            terraform plan file (si politique autorise)
                        

Exemple complet : App Django + Front React + Docker

                            JOB: backend-tests
                            - checkout
                            - python -m venv venv
                            - pip install -r requirements.txt
                            - pytest -q

                            JOB: frontend-tests
                            - checkout
                            - npm ci
                            - npm test
                        

                            JOB: package
                            - docker build -t registry/app:${bamboo.buildNumber} .
                            - docker push registry/app:${bamboo.buildNumber}
                            - publish artefact: build-metadata.json
                        

                            registry/app:1234
                            build-metadata.json
                            - git_sha
                            - build_number
                            - timestamp
                            - dependencies digest
                        

Quality gates : éviter le “green build” trompeur

Versionner proprement : buildNumber vs semver

                            version = buildNumber
                            image = app:${buildNumber}
                        

                            tag Git: v1.8.0
                            image: app:1.8.0
                            image: app:1.8.0+build1234
                        

Environnements : isolation et gouvernance

Approvals, “promotion”, rollback

                            - Même artefact R1234
                            - Promu DEV → STAGE → PROD
                            - Pas de rebuild
                        

Exemple de déploiement AWS (pattern)

                    Artefact: docker image registry/app:R1234

                    DEV:
                    - deploy ECS service (desiredCount=1)
                    - run smoke tests

                    STAGE:
                    - deploy ECS service (blue/green)
                    - approval QA

                    PROD:
                    - deploy blue/green (canary 10%)
                    - monitoring + auto rollback si erreurs
                

Tu peux remplacer ECS par EC2 (pull image + restart), ou K8s (kubectl apply / helm upgrade).

Notifications (pattern)

• Slack / Teams : build failed, deployment succeeded
• Email : release approvals, incidents
• Jira : transition automatique du ticket (selon policy)

Webhooks (pattern)

                    - Trigger build on push
                    - Notify external system on release
                    - Update status dashboards (Grafana/Statuspage-like)
                

Exemple pipeline Django “pro”

                    # backend job (agent: python=3.12)
                    python -m venv venv
                    source venv/bin/activate
                    pip install -r requirements.txt
                    ruff check .
                    pytest -q --maxfail=1
                    python manage.py check --deploy
                

Docker build & publish (pattern)

                    docker build -t registry/ideolab-app:${bamboo.buildNumber} .
                    docker push registry/ideolab-app:${bamboo.buildNumber}

                    # option: tag "latest" seulement sur main
                

Infrastructure as Code (Terraform) — pattern safe

                    terraform fmt -check
                    terraform validate
                    terraform plan -out plan.tfplan

                    # apply seulement après approval (staging/prod)
                    terraform apply plan.tfplan
                

Gestion des secrets : règles d’entreprise

                    ✅ Secrets par env (DEV != PROD)
                    ✅ Rotation + expiration
                    ✅ Accès minimal (least privilege)
                    ✅ Masquage dans logs
                    ❌ Jamais de secrets dans le repo
                

Audit & conformité

• Qui a lancé un build ?
• Qui a approuvé une release ?
• Quel commit exact est en prod ?

Stratégie agents (pragmatique)

• 2 pools : fast CI (petits agents) + heavy builds (gros agents)
• Capacités strictes (docker/java/node/python)
• Éviter la dérive : agents “pet” vs “cattle” (reprovision)

Cache : gagner x2 à x10 sur le temps CI

                    Caches utiles:
                    - pip cache / wheels
                    - npm cache
                    - maven/gradle cache
                    - docker layer cache (si architecture le permet)
                

Release engineering : version, tags, changelog

                    - Tag Git = vérité (vX.Y.Z)
                    - Build produit artefact versionné
                    - Changelog auto (conventional commits)
                    - Déploiement prod = approval + window + monitoring
                

Une ligne “CV-ready” (Bamboo)

                    Mise en place de pipelines CI/CD Bamboo (build, tests, quality gates, artefacts immuables)
                    et déploiements multi-environnements (dev/stage/prod) avec traçabilité Jira/Bitbucket.
                

Tu peux rajouter la stack : Docker, AWS, Terraform, Python/Django, Node… selon ton contexte.

Builds qui “flaky” ou timeouts

• Isoler dépendances (versions figées)
• Éviter reliance “réseau” instable (mirror, caches)
• Augmenter timeouts uniquement après avoir compris le goulot

Accès refusé / deploy impossible

• Vérifier RBAC sur Plan et Deployment project
• Vérifier droits “approval” (prod)
• Vérifier tokens/credentials (scopes minimaux)

Cache qui casse la reproductibilité

                    Symptômes:
                    - build OK hier, KO aujourd'hui sans changement
                    - dépendance différente installée
                    Actions:
                    - purge cache
                    - lockfiles stricts
                    - pin versions
                

Stratégie de migration (safe)

1. Commencer par 1 pipeline “pilote” (service non critique)
2. Reproduire build+tests à l’identique (comparaison outputs)
3. Mettre en place artefacts immuables + promotion
4. Déployer DEV puis STAGE, et prod en dernier
5. Basculer “repo triggers” progressivement

Pièges fréquents

• Scripts Jenkins trop spécifiques aux nodes (chemins, outils non standard)
• Secrets gérés “à la main” → à normaliser
• Builds non déterministes (versions non figées)
• Absence d’artefacts immuables (rebuild à chaque env)

Checklist entreprise