Outils & Workflow Back-End

3 modèles de branches

• GitFlow : develop, branches release, hotfix — adapté aux releases rares.
• Trunk-based : tout part et revient sur main ; feature flags obligatoires.
• “GitHub flow” : branche → PR → merge → deploy, très courant en SaaS.

Conventional Commits

• feat : nouvelle fonctionnalité (impacte la version MINOR).
• fix : correction de bug (impacte la version PATCH).
• chore, refactor, docs, test, etc.
• Permet de générer changelog & versions automatiquement.

feat(api): add filters on /orders
                            fix(db): correct index on invoices
                            chore(ci): cache pip dependencies in GitHub Actions

Qualité de code “outillée”

• Formatteurs auto (Black, Prettier, gofmt…) → moins de débats sur le style.
• Linters (flake8, ESLint, golangci-lint…) branchés en CI.
• Analyse statique : mypy, SonarQube, Pylint, etc.

Stages typiques

• Check : lint, format, analyse statique.
• Test : unitaires + intégration, coverage.
• Build : image Docker, artefacts (wheel, jar, binaire).
• Deploy : staging puis prod (manuelle ou auto).

Matrice & parallélisme

• Tester sur plusieurs versions de langage / DB.
• Lancer les jobs en parallèle pour réduire le temps total.

strategy:
                            matrix:
                            python-version: ["3.10", "3.11", "3.12"]

Releases contrôlées

• Tag + changelog généré automatiquement depuis les commits.
• Promotion staging → prod via “deploy buttons” + approbation.
• Rollbacks scriptés : revenir à l’image N-1 + migrations down.

Stack dev local

• Un simple make dev pour lancer API + DB + Redis + outils.
• Scripts pour importer un dump anonymisé, créer un admin, etc.
• Éviter la “doc orale” : tout dans le README / docs dev.

Configs par env

• .env.dev, .env.staging, .env.prod ignorés par Git.
• Valeurs par défaut raisonnables pour l’onboarding d’un nouveau dev.

Parité dev/prod

• Mêmes versions majeures de DB, même runtime (Python, Node…).
• Limitation des “ça marche chez moi” grâce à Docker/Compose.

Structurer le repo

• Répertoires clairs : src/ ou app/, tests/, infra/, scripts/, docs/.
• Fichier README.md qui explique comment lancer, tester, déployer.
• Pour un monorepo : dossiers par service + scripts communs.

Historique utile

• Commits atomiques, pas des “big-bang refactor + features + tests”.
• Utiliser git bisect quand un bug est introduit pour trouver le commit fautif.
• Tags de versions cohérentes (semver).

Rebase vs merge

• Merge : garde l’historique exact, mais peut être très verbeux.
• Rebase : historique linéaire, plus lisible → à utiliser avant PR.
• Règle classique : rebase libre sur branches perso, jamais sur main partagé.

Workflow d’une feature

1. Créer branche feature/1234-checkout-coupons depuis main.
2. Code + tests, rebase régulièrement sur main.
3. Ouvrir PR en “draft” tôt pour feedback.
4. CI verte, review, corrections, squash & merge.

Template de PR minimal

## Objet
                            - Ajouter la pagination sur /orders

                            ## Changements
                            - nouveau paramètre `page` et `page_size`
                            - mise à jour de l'OpenAPI
                            - nouveaux tests

                            ## Impacts
                            - DB : aucun
                            - Perf : +1 requête sur les totaux

                            ## Checklist
                            - [x] tests unitaires
                            - [x] tests intégration
                            - [x] docs OpenAPI

Gestion des versions

• pyenv, asdf ou équivalent pour gérer plusieurs versions de Python/Node.
• Fichier .python-version ou .tool-versions committé.

Virtualenv & requirements

• Un env par projet (python -m venv .venv).
• Fichier lock (poetry.lock, requirements.txt) versionné.
• Scripts pour régénérer l’env : make venv.

Secrets & config en dev

• Variables d’environnement via .env (non committé).
• Secrets fictifs ou comptes de test, jamais les secrets prod.

Multi-stage build (image légère)

FROM python:3.12-slim AS base

                            FROM base AS build
                            WORKDIR /app
                            COPY pyproject.toml poetry.lock ./
                            RUN pip install poetry && poetry install --no-dev

                            FROM base AS runtime
                            WORKDIR /app
                            COPY --from=build /usr/local /usr/local
                            COPY . .
                            USER 1000
                            CMD ["gunicorn", "app.wsgi:application", "-b", "0.0.0.0:8000"]

docker-compose pour dev complet

services:
                            api:
                            build: .
                            env_file: .env.dev
                            ports: ["8000:8000"]
                            depends_on: [db, redis]
                            db:
                            image: postgres:16
                            environment:
                            POSTGRES_PASSWORD: dev
                            volumes:
                            - dbdata:/var/lib/postgresql/data
                            redis:
                            image: redis:7
                            volumes:
                            dbdata:

Pipeline complet

• Push sur branche → build & tests.
• Merge sur main → build image + push registry.
• Tag release → déploiement staging / prod.

Migrations DB dans la CI/CD

• Commandes dédiées : migrate, check, rollback.
• Test des migrations sur env éphémère dans le pipeline.
• Documenter les migrations destructives (DROP, TRUNCATE…).

Artefacts & registry

• Images Docker versionnées dans un registry (ECR, GHCR…).
• Artefacts de build (packages, binaires) dans un store central.
• Permet de reproduire exactement un déploiement N-1.

Pyramide de tests

• Beaucoup d’unitaires, moins d’intégration, peu d’e2e, quelques tests de perf.
• Les tests lents doivent être limités mais fiables.

Organisation du dossier tests/

• tests/unit/ pour la logique pure.
• tests/integration/ pour API, DB, queues…
• tests/e2e/ pour les parcours complets.

Mocks & doubles de test

• Mocker les appels externes (APIs tierces, e-mails…).
• Utiliser des fixtures réutilisables (Pytest).

Tickets & flux

• Un ticket = un problème / feature, pas un fourre-tout.
• Critères d’acceptation clairs (Given / When / Then).
• Limiter le WIP pour éviter l’éparpillement.

Documentation “vivante”

• OpenAPI pour les contrats d’API (généré par le code si possible).
• ADR (Architecture Decision Records) pour les grosses décisions.
• Docs proches du code plutôt que ppt dispersés.

Collaboration

• Pair/mob programming pour les sujets complexes ou sensibles.
• Canaux Slack/Teams par domaine (api-payments, infra, data…).
• Rétros régulières pour ajuster tooling & process.

Organisation perso

• Bloc “deep work” quotidien sans Slack/mail (code, design).
• Regrouper les revues de code, les réunions, la comm.
• Limiter le multi-task & garder peu de tâches ouvertes.

Automatisation & dotfiles

• Alias shell, fonctions, scripts de bootstrap de nouvelle machine.
• Config d’éditeur versionnée (VSCode, vim, etc.).

Feedback loop

• Mesurer les irritants : builds lents, tests flakys, onboarding compliqué.
• Proposer des améliorations concrètes : cache CI, tests refactorés, scripts.