Contributed by Steven Terrana
CDF Newsletter – August 2020 Article
Subscribe to the Newsletter
Origin Story
One of my first tasks as a DevOps engineer was to maintain a CI/CD pipeline that would support fifty or so applications being built by different teams that were either Spring Boot microservices or frontend applications. The program leadership expected that each of these teams would follow the same business process to bring a semblance of standardization to the project. Instead of asking every team to learn how to build their own Jenkins pipeline, a central team was responsible for orchestrating pipeline development across all of the application development teams.
After getting my head around the way everything worked, it turned out that some automation existed to seed a java or npm specific Jenkinsfile when new services would spin up. This Jenkinsfile was over 700 lines long, and upon closer inspection, both Jenkinsfiles only differed by 7 lines of code! The difference centered on whether to use maven or npm to execute the application’s unit tests.
I was pretty new to Jenkins pipeline development, but there had to be a better way to handle this difference without needing to manage two separate pipelines just to swap out 7 lines of code.
The solution was to create both a java and npm Jenkins Shared Library that would each implement a unit_test() method. The presence of either a pom.xml or package.json file would result in a different library being loaded, and voilà! We could now collapse these two Jenkinsfiles into a single pipeline that could support multiple types of tech stacks, simultaneously.
We didn’t know it yet, but we had just taken the first step towards creating what would eventually become the Jenkins Templating Engine, a Jenkins plugin that allows teams to create tool-agnostic pipeline templates that can be reused by multiple teams.
How does it work?
The Jenkins Templating Engine allows pipeline developers to create common workflows (called pipeline templates) and share them across teams. These workflows define the business logic of the pipeline in a tool-agnostic way by calling generic functions (called steps). These functions are implemented by one or more reusable modules (called libraries).
Different teams can tailor the pipeline through their own pipeline configuration. The pipeline configuration declares which libraries to load prior to executing the pipeline template.
Through this approach, the same pipeline template can be reused for an arbitrary number of teams, each with their own tool integrations, by loading different libraries.
If that sounds interesting, I would recommend checking out this Jenkins Online Meetup, it’s a great introductional deep dive.. There are also Learning Labs for those who learn better by doing and the documentation for those who want to read about everything the Jenkins Templating Engine has to offer. If you have any questions, we would love to chat in the JTE Gitter Channel.
What’s Next?
We’re currently working on a 2.0 release of the Jenkins Templating Engine!
Over the past few years, we’ve learned a lot. We’re currently taking a pause to perform some significant refactoring to the JTE code base to better align our implementation with the underlying Pipeline Engine upon which it depends.
We’ll also be incorporating a ton of new features that align with the community’s most popularly requested items like support for library resources, field-level governance in the pipeline configuration file, ways to support loading two libraries that contribute the same step, and more! To stay current on the latest JTE developments, check out the Jenkins Project Roadmap which will link you to the JTE 2.0 Scope Document.
