Continuous Release Practices are evolving, Here is our story
Good Engineering Practices are designed to deliver software more quickly. Short iterations and shorter release cycles have driven significant changes to the development process of multi-release software products. Rapid software deployments to live is a need for businesses, so that they can align with fast-changing consumer requirements and bring more reliable products to the market. In this blog I have summarised the general outlook for CI/CD and shared our story at The Telegraph Engineering
Industry outlook
The concept of a modern day release is driven by lean software practices. However, despite the obvious benefits, Forrester Consulting research found that few organisations regularly perform advanced continuous delivery practices. A small minority of leaders indicate that their software development teams regularly execute mature continuous delivery practices. This slows the rate at which these teams can deliver new releases for existing services and limits the rate at which developers and product owners can get customer feedback on the value of their work.
Researchers found that 15% of organisations have enough funds to implement CD with no barriers. Conversely, 82% of organisations believe that their budgets could prevent the implementation of CD. Additionally, 88% of organisations said that a lack of technical knowledge or skill could be a prohibiting factor in implementing CD practices.
How The Telegraph Platforms and Web team implement best practices
On this blog, I have shared our story of implementing release pipelines to reduce the time taken to deploy and improve communication between various teams. Built using the Jenkins platform, it helped us to reduce the manual time it took to complete deployments to staging for a monolith application. Be warned, any advanced DevOps engineers out there may find some of this information a little basic. But for the purpose of the wider audience, I have given a brief explanation about the different concepts I am describing.
Continuous Integration (CI)
CI is a practice in software development that requires engineers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. In CI, engineers integrate and merge development work (e.g. code) multiple times. CI enables shorter and more frequent release cycles, improves software quality, and increases productivity.
At The Telegraph, one of our core applications is the content management system that powers the content creation and modification for the web, mobile and other 3rd party apps. The Adobe Experience Manager is a monolith and there are around 7 teams (aka Squads) that share the same code base.
To cut down on any last-minute surprises, developers maintain and run the CI for their local changes. We call it “Pre-CI”. The idea is for teams to build and validate their changes on a feature code branch that only has their changes. A setup that is maintained by individual teams helps to provide feedback before their changes are merged into a develop branch. The develop branch in the git flow structure enables all the teams to merge their code. It re-runs the test, but this time with code changes from various teams.
Continuous Delivery (CDe)
This is the next layer in continuous software development. The main purpose is to ensure that a production-ready state is reached after successfully passing automated tests and other quality checks. Although the whole process is automated, in continuous delivery the control can be left to the managers or lead engineers as to what is pushed to production and made available to consumers. Code changes in a continuous delivery process generally occur more frequently, but release frequency is determined by the organisation, thereby providing control.
We recently undertook a task to reduce the deployment time from Development to Staging. As a production-like environment hosted by Adobe Managed Services, it gives us an opportunity to do end-to-end testing for journeys that are manually tested. Having previously required 16 hours of manual deployments and testing, the time has now been reduced to 8 hours. This is a release-ready branch and here is a screenshot of the pipeline:
Here is my recent talk in Jenkins Meetup about the Project Straw.
Continuous Deployment (CD)
Finally, this refers to complete automation from code complete to deployment. The prerequisites are to build Continuous Integration and Continuous Delivery first. Once they are in place, then the final step of layering on the automated deployment system is achievable.
According to a white paper published by Cycligent, a software deployment tool, many companies may not use Continuous Deployment due to quality control reasons. Continuous deployment gives control to software engineers regarding what is released to production. Code changes may occur daily or even multiple times a day.
Whilst this is not implemented for our core CMS application, CD is a day-to-day reality for microservices and a number of standalone applications deployed at The Telegraph Engineering; we have built 156 different CD pipelines for some of our microservices. Amit Lalani, a Senior Platform Engineer, recently shared our Automation
Final thoughts
I have listed the stages and steps required toward continuous releases and How we at the Telegraph Engineering have implemented these best practices to deliver better applications faster. I believe the general CI/CD practices will evolve furthering CD as a crucial methodology for companies like us. I hope that this blog serves as a resource for DevOps looking for ways to better their application development process for a monolith.
If you have implemented a similar setup and/or have ideas you would like to share, then please comment
Mehdi Ali is the Head of Development and Technology at The Telegraph. Follow him on Medium MEHDI Ali and Twitter @mesum98
References
Cycligent (2017). 1st ed. [ebook] Available at: https://s3-us-west-2.amazonaws.com/cycligent-downloads/Continuous+Delivery+Patterns+WhitePaper.pdf [Accessed 15 May. 2018].
Weber, I., Nepal, S. and Zhu, L. (2016). Developing Dependable and Secure Cloud Applications. IEEE Internet Computing, 20(3), pp.74–79.
Shahin, M., Ali Babar, M. and Zhu, L. (2017). Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices. IEEE Access, 5, pp.3909–3943.
Kapur, P., Pham, H., Anand, S. and Yadav, K. (2011). A Unified Approach for Developing Software Reliability Growth Models in the Presence of Imperfect Debugging and Error Generation. IEEE Transactions on Reliability, 60(1), pp.331–340.
Zhu, M. and Pham, H. (2017). Environmental factors analysis and comparison affecting software reliability in development of multi-release software. Journal of Systems and Software, 132, pp.72–84.
Karvonen, T., Behutiye, W., Oivo, M. and Kuvaja, P. (2017). Systematic literature review on the impacts of agile release engineering practices. Information and Software Technology, 86, pp.87–100.
