Evolution of Jenkins Jobs and How We Got the YAML-Based Format

⚠️ The examples in this chapter work only with serverless Jenkins X.

The Jenkins X pipeline extension model is, in my opinion, one of the most exciting and innovative improvements we recieved with Jenkins X. It allows us to focus on what really matters in our projects and ignore the steps that are common to others. Understanding the evolution of Jenkins pipelines is vital if we are to adopt the extension model. Before we dive into extensions, we need to understand how pipelines evolved over time.

Freestyle jobs

When Jenkins appeared, its pipelines were called Freestyle jobs. There was no way to describe them in code, and they were not kept in version control. We were creating and maintaining those jobs through Jenkins UI by filling input fields, marking checkboxes, and selecting values from drop-down lists. The results were impossible-to-read XML files stored in the Jenkins home directory. Nevertheless, that approach was so great (compared to what existed at the time) that Jenkins become widely adopted overnight.

But, that was many years ago and what was great over a decade ago is not necessarily as good today. As a matter of fact, Freestyle jobs are the antithesis of the types of jobs we should be writing today. Tools that create code through drag-and-drop methods are extinct. Not having code in version control is a cardinal sin. Not being able to use our favorite IDE or code editor is unacceptable. Hence, the Jenkins community created Jenkins pipelines.