Continuous frustration or Continous Delivery — CI/CD and Agile development (AWS Codepipline)
Time-to-market is the key item for organizations to be able to compete in the market. Companies need to launch features and services faster than other companies to survive and thrive. Software features need to be released in the shortest possible delivery time.
Companies are adopting agile and DevOps to build products and services faster. They hire agile coaches to drive the change, but lot of organizations fail to achieve the required velocity. Ever thought of WHY?
Let us understand agile. In simplest terms, agile is a way of working by which we can deliver value to our customers quickly.
Traditional building and release process is similar to firing an ancient cannon.
If your build and release is still using ancient cannons to build and deploy your code then you call the process as ‘Continuous frustration’.It is the absence of any continuous integration or continuous delivery practices.
The cannons firing process is described below.
Cannons are used in ancient times as primary artillery weaponry.
Each cannon would be manned by two gunners, six soldiers, and four officers of the artillery (release team). The right gunner was to prime the piece and load it with powder (Code merger and load), while the left gunner would fetch the powder from the magazine (Environment teams) and keep ready to fire the cannon at the officer’s command (Release manager). Three soldiers stood on each side of the cannon, to ram and sponge the cannon, and hold the ladle (Build support).
Initially, our build process was similar to the above, though we don't have a dedicated army (release team). Developers were only building the code once a week.
We realized we need to transform our process. Due to delay in build and release we are unable to ‘inspect and adapt’, the key essence of agile.
We need a state of the art weaponry, which is automated and event-driven. Something like the one below.
We build a continuous delivery pipeline, which means getting feedback on every commit. Our AWS Code build servers (serverless) listen to git commits to the master branch and trigger a build when change is pushed on to the master branch.
This helped us to avoid merger and build issues. The easier way to avoid bug fixes complicated is by avoiding bugs to be piling up. Earlier detection help us to resolve the issue quickly as changes are fresh in developers mind.
We keep master branches always fresh by the use of feature flags. This means at every commit our code is ready to be deployed to production.
We use the AWS Codepipeline to build and deploy our code.
Create a new pipeline.
Select the code source. We access code checked-in our GitHub.
Once you select the option as Github, you need to provide access to Github.
We also defined our build provider. We used AWS CodeBuild for the process.
And finally deployed the code to S3 bucket.
Automation helped us increase our productivity by more than 30–35%. If you are facing a similar situation in your organization and need guidance then feel free to reach out via comment.
