-
Notifications
You must be signed in to change notification settings - Fork 196
Feature branch CI/CD strategy #39
Comments
Option to look into : https://github.com/MHacker9404/cdk-pipeline-multi-branch |
Would also like this feature. In our current home-built CICD, we can deploy or undeploy any branch into staging. Bonus points (we do this): All our staging deployments share the same infrastructure (NATs, databases, ALB, etc.) i.e. anything that is a significant cost. |
@flochaz : not sure if this would be helpful, so please disregard if not. We've been using the CDK and self-mutating pipelines with a
The It was however very important for the artifacts. So developer environments, for example, can be pointed to any artifact (ECR and S3 bucket) using a "descriptor" file, but they mostly were automatically updated every time a new ECR image was pushed ( The downside to this is that we have to maintain several descriptor files in the infrastructure git repo (repo C) -- different for the Until now we had separated dev, staging and prod environments in 3 different AWS accounts and each tenant was isolated in their own slice of a VPC. Now, we're trying to migrate to one AWS account per tenant per environment (why we're looking into the Bootstrap Kit) ; so we're looking at things a little differently. It would be ideal if the self-mutating pipeline that dictates the infrastructure for each account could be descriptor-less. Coming back to the feature branch strategy, I think it would be interesting to have an organizational unit structured like this :
You can extend or "shrink" this to match your SDLC processes. But having a development environment that can :
Note : the structure depicted above didn't address "developer" environments, which could be included in an SDLC OU, as shown in the AWS Bootstrap Kit example, with 1 AWS account per developer
This also makes cost attribution a lot easier. |
Context
Current examples only show how to develop, integrate and deploy following a trunk base strategy with immutable infrastructure (main branch built once and promoted automatically to each stages).
Goal
Offer an alternative approach based on gitflow / feature branching strategy.
The text was updated successfully, but these errors were encountered: