Home > Enterprise >  CDK pipelines branching strategy
CDK pipelines branching strategy

Time:11-03

CDK pipelines seems to only work, by default, with one branch. Am I missing something or do you know if is there a way to

  • have a dev branch to deploy to the Dev account/ env
  • test branch deploy to Test account/env.
  • jons-cool-feature-branch to X account/env etc

Ideally we do not want to have to push everything to the master branch to deploy to dev / test, so that we can keep the master branch clean, tidy, and stable.

I have thought about having multiple pipelines, one for dev, one for test, and one for master, this would solve the issue, but doesn’t feel like the cleanest solution.

Are there any recommended patterns?

CodePudding user response:

The AWS-prescribed best practice is to use trunk-based development.

Thus, a single pipeline cannot use multiple branches for deploying to different environments cleanly.

You should look into creating a single pipeline that would in turn create environment-specific pipelines.

Here is a relevant issue in the CDK repo: https://github.com/aws/aws-cdk/issues/9461

CodePudding user response:

Codepipeline cannot branch. It is not designed to do so.

A solution is to have a multi stage pipeline that has manual approval steps in the middle if you absolutely must have multiple environments and a single pipeline.

That is

Source (Dev branch) -> Build/Deploy -> Manual Approval step -> Make use of of a Codebuild or a lambda to move your now tested code (still in the artifact chain) to your test branch for you (ie make use of a git server api to initiate the merge based on the commit message from the initial commit that started the chain -> Another Build./Deploy to your test env (can even do cross account deployment here) -> Manual Approval step -> Repeat as many times as you want until you deploy to Production.

However.... this is entirely a hack. You're better off with multiple pipelines. I would use the CDK to be able to dynamically adjust the cloudformation template for the pipeline itself to handle Dev/Prod and then simply deploy it twice, linking one to the source of Dev and one to the source of Main.

  • Related