Last Updated Jan 09, 2017 — DevOps Expert
Stop Scripting Your Deployments in your CI Server
DevOps
Continuous Integration tools like Jenkins and Bamboo are especially effective when building, unit testing and validating your applications. In fact, with CI tools, teams can do almost anything they want with code. But do CI tools scale?
The short answer is no. There are many steps required to deploy applications, such as removing servers from load balancers, stopping servers, updating web server content and application server binaries, running database updates, and restarting servers to name a few. Application deployment using a CI server basically means scripting out entire deployments yourself, using CI tools to move your script to a target server and running it there. In an enterprise environment, it wouldn't take long for all this scripting to turn into a convoluted mess.But I Like to Script!
So maybe you're fine with scripting. But are you ok with:- Maintaining all of those deployment scripts, especially if something changes?
- Installing agents on every machine that's not a build server? A QA database or app server is unlikely to be a build agent for your CI tool, for example.
- Having no cross-machine orchestration? CI servers, after all, are designed to run an entire build on one machine of a large pool of possible machines. In contrast, application deployments need parts of a build to run on multiple, specific machines.
- Lacking a suitable domain model for applications and deployments? Yes, you can see whether the job succeeded or not. But answering a simple, very common deployment questions such as “which version of my application is running in which environment” is non-trivial with most CI tools.
Release Pipeline Orchestration: Essential Practices for Continuous Delivery at Scale
In this whitepaper, you will learn about:
- The essential elements of release orchestration, including automation, visibility, intelligence, and control
- The ROI of pipeline release orchestration
Deploying with CI Tools
CI servers typically offer a couple of choices for deployments:- Creating jobs for each application/environment combination (e.g., “MyApp to Dev,” “MyApp to Test”)
- Creating a parameterized job that accepts that application and/or environment as parameters