Un client réglementé pose la question que son auditeur va poser : « où vit le code source, et qui peut le lire ? » La réponse de CodeCommit était propre — à l’intérieur du compte AWS du client, contrôlé par IAM, audité par CloudTrail. Avec CodeCommit fermé aux nouveaux clients et doucement sur le chemin de dépréciation, cette réponse propre n’existe plus. Les remplacements prennent quatre formes : Gitea auto-hébergé sur EC2 ou ECS, Bitbucket Data Center dans un VPC, GitHub Enterprise Server (aussi dans un VPC) ou GitHub.com avec OIDC et une lecture soignée d’où vit réellement le périmètre d’audit. Chacun a une histoire de résidence différente, un coût opérationnel différent et une expérience développeur différente. La bonne réponse dépend des compromis que le contrat permet.
Ce qui se passe
La valeur de conception de CodeCommit était un plan de contrôle et un plan de données qui vivaient tous deux à l’intérieur du compte AWS du client. Le paysage post-CodeCommit sépare les deux : soit vous gardez les données à l’intérieur d’un compte AWS en auto-hébergeant un serveur Git, soit vous acceptez que le locataire source-de-vérité se déplace vers un fournisseur SaaS et utilisez OIDC / audit soigneux pour maintenir le contrôle sans posséder le plan de données.
Gitea sur EC2 ou ECS. Gitea est open-source, petit binaire Go, tourne sur une seule instance EC2 avec un backend PostgreSQL RDS ou dans un conteneur sur ECS Fargate. Le plan de données entier est à l’intérieur de votre VPC. Le compromis est l’expérience développeur — la revue PR de Gitea est compétente mais pas équivalente à GitHub (pas de file de fusion, pas de CODEOWNERS à la profondeur de GitHub, pas de Copilot, pas de Marketplace d’Actions). Pour une petite équipe qui valorise la résidence par-dessus la finition, c’est le remplacement CodeCommit le plus proche.
Bitbucket Data Center. L’offre auto-hébergée d’Atlassian, déployée sur une grappe EC2 ou EKS avec un backend PostgreSQL RDS. La revue PR est plus proche du niveau GitHub (Atlassian a investi dans l’outillage de revue de code depuis des années). Elle s’intègre avec Bamboo, Jenkins, et de plus en plus avec les runners Pipelines natifs. Le compromis est le coût de licence (par-utilisateur, payé d’avance — modèle de tarification seulement, pas un chiffre à publier), la complexité opérationnelle (clustering, sidecar Elasticsearch, maintenance planifiée) et un écosystème de plugins tiers plus petit que celui de GitHub.
GitHub Enterprise Server (GHES). L’appliance auto-hébergée de GitHub, déployée comme image VM sur EC2 (ou AMI AWS Marketplace). Jeu de fonctionnalités GitHub complet — Actions, Packages, l’expérience de revue PR — mais dans une VM que vous contrôlez. Le compromis est l’empreinte opérationnelle : GHES est une appliance substantielle, avec sa propre cadence de mise à jour, ses propres caractéristiques de performance (elle a besoin d’IOPS réels) et un modèle de licence par-utilisateur avec un minimum non-trivial. Pour les organisations qui veulent l’UX de GitHub sans la tenance SaaS, c’est la réponse ; pour les petites équipes, c’est démesuré.
GitHub.com avec OIDC. La réponse pragmatique pour la plupart des équipes : accepter que le code source vit dans le locataire de GitHub, auditer l’accès via l’API de journal d’audit de GitHub exportée vers votre S3 / CloudTrail Lake, et utiliser OIDC pour l’auth Actions-vers-AWS pour qu’aucune lettre de créance AWS longue durée n’existe en dehors d’AWS. Le plan de données (le contenu du dépôt) est dans GitHub. Le plan de contrôle (qui peut lire, qui peut pousser, quelles branches sont protégées) est l’interface admin enterprise de GitHub, mirrorée dans votre SIEM via le flux de journal d’audit. Le compromis est que votre contrat avec GitHub fait partie de l’histoire de résidence — et pour les clients avec contraintes dures de localisation de données (les données canadiennes doivent rester au Canada), les régions principales de GitHub.com ne sont pas canadiennes.
Le « motif Actions qui remplace les déclencheurs CodePipeline » est la colle de migration à travers les quatre. CodePipeline se déclenche sur un événement de push CodeCommit par sondage ou via CloudWatch Events. Post-migration, l’équivalent est un workflow GitHub Actions qui utilise aws-actions/configure-aws-credentials avec OIDC, assume un rôle IAM dans le compte AWS cible, et soit pilote un déploiement directement (CDK, Terraform, aws s3 sync) soit donne un coup de pied à l’existant CodePipeline en appelant codepipeline:StartPipelineExecution. Le second motif préserve votre investissement existant en CodePipeline — vous remplacez juste la surface de déclencheur, pas le pipeline.
Comment vérifier
Pour chaque option de remplacement, trois vérifications déterminent la faisabilité sur une charge spécifique.
# 1. Résidence des données : dans quelle région la source doit-elle vivre ?
# Vérifiez le contrat du client et tout DPA actif.
# CodeCommit était dans us-east-1 / ca-central-1 ; si le contrat exige ca-central-1,
# les options SaaS sont contraintes :
# - GitHub.com : principal aux US ; module additionnel de résidence peut épingler à l'UE ; pas de région canadienne
# - Auto-hébergé dans ca-central-1 : Gitea/Bitbucket DC/GHES tous fonctionnent
# 2. Empreinte CodePipeline : combien de pipelines doivent être re-câblés ?
aws codepipeline list-pipelines --query 'pipelines[].name' --output text | \
while read p; do
aws codepipeline get-pipeline --name "$p" \
--query 'pipeline.stages[?actions[?actionTypeId.provider==`CodeCommit`]].name' \
--output text
done | grep -v '^$' | wc -lUn compte élevé signifie que la migration inclut le re-câblage de N pipelines ; ce coût est le même peu importe où vous atterrissez en serveur Git, donc il n’influence pas le choix. Le choix est piloté par la résidence et l’expérience développeur.
# 3. Attentes développeur : quelles fonctionnalités sont non-négociables ?
# Questions de sondage à poser à l'équipe :
# - Copilot est-il déjà dans les attentes IDE ? (Oui → GHES ou GitHub.com)
# - Les PR ont-elles besoin de file de fusion ? (Oui → GHES ou GitHub.com)
# - L'équipe est-elle prête à opérer une appliance auto-hébergée ? (Non → GitHub.com)
# - Les auditeurs exigent-ils le plan de données à l'intérieur du locataire client ? (Oui → auto-hébergé)Le sondage est non-quantitatif mais les réponses déterminent l’option. Le sauter mène à choisir sur la préférence d’infrastructure et à découvrir six mois plus tard que l’équipe est malheureuse.
La correction
Le flux décisionnel :
-
Établir le plancher de résidence. Si le contrat ou le régulateur exige la résidence des données canadienne au niveau du code source, l’option GitHub.com est dehors — et les modules additionnels de résidence pour Enterprise Cloud sont UE seulement à l’écriture, pas canadiens. Le choix se réduit à auto-hébergé dans
ca-central-1: Gitea, Bitbucket DC ou GHES. Si la résidence est flexible (la plupart du SaaS non-réglementé l’est), les quatre options sont disponibles. -
Faire correspondre la surface d’attente développeur. Une équipe qui vit dans GitHub.com pour le travail open-source sera malheureuse sur Gitea. Une équipe qui n’utilise pas Copilot, n’écrit pas d’Actions et traite le serveur Git comme un endroit pour pousser du code sera bien sur Gitea. Bitbucket DC est le bon choix quand l’équipe est déjà profonde dans Atlassian (Jira, Confluence) — l’intégration inter-produit est la valeur, pas l’UX Git.
-
Choisir l’adéquation opérationnelle. Chaque option auto-hébergée a un profil ops différent :
- Gitea : la plus légère. Binaire unique, PostgreSQL unique. Les mises à jour sont un échange de binaire. SSO via OAuth/OIDC. Bon ajustement pour une petite équipe ops. La capacité pour des centaines de devs est atteignable sur une seule instance EC2 bien dimensionnée plus RDS.
- Bitbucket DC : clusterisée (la HA réclame au moins deux nœuds plus un partage de fichiers partagé pour le stockage de dépôts — typiquement EFS), sidecar Elasticsearch, mises à jour de version majeure planifiées. Les motifs de déploiement publiés d’Atlassian sont matures. Vraie discipline opérationnelle requise.
- GHES : appliance avec son propre cycle de mise à jour (mineur mensuel, patch trimestriel). Les sauvegardes sont natives GitHub (
ghe-backupbasé ssh), restauration testée en DR. Les IOPS disque comptent — un disque sous-dimensionné est la panne GHES la plus courante. L’appliance est opinionnée ; vous ne la réglez pas comme vous réglez Gitea.
-
Câbler le motif Actions-remplaçant-déclencheurs-CodePipeline. À travers toutes les options, le motif est le même :
# .github/workflows/deploy.yml (ou .gitea/workflows/deploy.yml, etc.)
name: deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
permissions:
id-token: write # requis pour OIDC
contents: read
steps:
- uses: actions/checkout@v4
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/GitHubActions-Deploy
aws-region: ca-central-1
- name: Déclencher le CodePipeline existant
run: |
aws codepipeline start-pipeline-execution \
--name production-deployLa politique de confiance du rôle IAM permet sts:AssumeRoleWithWebIdentity depuis le fournisseur OIDC GitHub, étendue au dépôt et à la branche spécifiques. Aucune clé AWS longue durée n’atterrit dans GitHub Secrets. Le CodePipeline existant reste — sa source de déclenchement s’est déplacée de CodeCommit à « manuel via GitHub Actions ».
-
Garder le périmètre d’audit explicite. Pour GitHub.com / GHES, configurez le point de terminaison de diffusion de journal d’audit pour livrer dans S3 (et de là dans CloudTrail Lake ou votre SIEM). Pour Bitbucket DC, le journal d’audit est dans PostgreSQL — expédiez-le via Logstash ou Fluent Bit. Pour Gitea, idem — les événements d’audit Gitea vont dans son fichier de log, expédiez-les. L’équivalent CodeCommit (événements CloudTrail sur les actions
codecommit:*) a besoin d’un remplacement explicite, pas d’une supposition que les défauts de la nouvelle plateforme le couvrent. -
Planifier le runbook de migration pour chaque dépôt. La migration mécanique est la même à travers les destinations — les étapes de mirror-push et validation ne changent pas. Seuls l’URL de destination et les détails de remplacement de déclencheurs diffèrent.
Deux règles que nous tenons :
Ne pas choisir sur le coût seul. La différence de coût entre GitHub.com Enterprise Cloud et une grappe GHES auto-hébergée est significative, mais le coût opérationnel d’une appliance auto-hébergée pour une petite équipe efface habituellement cet écart. La bonne comparaison est le coût total de possession sur deux ans, pas le prix de catalogue.
Ne pas confondre « auto-hébergé » avec « plus sécurisé ». Une instance GitHub.com Enterprise bien configurée avec diffusion de journal d’audit, SSO SAML et OIDC-vers-AWS est dans bien des cas mieux sécurisée qu’une appliance auto-hébergée opérée par une petite équipe ops qui rate un cycle de correctifs. La question de résidence est réelle ; la question de sécurité est surtout la discipline opérationnelle appliquée, pas la forme de déploiement.
Le paysage Git-sur-AWS post-CodeCommit est sain — chaque option fonctionne, les compromis sont réels et les motifs de migration sont bien éprouvés. La décision est de posséder le compromis, pas de trouver un remplacement parfait. Il n’y en a pas.
Stack Harbor opère CodePipeline + CodeCommit (et les variantes GitHub sur AWS) dans le cadre de l’onboarding Gestion AWS et des Environnements infogérés en continu. Si vous dimensionnez un remplacement Git-sur-AWS contre une vraie contrainte de résidence, commencez par une consultation d’infrastructure.