Deployment Scripts Were Born in Waterfall

Deployment Scripts are No Longer Needed

Deployment scripts were born from a waterfall practice where developers and operations teams had the luxury of time to tweak them across the different stages of the life cycle. I have found a way to improve the process of software deployment without a scripting language through the use of continuous deployment and software deployment automation tools. Automating release management involves incorporating plugins and reusable scripts that can be shared across teams and life cycle environments.

Heavy Lifting of Software Deployments

Improve Continuous Delivery  by replacing one-off scripts written in your scripting language with playbooks that call plugins. This is critical for achieving reproducible software deployments called by your continuous delivery workflow.

For the last 30 years, distributed platform teams have been using one-off scripts to manage software deployments. This is their habit. Developers commonly face the challenge of creating both “build” and “deploy” scripts late in the project schedule reaching for what is quickly available.  These same scripts are then added to the Continuous Delivery workflow. No “Request for Proposal” is developed, requirements are not documented, no “Proof of Concept” is done, budgeting is avoided.

The result is that each team’s software deployment is put together in an ad-hoc method using their favorite scripting language, often with mixed results. These ad-hoc, one-off deployment scripts are copied and updated for each release version and for each state in the continuous delivery lifecycle. The scripts are then called by a CI server such as  Jenkins using the CI Server’s “slaves” to perform the remote execution of the scripts on each end target. In large complex continuous delivery workflows, Jenkins becomes over loaded and struggles to scale up with the deployment demands. Key developers spend costly time maintaining and updating the scripts and patching the scalability issues. Central release teams struggle to maintain and understand the one-off deployment scripts causing frustration when something goes wrong.  A deployment automation tool can help solve these issues.

Jenkins Stack Trace

Common Issues with scripted Deployments vs Deployment Automation Tools Such as DeployHub

Common issues with a continuous delivery process that is not automated include:

Agentless Deployment

When you are running software deployments in development, you may already have a server that is configured with a Jenkins ‘slave.’ Moving up the lifecycle with a repeatable software deployment process requires that a Jenkins Slave be installed on all test and production machines. DeployHub is agentless and eliminates this overhead. Jenkins can still orchestrate the process, but leave the heavy lifting to automation done by DeployHub.  Get the DeployHub Jenkins plug-in.

Different Server Types

Jenkins was not designed to manage different types of Servers such as a database server, application server or load balancers in a single Workflow. It was designed to run the entire Workflow on multiple servers that are identical. Deployments run on different servers with different actions. DeployHub supports a deployment Workflow that understands what needs to occur on each server type and performs automatic mapping component to server even as the server numbers increase in the higher states of the lifecycle.


Jenkins run Continuous Delivery Workflows but have no concept of Environments (Dev, Test, QA) or Domains (East, West, etc.). Tracking what version is running in what Environment and in what Domain cannot be done without digging through log history and having a manual way to track where a server is. This audit detail is tracked when using DeployHub.

Reliance on Deployment Scripts

Jenkins relies on software deployment scripts to do the actual deployment; therefore your deployments can only be as smart as the script itself. There are deployment requirements that are not easily done with a script, such as:

  • rolling a deployment backward or forward with version jumping and database updates,
  • automatically mapping components to servers as you move up the lifecycle dynamically adding more servers to your deployments,
  • Coordinating deployments based on environments (groups of servers),
  • creating a release train that includes a deployment of more than a single application,
  • calendaring and pipeline management.

Continuous Delivery Calendar


Jenkins lack the concept of security making it difficult to setup up different environments with different ownership. Lack of security controls and approval gates may work for development but does not work for testing and production control where deployments are more tightly managed.


To summarize, developers should consider the move away from a scripted Jenkins process to allowing Jenkins to call out to a deployment automation tool such as DeployHub that can automate the entire release process instead of just moving files from point A to B. When developers embrace this level of automation, their job becomes much easier and the process of handing off the deployment to operations becomes transparent and reproducible. This is ultimately the goal of DevOps achieved through an improved continuous delivery process.

Learn More

Software Installations with Pre Built Actions