This article is the fourth in a series describing how the development team at RightScale does continuous integration (CI) and continuous delivery (CD) in the cloud. The previous articles provided an overview of CI/CD in the cloud and described how we do agile regression testing and dynamic scaling of Jenkins in the cloud at RightScale.
In this article, I will describe how the RightScale development organization has implemented continuous delivery of our RightLink™ package and enabled us to release as frequently as needed based on customer demands.
The Problem: Compressing Long Release Cycles with Continuous Delivery
Although the RightScale platform is a SaaS solution, we also develop a software agent, RightLink, that is automatically installed on our customers’ cloud instances and communicates with the RIghtScale platform to monitor these instances and perform management functions.
In the early days of RightScale, RightLink was released every 12-18 months. However, as the company grew and gained more customers, we wanted to release more frequently. In addition, the long release cycles with many code changes pushed the discovery of bugs to the end of the release process long after the code changes had been made. This made it more difficult to find and fix the issues.
The Solution: Continuous Delivery of RightLink
To accelerate the release cycle, we implemented a continuous integration and delivery process. Each time changes are made to the code in the GitHub repo, Jenkins is triggered and unit tests are run. Every night, we use the RightScale API to launch a number of servers — one for each supported architecture and OS — which build the package and upload it into cloud storage. Then, using the RightScale API, we provision test servers in the cloud to run the newly built packages and automatically execute Chef test scripts. Any issues found are reported to the development team so that fixes can be made immediately.
The nightly build is made available for both internal use by RightScale developers as well as for customers who want to test the latest and greatest features. Because we now have a tested package at all times, we can make release decisions based on customer needs or market demand. If a customer needs a particular feature, we simply do final regression testing and then create a release.
As a result, our releases are now averaging about three months apart and could be even shorter if needed. This enables us to get new features in the hands of customers more quickly.