As a software company run by developers for developers, two core engineering values define us. Dogfooding is number one. Since we are our primary user, dogfooding ElasticBox helps us learn firsthand what we would otherwise have to learn later and more painfully from customer experiences. Our second engineering value is to deploy daily to keep ourselves honest and tighten the feedback loop with customers. Today, we live both these values through CI/CD with the ElasticBox Jenkins Plugin. Here, we share why and how we implemented it.
Continuous integration and delivery refine the process of delivering software. It enables us to build high-quality features and then package and ship systematically. It gives us speed–the ability to push features and fixes faster to our customers.
CI/CD then and now
Although we practiced CI/CD through Jenkins and ElasticBox before the plugin, we weren’t satisfied. Several pain points like long build times, manual steps, cloud resource costs, and laborious lifecycle management snagged our deployments.
Today, Jenkins automatically runs deployments in the test, staging, and production environments using the ElasticBox Jenkins Plugin. The plugin integrates ElasticBox, our cloud application manager, with GitHub, our source code and version control system, and Jenkins.
To reduce the risk of defects, we closely match the development environment stack with the test, staging, and production environments. Whenever a developer submits a code change, Jenkins launches a test instance via ElasticBox. At the same time, automated unit and end-to-end tests run against each code commit. If the tests pass and reviewers approve, the code moves to the next stage.
Similarly, to deploy and maintain staging and production environments, Jenkins runs workloads pre-defined from boxes through ElasticBox build steps. Infrastructure independent boxes let us run builds on any cloud such as AWS, Google Cloud, vSphere, Azure, and more.
CI/CD versus releases
But deploying continuously doesn’t mean you push to production every time. In fact, launching to production is a business decision. While the engineering team deploys to test and staging environments continuously, only a scheduled cadence of them launch into production.
The bottom line for us is that CI/CD with the plugin gives us fast, automated deployments. That’s deploying 20-30 times a day–saving nearly 100 hours of manual overhead a month. As someone wisely said, velocity beats everything. Fast and frequent deploys help us respond quickly to security issues, bugs, patch releases. Because our application is setup as microservices encapsulated in boxes, instantiating and maintaining their lifecycle happens organically through the plugin.