Continuous delivery is a software development practice in which every build is made production ready. Build should be able to be deployed into production environment at the click of a button. Here the emphasis is given to ensure that the system works rather than addressing new requirements/any bugs.
Why is Continuous Delivery needed?
Continuous delivery enables the teams to achieve the following:
- Check if the teams are building right things
- Get the feedback at more frequent intervals
- Gauge the real progress
- Reduce the risk of releases
Continuous delivery majorly reduces the risk of release as the work of every developer/user-story/feature is committed and turned into a build, tested for failures, integrated with the existing code and is checked on the live environment. This will reduce any complexities of merging works of various developers.
As any feature accomplished/done is made releasable, quick feedback can be achieved and the real progress can be gauged.
How to achieve Continuous Delivery?
Continuous delivery can be achieved by practices such as Continuous Integration and deployment pipelines. It requires tools which facilitate configuration management and tools such as Jenkins which facilitate continuous integration.
What is Continuous Integration?
Continuous integration is a practice in which the software developers integrate their code frequently, usually at least once in a day. Each integration should be checked by an automated process where integration errors are checked out.
Post developers commit their code on to the major source of code, tests are run to check if there are any integration issues. While one developer is integrating and running tests, no other developer is allowed to commit to the key code in version control system. If there are any issues, they should be fixed and the code should be made bug free. In case the issues cannot be fixed immediately, roll out the changes and work in silos so that others can integrate their code.
What are the best practices for Continuous Integration?
Trunk based development is one major approach widely recommended to achieve CI. In this method, a single source called trunk is used by all the developers to commit their code to. Before committing, the developers should run their code against unit tests and ensure that the code is bug free. Post which the developers will commit their code to the trunk and will resolve integration issues.
The smaller the code and more the integration, more the issues can be resolved at the earliest and in an easier manner.
Branches are made out by the release engineers from the trunk before the release. But the developers commit their code to the trunk. In case of any bug fixes/requirements done are to be pulled to the release, they will be cherry picked by the release team and will be merged to the release branch.
In any case, the trunk has the updated code and the branch will be deleted post the release. New branch will be created for the next release.
What is Deployment Pipeline?
Deployment pipeline is an automated implementation process of system’s build, deploy, test and release. Running all the tests may take time and the build may be delayed. So this is divided into stages and tests are run at various stages.
Post the code is checked into version control, run the automated unit tests and if passed, run next set of tests. If failed, roll out the changes, fix the issues and re check-in the code and run the same process. The code should be tested against all the tests and post which the code is merged with the key code. If every build results in a release, then it can be deployed.
It is recommended to automate the unit, integration, system, and regression tests. User scenarios, acceptance tests may be manual depending on the system.
How to check if Continuous Integration works?
Developers should check their code to the trunk at least once in a day and every check-in should result in a build which is up and running. This build should be tested automatically against the tests to check for any integration issues.
How is it different from Continuous Deployment?
Continuous delivery is about ensuring that every build is made production ready while Continuous deployment is about deploying the build onto the production environment or near production environments. Deploying every build onto production environments is a business decision and it is left for the business to decide how frequently they should release.
Does deployment mean release?
Every deployment may not mean release. Organizations may be doing continuous deployment onto near production environments but they may not be releasing to the users.
How to hide certain features from being released when practising Continuous Deployment?
Feature toggles is a mechanism which will enable unintended features to be hidden during the deployment. They can also enable the features to be visible to only specific audience. For example certain features can be released only to premier customers and post feedback, the feature can be rolled out to the entire set of customers.
There are different types of feature toggles such as Release toggles, Experiment toggles, Ops toggles, Permission toggles, and A/B toggles which are used to achieve various purposes.
What does Dev-Ops mean?
Dev-Ops is a collaborative culture where in the development, operations and maintenance teams collaborate to share the responsibilities. Development team may automate the deployments, logging or do something which will aid the operations team in deploying and maintaining the system in production environment. Operations team understanding the business goals and facilitating the development teams in achieving the same will help the organization in achieving the intended business goals. It enables to put qualitative code into production.
What is important to achieve Continuous delivery, Continuous Integration or Dev-Ops culture?
It is the mind-set of the people which is very essential in achieving any of the goals. Coordination between the teams is another factor which will enable Continuous Delivery/Integration/Deployment, Dev-Ops to become the practices and patterns of the teams.