Build and Release

As mention in previous post DevOps is a philosophy. Its a practice. DevOps philosophy talks about automation. In this post I will talk about Continuous Integration ,Continuous Delivery, Continuous deployment.

Continuous Integration (CI):

Is the practice used by development teams to automate the merging and testing of code. Implementing CI helps to catch bugs early in the development cycle, which makes them less expensive to fix. Automated tests execute as part of the CI process to ensure quality. Artifacts are produced from CI systems and fed to release pipelines to drive frequent deployments.

Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch.

Continuous Delivery (CD):

Is a process by which code is built, tested, and deployed to one or more test and production environments. Deploying and testing in multiple environments drives quality. CI systems produce the deployable artifacts including infrastructure and apps. Automated release pipelines consume these artifacts to release new versions and fixes to existing systems. Monitoring and alerting systems run continually to drive visibility into the entire CD process.

Continuous delivery, help to decide the release frequency (daily, weekly, fortnightly, or whatever suits your business requirements). However, if you truly want to get the benefits agility using continuous delivery, we should deploy to production as early as possible to make sure that we release small batches, that are easy to troubleshoot in case of a problem.

Continuous deployment:

Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There’s no human intervention, and only a failed test will prevent a new change to be deployed to production.

Continuous deployment is an excellent way to accelerate the feedback loop with your customers and take pressure off the team as there isn’t a Release Day anymore. Developers can focus on building software, and they see their work go live minutes after they’ve finished working on it.

Cost v/s Gain:

Continuous Integration

  • Your team will need to write automated tests for each new feature, improvement or bug fix. Less bugs get shipped to production as regressions are captured early by the automated tests.

  • You need a continuous integration server that can monitor the main repository and run the tests automatically for every new commits pushed. Building the release is easy as all integration issues have been solved early.

  • Developers need to merge their changes as often as possible, at least once a day. Less context switching as developers are alerted as soon as they break the build and can work on fixing it before they move to another task.

  • Testing costs are reduced drastically – your CI server can run hundreds of tests in the matter of seconds.

  • Your QA team spend less time testing and can focus on significant improvements to the quality culture.

Continuous delivery

  • You need a strong foundation in continuous integration and your test suite needs to cover enough of your codebase. The complexity of deploying software has been taken away. Your team doesn’t have to spend days preparing for a release anymore.

  • Deployments need to be automated. The trigger is still manual but once a deployment is started there shouldn’t be a need for human intervention. You can release more often, thus accelerating the feedback loop with your customers.

  • Your team will most likely need to embrace feature flags so that incomplete features do not affect customers in production. There is much less pressure on decisions for small changes, hence encouraging iterating faster.

Continuous deployment

  • Your testing culture needs to be at its best. The quality of your test suite will determine the quality of your releases.

  • Your documentation process will need to keep up with the pace of deployments.

  • Feature flags become an inherent part of the process of releasing significant changes to make sure you can coordinate with other departments (Support, Marketing, PR…).

  • You can develop faster as there’s no need to pause development for releases. Deployments pipelines are triggered automatically for every change.

  • Releases are less risky and easier to fix in case of problem as you deploy small batches of changes.

  • Customers see a continuous stream of improvements, and quality increases every day, instead of every month, quarter or year.

Related Posts

About Ajeet Chouksey

With a robust background spanning more than 18 years, I am an adept Azure and Azure DevOps architect and engineer, dedicated to crafting Azure-centric solutions that prioritize customer requirements and agile methodologies. My expertise encompasses steering extensive cloud migration initiatives and advocating for Azure best practices, all aimed at streamlining costs and steering multinational teams towards success. Fueled by a passion for technological innovation, I am committed to perpetual learning, constantly advancing my proficiency in Azure, AI, MLOps, and Product Management to stay at the forefront of the industry..