Le déploiement de la plateforme repose sur AWS CodePipeline avec GitHub comme source. Chaque push sur la branche de déploiement déclenche un pipeline en trois étapes : récupération du code, build via CodeBuild, puis déploiement sur AWS Elastic Beanstalk avec retour arrière automatique en cas d'échec. Les tests, eux, tournent en continu dans GitHub Actions. Voici comment c'est structuré et pourquoi on a réparti les rôles ainsi.
CodePipeline pour déployer, GitHub Actions pour tester
GitHub Actions est idéal pour tout ce qui vit autour du code : tests, analyse de qualité, mises à jour de dépendances. Pour le déploiement sur AWS, CodePipeline offre des avantages concrets :
- Rôles IAM natifs : chaque étape du pipeline s'exécute avec un rôle IAM dédié. Les credentials AWS restent dans AWS, et chaque accès est scopé au strict nécessaire.
- Intégration native avec Elastic Beanstalk : l'action de déploiement est un plugin natif, avec suivi de santé et retour arrière intégrés.
- Traçabilité : chaque exécution, chaque artefact et chaque version déployée sont historisés côté AWS.
La connexion GitHub : CodeStar Connections
La connexion entre GitHub et CodePipeline passe par AWS CodeStar Connections, qui installe une GitHub App sur le dépôt. C'est le mécanisme recommandé aujourd'hui, l'ancienne méthode OAuth avec token personnel étant dépréciée.
La GitHub App reçoit uniquement les permissions nécessaires : lecture du code source et réception des webhooks. Côté AWS, la connexion est une ressource qui peut être partagée entre plusieurs pipelines avec une seule autorisation GitHub.
Structure du pipeline
Le pipeline (CodePipeline V2) comporte trois étapes :
1. Source
Un push sur la branche suivie déclenche le pipeline via webhook. CodePipeline récupère le code source depuis GitHub et le stocke comme artefact dans un bucket S3 chiffré, accessible aux rôles IAM du pipeline.
2. Build (CodeBuild)
CodeBuild exécute les instructions du fichier buildspec.yml à la racine du dépôt : installation des dépendances PHP avec composer install, puis assemblage de l'archive applicative qui sera déployée. Si le build échoue, le pipeline s'arrête là et la version en production continue de tourner.
3. Deploy (Elastic Beanstalk)
CodePipeline transmet l'archive à Elastic Beanstalk, qui la déploie sur les instances EC2 de l'environnement, derrière un Application Load Balancer. Les health checks du load balancer valident que la nouvelle version répond correctement. En cas d'échec, Elastic Beanstalk revient automatiquement à la version précédente.
Les tests : GitHub Actions, SonarCloud, Dependabot
La qualité est vérifiée en amont du pipeline, directement sur le dépôt :
- Plus de 3 000 tests PHPUnit et des scénarios de bout en bout Cypress tournent dans GitHub Actions.
- SonarCloud analyse chaque branche et applique sa quality gate.
- Dependabot surveille les dépendances et propose les mises à jour de sécurité.
Chaque outil garde son rôle : GitHub vérifie le code, AWS le livre.
Gestion des secrets
Les secrets restent dans AWS. La configuration de chaque environnement client vit dans AWS Secrets Manager, avec un secret dédié par client : identifiants de base de données, clés des services tiers, paramètres de l'application. L'application les lit au démarrage grâce au rôle IAM de son environnement, qui donne accès au secret de ce client et à lui seul.
Rôles IAM : un rôle par étape
CodePipeline utilise plusieurs rôles IAM distincts :
- Rôle CodePipeline : lit et écrit dans le bucket d'artefacts, déclenche CodeBuild, lance le déploiement Elastic Beanstalk.
- Rôle CodeBuild : lit le bucket d'artefacts, écrit les logs dans CloudWatch, produit l'archive de déploiement.
- Rôles Elastic Beanstalk : le rôle de service pilote le déploiement et le retour arrière ; le rôle des instances donne à l'application l'accès à son propre secret.
Ce découpage cantonne chaque étape à son périmètre : une compromission d'une étape reste confinée à ses propres droits.