Automated releases free a lot of time for developers. But the advantages of the continous delivery concept are much broader – here's what it's all about.
SUBSCRIBE TO OUR BLOG
“The most powerful tool we have as developers is automation” – it’s not only Scott Hanselman, renowned programmer, tech blogger and speaker, who says it; it’s one of the most important business trends for 2021 and beyond.
In the developers’ world, one of the most important processes related to automation is continuous delivery: the process in which code is automatically prepared to be released, with the go live also being fully automated.
The concept is based on continuous Integration, which means that every code change is tested automatically in a test environment, before being included in a release.
With continuous delivery, a team can decide to start the release process at any time. A pipeline will automatically build and test the code, making sure that nothing was broken by the latest changes. Afterwards, the code will be packaged into a release-ready artifact and deployed to a testing environment, where some extra manual checks can be done before the final approval.
The approval step is what differentiates this process from continuous deployment: continuous deployment doesn't provide any manual approval at the end. Automated tests run in the testing environment, and once all tests are passed, the code is scheduled for release to production.
Continuous delivery is an extension of continuous integration, not only testing the code ready for release, but also running automated tests on every contribution to the codebase. Any developers who want to contribute code will have their changes tested. If the contributions fail, they'll be blocked until they finally pass all tests.
The deployment to any environment (either production or test environment) should be fully automated when using continuous delivery. This includes the installation of the packages, sanity check runs after a release, and also automated fallback mechanisms if the sanity checks fail.
Next to automated deployments, feature flags are also important when using continuous delivery. Feature flags will make sure that code can be switched off, not to impact production when released.
Why is Continous Delivery important?
Continuous delivery will automate your releases up to the point that you only have two manual steps left. As soon as the team decides to make a release, all previous steps to make this happen are done automatically. The only manual steps left are to start the release and to approve it for production. Continuous deployment even omits that very last step.
This results in (almost) no dependency on the experience of developers to create releases – which also frees up some of their time, to focus more on the actual development of new features and thus create more business value.
To be a bit more detailed, we can sort the main advantages into four categories:
1. Lower risk of errors
Automated building, testing and deployment of code means to reduce the probability of errors. A CI/CD pipeline can easily run hundreds of tests within minutes, whereas this takes a lot longer if executed manually. Continous delivery also means that these tests run with the exact same parameters each time – much less likely with manual testing.
2. Short feedback loop
Due to the fact that every contribution of code is automatically tested, possible errors will be picked up early in the development cycle. This results in a very short feedback loop where developers can see and fix bugs immediately after the tests.
3. Automated fallback
Should it happen that something goes wrong during the release to production, the release will be aborted and reverted to make sure the production environment remains in the same valid state as before the release.
4. Smaller releases
Since manual work for releases is almost non-existing, it is easier to release more often. This has the advantage that if anything goes wrong, the problem can be identified more easily.
Two last tips for Continous Delivery
1. Test, test, test!
To reduce the number of bugs in a release (which of course is always zero, anyhow – just to make sure 😉), enough tests should be included. Run tests on every code contribution – unit tests, front-end tests. These tests should cover the entire codebase and should be extended when developing new features. Make sure to also include end-to-end tests and to check that new features don’t break other (older) features.
Automation is key. You want to have a standard procedure of testing and deploying, without risks of human errors. Automation of the deployment process will result in zero to very few surprises during and after the release, as it will always run under the same parameters.
If you keep all of this in mind, you'll never want to go back in time again and miss all the perks of continous delivery. And if you're looking for more ways to make your life easier with AEM, check out our article on Core Components. Or are you still wondering whether Adobe Experience Manager is the right platform for you? Reach out to us, to create the tailor-made solution that is best for your enterprise!
About the author
Yentl Frickx is an AEM consultant at Amplexor Belgium. He started his Amplexor career with an AEM bootcamp in 2019 and has since worked on different AEM projects and the implementation of a continuous delivery workflow.