"Jenkins" 2.0 New era: from CI to CD

2.0 Broken Cocoon Rebirth

Since the end of last September Jenkins founder Kohsuke Kawaguchi proposed Jenkins After the vision and draft of 2.0 (2.0), the entire Jenkins community was cheered up, whether it was the official blog or the Google Forum, and everyone was enthusiastically discussing and looking forward to the arrival of 2.0. April 20, after an iteration of Alpha (2/29), Beta (3/24), RC (4/7) 3 versions, 2.0 finally officially released. This is the first major version of Jenkins's 11-year-old Hudson. So what exactly does this upgrade contain?

External

Externally, the 2.0 largest three selling points are pipeline as Code, the new unpacking experience and 1.x compatibility.

Pipeline as Code is the essence of the 2.0 and is the key enabler for Jenkins to achieve a continuous integration to the CD (continuous Delivery). The so-called pipeline, in short, is a set of workflow frameworks running on Jenkins that connect tasks that would otherwise run independently on a single or multiple nodes to achieve a complex release process that is difficult for a single task to accomplish (for example). Pipeline is implemented in a groovy DSL (similar to gradle), and any release process can be described as a groovy script, and Jenkins supports reading scripts directly from the codebase, thus implementing the idea of pipeline as code.

the new out-of-box experience seeks to reverse the dull and unchanging interface style that we have seen in Jenkins for ten years, not only in the Jenkins application itself, but in the website layout, blog style, and even domain names being redesigned. These changes have greatly improved the user experience and, more importantly, conveyed a clear signal that Jenkins is no longer just a CI tool, but a limitless possibility.

1.x compatibility for all older users to eat a big reassurance, note that is fully compatible OH.

Internal

Internally, 2.0 includes some component upgrades and JS Modular transformation.

• Upgrading the servlet version to 3.1 for Web sockets support
• Upgrade the inline groovy version to 2.4.6
  
  • A future version of Jenkins will completely strip groovy from the kernel, and this groovy upgrade is just the first step
• Provides a simplified JS class library for plugin developers to use

Better containerized support

As containerized technology (represented by Docker) continues to heat up, Jenkins follows the trend, not only uploading 2.0 of Docker images synchronously, but also providing default Docker support in pipeline.

In addition to the above, 2.0 has a more interesting change, global renaming slave as agent, it seems to be in the United States it political correctness is also very important AH.

Pipeline as Code

After knowing the general picture of 2.0, come back and look at the background and concrete composition of pipeline as Code (later called pipeline).

Create a background

As the core plugin of 2.0, pipeline is not a new thing, its predecessor was workflow Plugin, and workflow's birth was inspired by the earlier build Flow Plugin, by Nicolas De Loof released its first version in April 2012. And throughout Jenkins's several rivals (Travis CI, Phpci, Circleci), pipeline is not a fresh concept. It can be said that the release of Jenkins 2.0 is the trend, but also the inevitable.

If the background of pipelined is to be explored on a broader scale, I think there are three levels of reasons.

• The first level, related to the growing complexity of publishing, one of the typical scenarios is grayscale publishing. Originally only large companies have the grayscale release, with the broad adoption of agile development practice, product iteration cycle of the continuous shortening, the idea of data growth in the popular, more and more small and medium-sized companies also began to explore this aspect, the release of the demand also from the point-like CI upgrade to a line-like CD. This is the first reason for the pipeline to occur.
• On the second level, with the modular evolution of the application architecture, with MicroServices as the representative, an application upgrade often involves the co-release of multiple modules, and a single CI is clearly unable to meet such requirements. This is the second cause of pipeline's emergence.
• The third level is related to the growing number of CI numbers that are out of control. On the one hand, package management tools such as Maven, Pip, and RubyGems have resulted in an explosive growth of applications with CI requirements, and, on the other hand, benefit from the convenient Git branching feature, which often requires multiple CI configurations even for the same application. As the number of CI continues to grow, centralized task provisioning becomes a bottleneck, which requires delegating responsibility for the task configuration to the application team. This is the third reason that pipeline (as Code) produces.

Concrete composition

After the background, look at the specific composition and characteristics of pipeline.

Basic concepts:

• Stage: A pipeline can be divided into stages, each stage representing a set of actions. Note that the stage is a logical grouping concept that can span multiple node.
• Node: A node is a Jenkins, or master, or agent, which is the specific run-time environment for step execution.
• Step:step is the most basic operating unit, small to create a directory, large to build a Docker image, provided by various Jenkins plugin.

Specific composition:

• The jenkinsfile:pipeline definition file, composed of Stage,node,step, is generally stored in the Code Coogan directory.
• Stage View:pipeline Visual presentation, similar to the.

2.0 default support three types of pipeline, ordinary Pipeline,multibranch pipeline and organization Folders, the latter two are actually batch create a set of ordinary pipeline shortcuts, corresponding to multi-branch applications and multi-application of large organizations. Note that additional installation plugin is required to obtain support for organization folders.

It is worth mentioning that 2.0 has two very important features:

• Pausable: The Read command, similar to bash, 2.0 allows the release process to be paused, waiting for manual confirmation before continuing, which is especially important to ensure application of ha.

• Durable: In the publishing process, if Jenkins hangs up, the running pipeline is not affected, that is, the pipeline process is independent of the Jenkins process itself.

Example Pipeline

The example pipeline mentioned above can be found on my GitHub, and if there is a problem you want to discuss with me, you can add me qq:7789059.

Reference

• The need for Jenkins Pipeline
• Jenkins 2.0
• Why Pipeline?
• Pipeline-as-code with Multibranch workflows in Jenkins

Reprint please retain source and original address : HTTP://EMACOO.CN/BLOG/JENKINS-2-0-FROM-CI-TO-CD

"Jenkins" 2.0 New era: from CI to CD