CodePipeline vs GitHub Actions : quand CodePipeline mérite sa place

Un fondateur a construit le MVP sur GitHub Actions parce que c’est ce qui était là. Le premier client payant est un acheteur de données de santé québécois qui demande où sont stockés les artéfacts de build, quel principal IAM peut les lire, et si le déploiement de production peut être initié par quiconque a un PAT GitHub. L’équipe est en train d’évaluer s’il faut migrer tout le CI/CD vers CodePipeline, tout garder en GH Actions, ou diviser les deux. La bonne réponse est rarement « tout l’un ». Voici la lecture honnête de là où chaque outil gagne, et la division qui tient pour la plupart des SaaS réglementés au Canada.

Ce qui se passe

GitHub Actions et CodePipeline résolvent des problèmes qui se chevauchent avec un centre de gravité différent :

• GitHub Actions est un outil CI/CD rapide et riche en écosystème, avec la source de vérité (le dépôt Git) intégrée étroitement. Les vérifications de PR, la protection de branche, les builds matriciels et le marché des actions communautaires vivent tous au même endroit que le code. Les runners d’exécution sont hébergés par GitHub par défaut (runners multi-locataires sur l’infrastructure Microsoft Azure), ou auto-hébergés dans votre propre compte.
• CodePipeline est un service d’orchestration AWS-natif. Le modèle d’exécution est « des étapes d’actions, chaque action est un service AWS (CodeBuild, CodeDeploy, Lambda, CloudFormation, approbation manuelle) ». IAM est la couche de contrôle d’accès. Les runners sont la compute CodeBuild, qui s’exécute dans votre compte.

Pour la plupart des décisions, la question n’est pas « lequel est meilleur » mais « quel axe compte le plus ». Cinq axes, et l’outil qui gagne sur chacun :

Le juste milieu qui fonctionne pour la plupart des équipes : GH Actions exécute le CI (lint, test, build de l’artéfact, push vers un registre de conteneurs). CodePipeline récupère l’artéfact via un événement ECR ou un événement S3, puis exécute les étapes de déploiement — multi-compte, blue/green, approbation manuelle, validation post-déploiement. Cette division prend la force de chaque outil : GH Actions reste proche du PR, CodePipeline reste proche d’AWS.

Comment vérifier

La question « où vit l’artéfact et qui peut y toucher » est la façon la plus concrète de comparer les deux outils.

GitHub Actions, configuration par défaut : le workflow s’exécute sur un runner hébergé par GitHub, construit l’artéfact, et le pousse quelque part. Pour pousser vers AWS (ECR, S3), le workflow a besoin d’authentifications AWS. Le pattern naïf est un AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY stockés comme secrets de dépôt. C’est une authentification de longue durée disponible pour quiconque peut exécuter un workflow sur le dépôt — chaque contributeur avec accès en écriture, chaque action dans le fichier de workflow. L’objection d’audit s’écrit d’elle-même.

Le bon pattern est la fédération OIDC : configurer le fournisseur OIDC GitHub Actions comme fournisseur d’identité IAM dans AWS, configurer un rôle avec une politique de confiance qui fait confiance au fournisseur OIDC restreint à des dépôts et branches spécifiques, et faire en sorte que le workflow assume le rôle au runtime avec aws-actions/configure-aws-credentials. La politique de confiance ressemble à :

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::111111111111:oidc-provider/token.actions.githubusercontent.com"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
    },
    "StringLike": {
      "token.actions.githubusercontent.com:sub": "repo:stackharbor/app:ref:refs/heads/main"
    }
  }
}

La condition sub restreint quelles exécutions de workflow peuvent assumer le rôle — repo:stackharbor/app:ref:refs/heads/main signifie seulement les exécutions sur main de stackharbor/app. C’est le pattern sécurisé GH-Actions. Fait correctement, il est compétitif avec CodePipeline sur l’axe des authentifications.

CodePipeline, configuration par défaut : le rôle de service du pipeline assume les rôles de déploiement dans les comptes cibles. Il n’y a aucune authentification de longue durée nulle part — le pipeline n’a jamais un secret dans son environnement, l’assomption multi-compte est le pattern d’accès. La chaîne de confiance IAM est en CloudFormation, sous contrôle de version, et révisable. C’est l’avantage « IAM-natif » : ce n’est pas que vous ne puissiez pas faire l’équivalent en GH Actions, c’est que CodePipeline vous force à le faire correctement parce qu’il n’y a pas de raccourci plus facile.

Résidence des données : les runners hébergés par GitHub s’exécutent sur l’infrastructure Azure en dehors du Canada par défaut. Pour une charge de données de santé québécoise sujette à la PIPEDA/Loi 25 et à des clauses contractuelles clients sur la résidence, c’est l’obstacle bloquant. Deux réponses :

