With Jenkins, why do you need a standalone deployment system?

The need for a standalone deployment system is an issue that many enterprise users often confuse in building a continuous delivery process. There are often users who ask us that there is now Jenkins, which itself provides a rich set of deployment plugins (such as WebSphere deployment plug-ins, tomcat deployment plug-ins, etc.) that allow the user to automate deployment of the built-in deployment package to designated machines (or even cloud services). So why not integrate a range of deployment processes around Jenkins, so you don't need to build an additional standalone deployment system?

Note: This article takes Jenkins as an example to illustrate the importance of a standalone deployment system. But continuous building tools are not limited to Jenkins, but include Buildforge, TeamCity, CruiseControl, and so on, and their relationship to the standalone deployment system is basically the same as Jenkins.

Continuous delivery and deployment systems

This raises a very good question, but to answer this question, we need to understand the role that a deployment system needs to play from a larger perspective (i.e., continuous delivery), not just from the automated deployment process (although this is important). First, let's look at the typical process from code to final service in software production (e.g.).

As you can see, writing code from developers to service end users is a lengthy process that can be divided into three phases:

1. From code to Product library (ARTIFACT): This phase of the development of the developer's code to continue to build and centralize the production of artifacts, is the stage for the deployment of the system to prepare the input content.

2. From product to operational services: this phase of the main completion of the product deployment to the specified environment, is the most basic work of the deployment system.

3. From the development environment to the final production environment: this phase mainly completes the migration of a change in different environment, is the core ability to deploy the system on-line final service.

From a continuous delivery perspective, the core requirement is to allow three phases to be seamlessly connected and run automatically to achieve the two core goals of continuous delivery: increasing the frequency of delivery (number of deployments) and reducing deployment latency (from code submission to on-line time lag).

Continuous delivery requirements for the deployment system

Referring to the process of continuous delivery, you can find that continuous delivery is not just an automated deployment process for a deployment system, but also the reason why you still need to build a standalone deployment system after Jenkins and its associated deployment plug-ins. Specifically, we can analyze from the following points:

1. Decoupling the build and deployment process

While continuous delivery wants to automate the complete process from code to deployment. But the entire continuous delivery process has a number of people with different roles (dev, test, OPS and even managers and marketers). Some of these roles (such as dev/test) need to be concerned with the build process, while more roles (such as operations, etc.) are always deployed from artifacts. This also requires that the build and deployment process be decoupled from one another and operate independently.

If you trigger the deployment directly based on Jenkins, you are directly binding the build and deployment process. Building and deploying both processes through artifacts (Artifact, also known as deployment packages) connections (artifacts are the output of the build process, and are inputs to the deployment process). If they are decoupled from one another, there is a natural need for a unified local management store and management of these artifacts, the unified product library.

With the unified product Library, the build process automatically submits the resulting artifacts to this, while the deployment process is active to the product to take the necessary products to deploy, so as to achieve complete decoupling of the construction and deployment.

2. Managing a complex deployment environment

As mentioned earlier, the service on-line needs to involve many different environment (development, testing, pre-launch, production, demonstration, etc.). Also, in an increasing number of cloud infrastructures, resources within the environment change frequently (for example, auto-scaling can add or reduce your cloud host at any time).

The deployment process needs to be isolated from the deployment environment and the infrastructure that changes frequently within the environment. When a deployment needs to be performed, the operator only needs to specify which environment (that is, the environment name or ID number) to deploy to, without needing to be concerned about any information inside the environment.

It is the responsibility of the deployment system to distribute the deployment requests to each host within the specified environment and automate them. If you deploy directly based on Jenkins, you will inevitably introduce many of the complexities of environmental management into the deployment process.

3. Support Multiple Deployment strategies

To ensure high availability of services, implement deployment and release decoupling, and other business needs, users often need to support deployment requirements such as grayscale publishing, A/b test release, and more. A standalone deployment system provides a variety of deployment strategies, combined with other features such as environmental management, to meet the needs of the business for deployment and release. Similarly, Jenkins and its deployment plug-ins do not provide such capabilities.

4. Implementing the deployment Process specification

There are often different projects within a company, using different programming languages, and the deployment process is varied. From the multiple considerations of controlling risk, reducing repetitive operations, and reducing the difficulty of deployment automation, companies are inclined to develop a standard set of deployment processes.

At this point, a standalone deployment system can help to implement these specifications and validate them in the daily deployment process (in the field of software engineering, almost all of the implementation of the specification relies on tools to help, otherwise the basic will become the specification on paper).

If you are deploying directly based on Jenkins, it is still difficult to implement these deployment specifications because Jenkins and its deployment plug-ins do not provide any substantial support for this.

5. Get Deployment Operations Data

Deployment is a team's critical path from code to service, where all operational data is worth documenting and used for various operational support (including security audits, deployment record queries, deployment frequency and failure rate analysis, and so on). This data can also be obtained based on the direct deployment of Jenkins, but it is more flexible and convenient to do it in a standalone deployment system.

6. Make Deployment Operations Service

As mentioned earlier, deployment is not just for development and testers, but for deploying services so that anyone on the team can trigger a deployment at any time. The interface of Jenkins may be more convenient for developers or testers, but it is too complex for others (and not friendly for deployment). A standalone deployment system can do a better job in this area, helping more people to complete deployment operations at low thresholds.

Of course, in addition to these reasons listed above, the standalone deployment system has some other advantages (such as ease of deployment version management, etc.), not listed here. With the above analysis, I want you to have an overall understanding of the benefits of a standalone deployment system and what it needs to contain.

Of course, you might say, "I'm doing my own deployment process based on the above requirements and Jenkins." If that's true, congratulations! You're already on your way to building a standalone deployment system, and it's not really a big relationship with Jenkins, and maybe you could consider docking the system to other build systems (such as CruiseControl, teamcity, etc.).

Written in the last

As mentioned earlier, a standalone deployment system needs to include a very rich set of content (definitely not just what the Jenkins deployment plug-in does). As shown, the deployment system needs to connect the people involved in the project, the environment, the product library, and the build environment, except that the purpose of this connection is to get through the entire process of product-to-end service (i.e. the second and third phases of the continuous delivery process before this article).

With Jenkins, why do you need a standalone deployment system?