1.1 Why JTE?
Modern Jenkins use consists of defining and using pipelines. Pipelines define and control a specific set of operations in the CI/CD process. These operations call out specific tools and directories. Pipelines are not reusable across projects. JTE uses more generic templates that may be reused across projects. Traditional pipelines are not reusable because they are hard coded.
1.2 What is JTE
JTE allows the definition of pipeline templates. Pipeline templates genericize pipeline creation. Templates provide a high-level definition of the steps in the CI/CD process. It focuses on what happens and when in the process and decouples the what and when from implementation. JTE defines the logic of the CI/CD process.
1.3 JTE Benefits
1.4 Organizational Governance
JTE standardizes CI/CD process across projects and teams. JTE defines high level process steps. It reuses templates across technology stacks. Process steps are technology agnostic (e.g. build()). It ensures compliance by requiring projects to use a common template. If you define a build() step in JTE, it is generic. In a traditional Jenkins pipeline you would have to specify a tool and specific command s like npm –build or mvn –build.
1.5 Optimize Code Reuse
Templates are generic. Templates decouple process from implementation. Implementations are packaged in reusable/shareable pipeline libraries.
1.6 Simplify Pipeline Maintainability
JTE is designed with separation of concerns in mind. The template defines operations and sequencing. The actual tech stack-specific functions are decoupled from the template in libraries.
1.7 Key Idea
Regardless of technology stack the high-level steps in the CI/CD process are the same. Unit Test might be JUnit or Karma/Jasmine. Static Code Analysis might be SonarQube or SonarJS. Package Artifact might be creating a JAR file or using webpack. Deployment to Dev might be pushing to AWS or copying to JBoss.
Note: This is a sample workflow
1.8 Templates
Templated are designed to be human readable and machine executable. They consist of steps and primitives. Steps are actions whose implementation is defined in a pipeline library.
Sample template:
unit_test()
static_code_analysis()
build()
functional_test()
deploy_to dev
Note:In the sample template dev is a primitive and it defines the target environment ot which the application will be deployed.
1.9 Template Steps
In the sample template above, there is a build step step(). This step indicates that the build should be done here. It does not specify what tool is used to build, what files are being built and what to do with the resultant build artifacts.
1.10 Template Reuse
Because templates are generic, templates can be applied to multiple projects. Reusing templates enforces consistency across projects.
1.11 Configuration Files
Configuration files add the implementation piece to generic templates. They are required in order to execute templates. Templates are adapted (customized) for specific builds using configuration files. Configuration files are written in a groovy DSL. They are stored in root of source code or pipeline configuration repository.
File name: pipeline_config.groovy
Note:
A DSL or Domain-Specific Language is a computer language used for a specific purpose. For example HTML is a DSL, it is used for semantic content markup. DSLs are different from general-purpose languages (C#, Java, Kotlin) that can be used to solve general computing problems.
1.12 Example
application_environments{
dev{ long_name = “Development” }
prod{ long_name = “Production” }
}
libraries{
github
sonarqube
openshift{
url = “https://example.openshift.com”
cred_id = “openshift”
}
}
Note
This configuration file defines two environments: dev & prod
1.13 Configuration File Sandboxing
Configuration files run as scripts. JTE limits the features available to configuration files for security purposes.
E.g. no access to /etc/.
1.14 Summary
In this tutorial, we discussed
Why JTE?
Introduction to JTE
Configuration Files
Configuration File Sandboxing
