Deployment Scripts Were Born in Waterfall and 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. The use of continuous deployment and software deployment automation tools improve the process of software deployment without a scripting language through the use of continuous deployment and software deployment automation tools. Automating release management incorporates plugins and reusable scripts shared across teams and life cycle environments.
Heavy Lifting of Software Deployments
Improve Continuous Delivery by replacing one-off scripts with playbooks that plug into external tools. 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.
Each team’s software deployment is put together ad-hoc, using their favorite scripting language, often with mixed results. These one-off deployment scripts are copied and updated for each release version and 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 overloaded and struggles with the deployment demands. Key developers spend costly time updating the scripts, and patching the scalability issues. Central release teams struggle to maintain and understand these one-off deployment scripts. A deployment automation tool can help solve these issues.
Common Issues with scripted Deployments vs Deployment Automation Tools Such as DeployHub
Common issues with a non-automated continuous delivery process include:
When running software deployments in development, you may already have a server configured with a Jenkins ‘slave.’ Moving up the lifecycle with a repeatable software deployment process requires that such 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 automation to DeployHub. Get the DeployHub Jenkins plug-in.
Different Server Types
Jenkins was designed to run the entire Workflow on multiple servers that are identical, and not to manage different types of Servers such as a database server, application server, or load balancers in a single Workflow. It runs the entire Workflow on multiple servers that are identical. Deployments run on different servers with different actions. DeployHub 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 has no concept of Environments (Dev, Test, QA) or Domains (East, West, etc.). Tracking the specific version, Environment, and Domain cannot be done without digging through log history manually, looking to see where a server is. DeployHub tracks this audit detail.
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. However, 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.
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 contro,l where deployments are more tightly managed.
To summarize, developers should move away from a scripted process to allowing Jenkins to call out to a deployment automation tool. DeployHub automates the entire release process instead of just moving files from point A to B. At this level of automation, developer’s jobs become much easier. The process of handing off the deployment to operations also becomes transparent and reproducible. This ease is the goal of DevOps, as achieved through an improved continuous delivery process.
DeployHub’s Key Features
- Blueprint your application’s logical view
- Publish and Catalog Microservices
- Version Microservice Configurations
- Release and Track Microservices
- Manage Database Deployments
- Microservice Configuration Management Blogs
- What is Configuration Management?
- How to Navigate the Deathstar
- Working with Helm for your Microservices Releases
- On Versioning your Container Content
- Versioning Lambda Functions
- How to Use a Domain Driven Design
- Versioning Applications
- Why we need Application Packages for CD
- Agentless Deployments with DeployHub’s Engine
- Version Jumps and Tracking
- How are Microservices and Applications Related?