Bitbucket

Bitbucket (et Pipelines) quand le dépôt ou la politique SI est déjà chez Atlassian. On ne force pas une migration GitHub « pour le principe » : on branche la même exigence de CI verte là où vit déjà le code.

Beaucoup de PME/ETI ont déjà Bitbucket. L’important, ce n’est pas l’éditeur : c’est tests, analyse statique et déploiement reproductible sur chaque merge.

Bitbucket est la forge Git d’Atlassian. Avec Bitbucket Pipelines, on y branche la CI/CD : tests, builds, déploiements — versionnés avec le dépôt.

Chez Innovation Digitale, Bitbucket n’est pas un dogme. C’est une option pragmatique quand le client y est déjà, ou quand le SI impose l’écosystème Atlassian. La même méthode s’applique que sur GitHub : pipeline vert avant livrer, doc courte, code transmis.

On choisit Bitbucket quand l’existant le commande : équipes formées, droits déjà en place, conformité, ou couple naturel avec Jira. On choisit GitHub Actions quand le dépôt est sur GitHub ou qu’on part de zéro sans contrainte éditeur.

Dans les deux cas, le critère reste le même : chaque merge doit pouvoir partir — ou être bloqué si rouge. PHPUnit, PHPStan, Playwright, Gherkin : la forge suit ; la qualité ne se négocie pas.

Bon choix si Bitbucket (ou Data Center) est déjà le standard interne, ou si Jira / Confluence structurent déjà le delivery. On s’aligne, on documente les pipelines, on évite une double forge inutile.

On passe si le projet est déjà sur GitHub avec une CI propre, ou si le client veut simplifier vers une seule forge. On ne multiplie pas les outils pour empiler des logos.

Vous gardez votre forge si elle tient la route. Nous branchons la méthode iD dessus : critères exécutables, CI, passage de consignes. Le Brief 45 min sert à voir si on reste sur Bitbucket ou si un autre setup réduit le risque.