Table of Contents:
The Jenkins Templating Engine (JTE) is a plugin originally created by Booz Allen Hamilton enabling pipeline templating and governance.
Different teams are going to use different tools, but the flow of the pipeline is typically consistent. Having to maintain a Jenkinsfile in every source code repository introduces real challenges when scaling a DevOps pipeline across an organization:
- Time: Typical Jenkins Shared Libraries help to consolidate common pipeline code, but software teams should focus on where they provide business value: building their application. Jenkins can have a nontrivial learning curve and there's a desire to achieve economies of scale within an organization.
- Governance: Having a Jenkinsfile in every repository makes it difficult, if not impossible, to ensure that every team is following an agreed upon business process to get code from developer's laptops out to users in production. Furthermore, developer's have access to this Jenkinsfile and could have permission to skip required quality or security gates.
- Maintainability: Incorporating lessons learned into the pipeline over time becomes untenable when there are multiple pipeline definitions - it requires opening a Pull Request across each source code repository.
JTE aims to remove this friction by pulling the Jenkinsfile out of individual source code repositories and instead, creating tool-agnostic Pipeline Templates that can be reused across multiple teams.
For the academic coders out there, one way to describe the Jenkins Templating Engine is an implementation of the Template Method Design Pattern for Jenkins pipelines. JTE essentially separates the business logic of a pipeline from the technical implementation.
Templates define a workflow by calling steps. Steps are contributed by libraries. Instead of a Jenkinsfile in each source code repository, teams can now inherit a Pipeline Template (or choose a template from a Pipeline Catalog) and then configure the pipeline through a configuration file that specifies what libraries to load. Based on what libraries are loaded, the same Pipeline Template can be used to support an arbitrary combination of tools.
If your Pipeline Template is setup to build, test, scan, and deploy then it doesn't matter if you're using Docker, Maven, SonarQube, and Helm or NPM, Fortify, and S3: both pipelines can now be executed via the same Pipeline Template.
There are many resources available to help you get started:
- Documentation
- Presentations
- Blog Posts
There are many ways to get involved. We look forward to hearing from you.
JTE has a channel in the Jenkins community's gitter space. It's a great place to ask questions or propose ideas for the future of JTE.
Something not quite working right? Have a cool idea for how to make JTE better? Open an Issue on the JTE repository and let's get the conversation started.
No contribution is too small - all are appreciated!
Documentation is crucial to the health of JTE as a framework. Please feel free to update the documentation to resolve typos, make an explanation more clear, or add a new page to explain a particular pattern or concept.
JTE is the core engine that powers Booz Allen's open source DevSecOps capability, the Solutions Delivery Platform. To facilitate the aggregation of documentation, we leverage a documentation framework called MkDocs along with the Material for MkDocs theme. Documentation for MkDocs is written in Markdown. The documentation can be found in the docs directory. To view your changes locally, run just serve and then open 0.0.0.0:8000 in your browser.
JTE is written in Groovy and Unit Tests for JTE are written using Spock.
Feel free to open a Pull Request that addresses one of the bugs outlined in an Issue!
New features are welcome. JTE strives to be an unopinionated framework for creating tool-agnostic Pipeline Templates. Some features are great ideas, but belong in a separate plugin or can be implemented through libraries. Because of this, it would be best to open an Issue to discuss the feature first so we can have a conversation about it to see if there's already a way to achieve the same functionality without bringing it into JTE's core.