Continuous Delivery improved with Release Management
Use release management automation and plugins in your Continuous Delivery Workflows
You can easily improve your Continuous Delivery by automating software deployments with release management. Automating release management involves incorporating plugins and reusable scripts that can be shared across teams and life cycle environments.
Continuous Delivery can be easily improved by implementing release management for performing the heavy lifting of software deployments. Replacing one-off scripts with playbooks that call plugins 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, often with mixed results. These ad-hoc, one-off 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 scripts causing frustration when something goes wrong.
Common Issues with scripted Continuous Delivery Software Deployments
Common issues with a continuous delivery process that is not automated include:
1. Jenkins require Agents. 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. Release Engineer is agentless and eliminates this overhead. Jenkins can still orchestrate the process, but leave the heavy lifting to automation done by Release Engineer. The Release Engineer Jenkins plug-in can be found at Release Engineer Jenkins Plugin
2. 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. Release Engineer 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.
3. 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 Release Engineer.
4. 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.
5. 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.
Developers should consider the move away from a scripted Jenkins process to allowing Jenkins to call out to release management tools 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.