CODEWITHSUNDEEP
continuous-integrationcontinuous-deploymentaws-codepipelineaws-codebuildcontinuous-delivery
systemdebt
systemdebt

Reputation: 4941

Best way forward to improvise our CI-CD that uses code pipeline and codebuild

We are using codepipeline and codebuild with bitbucket cloud for source repositories.

We won't be releasing frequently and our releases are heavily regulated (Reviews by customers in a staging environment first) before releases etc.

We have separate branches for develop, staging, and production environment as the code pipeline doesn't support tag-based releases and feature branches will be frequently merged to the develop branch. The develop branch will be infrequently merged to staging the staging will be merged to master.

We also have a code pipeline per branch that gets triggered when there are updates in those branches.

We currently create pull requests manually from develop to staging and staging to master to trigger the respective pipelines.

  1. I would like to understand how should the current set up be modified (minimally) to make it a true CI-CD but without a complete overhaul of the CI-CD pipeline.

  2. How should I be making sure that the staging/production pipeline should not go through unless the develop pipeline had been triggered for the same code ( I was thinking of updating the list of versions in SSM when develop pipeline deploys so that if the version in staging/master is not found in SSM, the pipeline won't go through. Is there a better way of doing it? should I be doing this or taking a different approach?

P.S: Feature flags don't sound like a good option because we will end up with a lot of code with just feature flags since infrequent deployments. Yes, I know how trunk-based branching is what everyone keeps talking about but I don't see how is it sitting well for us with code pipeline (No tag-based triggers) and infrequent deployments to staging/prod?

Upvotes: 1

Views: 489

Answers (1)

Ronan Cunningham
Ronan Cunningham

Reputation: 404

It seems to me that your build and deployment process accurately reflects your release process.

I'm assuming in your company something like the following applies:

  • You need the production branch for hot-fixes to production. These changes need merged back to staging.
  • Upcoming releases (prod +1) sit in staging for a long time. You continue to make changes on the staging branch that need merged back to development and forward to the production branch.
  • Future releases (prod +2) are done on the development branch and this code needs merged to the staging branch when ready.
  • You spend a lot of time managing code merges (and likely firefighting the problems caused by code regressions)

The C in CI\CD stands for 'Continuous'. CI/CD is designed to accelerate frequent releases to production yet you explicitly say you release infrequently.

Your questions:

  1. Closer to true CI would be to use trunk based development with short lived feature branches. Your pipeline would build a single deployment artefact and deploy this same artefact through develop, staging and production. Feature flags or equivalent would be used to keep your code always release-able - there are no tag based triggers needed as every commit is potentially release-able.

You have indicated you understand this to some extent but don't feel it applies to your operating environment.

  1. If you must have different pipelines running off different branches for different environments, to me this is a question of your code management process and not for code-pipeline. You should mainly handle this at source, which is in your code management tools and processes.

Your question 2 indicates to me you are not confident in this process internally at your company and are looking inside AWS to fix problems outside of AWS.

This is all a reflection of the unfortunate reality of having long lived branches for different environments.

This is exactly the scenario that that CI was developed as an antidote to but you are discounting two of the main techniques needed for the benefits of CI/CD ( Trunk based development and feature flags) and your release cycle does not support one of the main benefits, i.e frequent releases to production.

Every organisation has their own constraints and particular trade-offs and I of course don't have the full picture. In my opinion the underlying issues in your question are a direct result of how you release and manage your code and you can't expect the benefits of CI/CD without the practices, which does mean a fundamental overhaul of how you work.

Upvotes: 1

Related Questions