• Runners GitHub auto-hébergés en EC2 ca-central-1 — possible, mais vous opérez maintenant les runners, y compris le patching, l’autoscaling, et la frontière de sécurité qui vient avec l’exécution de code de workflow arbitraire sur votre compte AWS.
• CodePipeline — l’exécution entière est dans votre compte AWS, dans la région que vous choisissez. Aucune préoccupation d’exfiltration, aucune opération de runner.

Pour les engagements de résidence québécoise, la question de résidence tire souvent les étapes de déploiement vers CodePipeline indépendamment d’où vit le CI.

La correction

Le pattern qui tient pour la plupart des SaaS réglementés :

1. GH Actions pour le CI. Lint, test, build, push vers ECR. Utilisez la fédération OIDC, pas des clés d’accès. Étiquetez l’image conteneur avec le SHA du commit. Le workflow se termine quand l’image est dans ECR, pas quand elle a été déployée.

2. CodePipeline déclenché par push ECR. Règle EventBridge sur l’événement PutImage d’ECR, ciblant le start-execution du pipeline. La première action du pipeline ramasse le tag d’image depuis le détail de l’événement. À partir d’ici, toutes les étapes de déploiement s’exécutent dans AWS — aucune implication GitHub, aucun runner externe.

3. Approbation manuelle dans CodePipeline, pas dans GH Actions. GH Actions a bien des environnements avec relecteurs requis, mais l’approbation vit dans l’interface GH et la piste d’audit est sur GitHub. Les approbations CodePipeline vivent dans le compte AWS, restreintes par IAM, audit-loggées via CloudTrail. Pour une charge réglementée, la piste d’audit côté AWS est ce que vous produisez pour la prochaine revue.

4. Déploiement via CodeDeploy depuis CodePipeline. Blue/green vers ECS ou EC2, avec AlarmConfiguration pour rollback automatique. La primitive blue/green dans CodeDeploy est difficile à répliquer dans GH Actions sans écrire beaucoup de colle — et la colle est ce qui casse pendant l’incident que vous essayiez d’éviter.

5. Source unique de vérité pour la config de déploiement. Que le pipeline soit défini en CloudFormation, CDK ou Terraform, il vit dans le dépôt de l’application. Le PR de définition de pipeline passe par la même revue que le code de l’application. Le pipeline est de l’infrastructure, pas une configuration ponctuelle.

Trois règles qui tiennent à travers la division CI/CD :

CodePipeline n’est pas GH Actions avec des étapes en plus. C’est un service d’orchestration avec une abstraction différente (étapes, actions, principaux de service IAM). Essayer de répliquer chaque workflow GH Actions comme une étape CodePipeline manque le point — le bon pipeline a 5 à 7 étapes, pas 30.

GH Actions n’est pas l’option économique pour les charges sérieuses. Le niveau gratuit couvre les dépôts publics et les petites charges privées. Pour un SaaS sérieux, les minutes de runner hébergé par GH s’additionnent, les opérations de runner auto-hébergé s’additionnent, et l’histoire de résidence peut l’exclure pour certains clients indépendamment. CodePipeline n’est pas gratuit non plus, mais la facturation est sur les minutes CodeBuild et le stockage S3 — des coûts qui montent en charge de manière prévisible avec la fréquence de déploiement.

La question de migration est rarement « tout ou rien ». La division (GH Actions pour le CI, CodePipeline pour le déploiement) est le mouvement qui capture la plupart du bénéfice de chaque outil. Une migration qui bascule tout vers CodePipeline à cause d’une conversation sur la résidence perdra la vitesse d’itération GH Actions à laquelle l’équipe est habituée. Une migration qui bascule tout vers GH Actions parce que « nous utilisons GitHub » perdra l’histoire de déploiement IAM-natif quand le prochain audit demande.

La bonne décision est celle qui correspond à la charge. Pour un projet open-source public : GH Actions pour tout. Pour un SaaS canadien réglementé : GH Actions pour le CI, CodePipeline pour le déploiement. Pour une équipe AWS-native sans empreinte GitHub en dehors de l’hébergement de source : CodePipeline de bout en bout. Les facteurs qui pilotent la décision sont la résidence, l’audit, l’ajustement à l’écosystème et la familiarité de l’équipe — dans cet ordre.

Stack Harbor bâtit et opère les workflows CodePipeline en production dans le cadre de l’onboarding Gestion AWS et de la couche Pipeline de déploiement en continu. Si votre chemin de release passe encore par SSH et un message Slack, commencez par une consultation d’infrastructure.