🏙️ TeamCity (JetBrains) — Guide CI/CD DevOps

Éditions (On-Prem vs Cloud)

Quand TeamCity est un excellent choix ?

Comparatif express

Agents & “requirements” (équivalent capacities/labels)

                            Build Config: "docker-image"
                            Requirements:
                            - docker.server.version exists
                            - teamcity.agent.jvm.os.name = Linux
                            - env.MEM_GB >= 16

                            Build Config: "android"
                            Requirements:
                            - env.ANDROID_HOME exists
                            - teamcity.agent.jvm.os.name = Linux OR macOS
                        

Réseau / Proxy / communication agent-server

En entreprise, TeamCity est souvent derrière un proxy/reverse-proxy (TLS, headers, auth), et les agents doivent pouvoir joindre le server de manière fiable.

• Stabiliser DNS/Certificates (TLS) et accès sortant des agents.
• Isoler les pools d’agents (prod vs non-prod) si besoin.
• Durcir les permissions des comptes qui exécutent les builds.

Stockage & artefacts

                            frontend-dist.zip
                            backend-wheel.whl
                            app.jar
                            docker image: registry/app:1.2.3
                            reports: coverage.xml, junit.xml, sbom.json
                        

Templates : factoriser (éviter duplication)

                            Template: "python-ci"
                            - steps: venv, pip install, ruff, pytest
                            - artifacts: junit.xml, coverage.xml
                            - parameters: PY_VERSION, REQUIREMENTS_FILE
                            - requirements: python exists

                            Build Config "svc-users" uses template "python-ci"
                            Build Config "svc-billing" uses template "python-ci"
                        

Kotlin DSL : CI “as code”

TeamCity peut définir projets/build configs via Kotlin DSL, utile pour versionner la CI et reviewer les changements comme du code (PR, audit).

                    // Vue conceptuelle (pseudo)
                    project {
                    buildType("Backend_Tests") { steps { ... } triggers { ... } }
                    buildType("Docker_Build") { dependencies { ... } }
                    }
                

Exemple complet : Django + React + Docker

                            Steps:
                            - checkout
                            - python -m venv venv
                            - pip install -r requirements.txt
                            - ruff check .
                            - pytest -q --maxfail=1
                            Artifacts:
                            - junit.xml
                            - coverage.xml
                        

                            Steps:
                            - docker build -t registry/app:%build.number% .
                            - docker push registry/app:%build.number%
                            Artifacts:
                            - build-metadata.json
                            Dependencies:
                            - snapshot: Build Config A
                        

                            Trigger:
                            - on finish Build Config B (main branch)
                            Steps:
                            - deploy to DEV (auto)
                            - smoke tests
                            - manual approval STAGE
                            - manual approval PROD
                            Artifact dependency:
                            - pull registry/app:%dep.B.build.number%
                        

PR builds : “quality gate” avant merge

                    Pull Request opened
                    └─ Trigger CI "fast"
                    - lint
                    - unit tests
                    - quick build
                    └─ Report status to Git provider
                    - ✅ merge allowed
                    - ❌ merge blocked
                

Objectif : feedback en minutes, pas en heures.

Monorepo : ne pas builder tout le repo à chaque commit

• Détecter chemins modifiés → déclencher uniquement les builds concernés.
• Build matrices (services x versions) si besoin.
• Cache agressif (deps) + pipelines “fast/slow”.

Pools : isoler & scaler

Docker/K8s : pattern moderne

                    Option A: Agent VM + Docker
                    - stable, simple
                    - bon pour enterprise networks

                    Option B: Agents éphémères (auto-scale)
                    - agents up/down selon la queue
                    - attention à la gestion cache & secrets
                

Policies “pro”

• Exécuter les builds avec des comptes à privilèges minimaux.
• Durcir la chaîne supply chain (SBOM, scan images, dépendances).
• Tracer les artefacts (git_sha + build number + timestamp).

Build chains : snapshot vs artifact dependency

Déploiement : patterns (sans “opinion” unique)

                    Pattern 1: Deploy via SSH/Ansible
                    - pull artefact
                    - restart service
                    - smoke tests

                    Pattern 2: Deploy K8s (helm/kubectl)
                    - helm upgrade --install
                    - canary + rollback

                    Pattern 3: Deploy Cloud (ECS/EC2)
                    - update task definition / ASG
                    - blue/green
                

Rapports (qualité) : JUnit, coverage, scans

• JUnit : visibilité tests et erreurs récurrentes.
• Coverage : seuils (quality gate) et détection régressions.
• Security scans : dépendances, images Docker, SBOM.

Secrets : règles non négociables

                    ✅ Tokens VCS scopes minimaux
                    ✅ Secrets par env (DEV != PROD)
                    ✅ Masquage dans logs
                    ✅ Rotation/expiration
                    ❌ Jamais dans le repo
                

Supply chain (bonus “enterprise”)

• SBOM (ex: CycloneDX/SPDX) et scans dépendances.
• Scan images Docker (Trivy/Grype) avant registry/prod.
• Signer artefacts (si politique) + provenance.

Cache (gains x2 à x10)

                    Caches typiques:
                    - pip/wheels
                    - npm/yarn
                    - maven/gradle
                    - docker layer cache (selon stratégie)
                

Stratégie agents (pragmatique)

• Pool “fast CI” (petits agents) + pool “heavy builds” (gros agents).
• Conserver les images/outils cohérents (golden images).
• Agents éphémères si auto-scale (attention cache/secrets).

Quality gates (exemples)

Une ligne CV-ready

                    Mise en place de pipelines CI/CD TeamCity (templates, build chains, quality gates, artefacts immuables),
                    avec orchestration multi-agents (pools/requirements) et déploiements multi-environnements.
                

Auth VCS / status checks

• Token expiré / scopes insuffisants → renouveler + limiter droits.
• Branch specs trop restrictives → build non déclenché.
• PR builds : vérifier hooks / triggers + mapping repo.

Build “stuck” / timeouts / flaky

• Réduire dépendances réseau (mirrors + caches).
• Fixer versions outils/dépendances.
• Paralléliser, découper steps, réduire “heavy builds” sur PR.

Cache qui casse la reproductibilité

                    Symptômes:
                    - build OK hier, KO aujourd'hui sans changement
                    Actions:
                    - purge cache
                    - lockfiles stricts
                    - pin versions
                

Stratégie safe (entreprise)

1. Pilote sur un service non critique
2. Reproduire CI à l’identique (tests/outputs)
3. Factoriser via templates / DSL
4. Mettre en place artefacts immuables + promotion
5. Basculer triggers VCS progressivement

Pièges fréquents

• Builds non déterministes (versions non figées).
• Secrets dans scripts → refactor paramètres sécurisés.
• Monorepo : builds déclenchés “trop large”.
• Cache non maîtrisé → flaky builds.

Checklist