Why automate gated code check-ins using ElasticBox?

In the last decade, we’ve been devising a number of tools and platforms like Jenkins, GitHub, ElasticBox to fully automate software development and build processes.

Automating software builds has one big challenge. How to keep the rigor of a gated check-in process in place as we automate triggers, builds, and deployment environments in each stage?

You can address these automation challenges with the ElasticBox Jenkins Plugin. It works by integrating Jenkins and your source control repository with ElasticBox. The plugin automates a gated process for checking in code and ensures that code is of quality and is deployed at each stage consistently and quickly.

For example, take a look at the gated check-in process we follow at ElasticBox.

Automate gated code check-in process at ElasticBox

Gated check-in process at ElasticBox

At ElasticBox, we use GitHub as our source control management repository. Each code check-in for a bug fix, enhancement, or new feature starts with a pull request. When a dev creates a new pull request, Jenkins triggers a job to build the pull request package.

With the help of the ElasticBox Jenkins plugin, the job deploys instances for the pull request and runs tests against them. Peer developers and testers review the pull request using live instances. Subsequent updates to the pull request also trigger the pull request job to build a new package, reinstall or reconfigure the pull request instances with that package, and then run the tests against updated instances. Only pull requests that we review, test, and verify are merged. A closing or merging pull request triggers a clean-up job that terminates and deletes all instances of the pull request.

When we merge a pull request to the master repository, Jenkins triggers a job to reinstall staging instances again with the help of the ElasticBox Jenkins plugin. If staging reinstalls successfully, another job runs end-to-end scenario tests against updated staging instances. The code check-in is finally pushed to production with a job that reinstalls the production environment if all the end-to-end tests against staging pass.

Configure build environments in ElasticBox

To automate the build processes, we configure the build environments in ElasticBox. By default they consume minimum resources, are reusable across environments and can deploy anywhere.

Each build environment is defined as a box. A set of boxes can represent a complex multi-tier enterprise grade web application. These can include a web server box, application services box, backend service box, search service box, message queue box, database box, and more. To connect these layers, we bind the boxes. By deploying the same set of boxes in all environments, we ensure that environments are consistent, and the code is the same across dev, test, staging, and production.

Reuse and deploy anywhere

The number of instances you deploy in each build environment can vary. For example, in dev and test environments we deploy only one instance of the web server, application services, and database. In staging and production though, we deploy multiple instances because we need to load balance multiple web servers and application service instances, and form cluster nodes of database services for high performance and availability.

The multi-tier application box installs all the tools and libraries required to build the source code, prepare a release package, and run unit tests. You can deploy the build environment to any infrastructure you choose. Choose the public cloud like Amazon Web Services, Google Compute, Microsoft Azure, or SoftLayer. Or deploy in the private cloud like VMWare vSphere, CloudStack, OpenStack, Rackspace, or HP Cloud.

For a local development environment, we deploy the box on our laptop. For a test environment, we deploy the box in our private cloud. For staging and production, we reuse the same box but in hybrid clouds, that is, web servers are in the public cloud whereas the database clusters are in the private cloud.

The takeaway

If you wonder why you would automate your code check-ins using ElasticBox, it boils down to these benefits in a nutshell:

  • Provide a consistent build environments
  • Use a minimum number of resources
  • Deploy flexibly in different infrastructure
  • Reuse the same build configuration no matter the environment

The question is, are you ready to try the ElasticBox Jenkins Plugin today? Reach out to us for a walkthrough tailored to your unique needs.

Hacker News

Categories: Cloud Computing, ElasticBox, Jenkins
Tags: , , , , , , , ,