Job Templates Overview #
In an application delivery cycle, shipping an application typically involves running a few individual tasks one after another, such as a Build Job, a Deploy Job, a Promote Job, and a Rollback Job.
Each of these individual tasks is a job. When you group a set of such jobs together into one reusable workflow, that aggregation becomes a job template.
A job template is a reusable and standardised workflow definition within BuildPiper that encapsulates one or more execution steps required to perform a specific activity. Job templates help organisations define delivery processes once and reuse them across multiple applications, services, environments, and pipelines. Rather than manually configuring the same build, deployment, testing, validation, or operational workflows repeatedly, teams can leverage job templates to ensure consistency, governance, and operational efficiency across the software delivery lifecycle.
A job template serves as a blueprint that defines the following:
What activities need to be executed.
The sequence in which they should execute.
Required input/output/override parameters.
Execution conditions and validations.
Standardized operational controls.
Types of Job Templates #
BuildPiper supports two types of job templates to address different levels of reusability and standardisation.
1. Application-Level Job Template #
An application-level job template is designed for workflows that are specific to a particular application or team. These templates are typically created when application teams require specialised build or deployment logic that is not shared across the organisation.
2. Global Job Template #
A Global Job Template is designed to be shared across multiple applications, business units, and teams. These templates are centrally managed and typically contain organisation-approved delivery processes and governance controls.
Explore the Two Template Types #
Read more: Application Job Template > Overview
Read more: Global Job Template > Overview
Why Two Constructs? #
Organisations typically have a mix of shared delivery processes and application-specific requirements. Using only a single template model often results in one of two problems: • Excessive customisation that reduces standardisation. • Excessive standardisation that limits application flexibility. BuildPiper addresses this challenge by providing both application-level and global job templates.
Benefits of Application-Level Templates #
• Supports application-specific requirements. • Enables team-level customisation. • Accommodates specialised build and deployment logic. • Reduces dependency on platform administrators.
Benefits of Global Templates #
• Enforces organizational standards. • Promotes reuse across applications. • Simplifies governance and compliance. • Reduces duplication of common workflows. • Enables centralized maintenance and updates.
Together, these constructs provide the flexibility required by application teams while maintaining the governance required by platform and DevOps teams.
Key Capabilities #
A job template defines a repeatable process that ensures all applications follow the same execution pattern.
A template can contain multiple catalogue steps executed sequentially or conditionally as part of a complete workflow.
The same template can be used by multiple applications and teams, reducing duplication and ensuring consistency.
Organisations can enforce mandatory controls, such as: • Security Scanning • Quality Gates • Approval Workflows • Validation Checks • Audit Requirements
How Job Templates Fit Into Delivery #
1. Step Catalogue → Job Template #
A step is the smallest unit of work within a Job. It performs one discrete action — such as cloning a repository, running a security scan, or pushing a Docker image. A Job is made up of one or more such Steps, executed together to complete that Job’s purpose.
The Step Catalogue is the central, reusable library of execution steps in BuildPiper — define a task once, then reuse it across jobs, pipelines, and applications.
For example, clone_repo, build_image, and push_image can each be reused across any number of Build Jobs, instead of being rebuilt every time.
A Job can be understood as a single unit of executable work within a pipeline. It defines what action needs to be performed and how that action should be executed as part of the overall application lifecycle.
For example, a Build Job is made up of many individual Steps, executed one after another, such as: clone_repo, external clone, pre-hook, build_image, push_image, post-hook, and image cleanup.
Each of these is a separate Step — together, they make up the complete Build Job.
A Job Template is created by assembling multiple Step Catalogue entries into a predefined workflow that achieves a specific objective.
Example:
2. Job Template → Pipeline #
A Pipeline in BP is used to orchestrate multiple jobs and their associated workflows into a single, unified execution flow. Each job step is governed by a blueprint defined within a Job Template, which specifies the actions, configurations, and execution logic required for that job.
A Job within a pipeline job step is mapped to a corresponding same job in the application Job Template by default (until it is explicitly overridden at the pipeline level), the application job template defines how that job is executed and what operations it performs.
Example:
Suppose we have a Payment Service and want to build it in the Dev environment. When the CI build job is configured on the pipeline, the pipeline fetches the metadata of the template that is present in the dev environment of the Payment Service and the same steps are invoked during the build execution.
Example:
Template Versions: V2 and V3 #
V2 and V3 are the two types of Application-Level Job Templates available in BuildPiper. Both come pre-loaded as default, system-generated templates, so there is no need to create them from scratch. When creating a new application, you can simply clone either template and use it as a starting point.
V2 Template #
V2 is built for static jobs. Its UI is static, not rendered dynamically — the workflow is predefined, made up of BuildPiper’s standard job types. The V2 default template is pre-loaded with 8 supported job types:
| Job types 1–4 | Job types 5–8 |
|---|---|
| Build Job | API Call Job |
| Deploy Job | Jira Ticket Job |
| Promote Job | Deploy ConfigMaps Job |
| Rollback Job | Deploy Secrets Job |
Values in a V2 template are defined at the template level — every service using the template shares the same set of values.
V3 Template #
V3 is built for dynamic and custom jobs. Its UI is also rendered dynamically — you can create the template and add any number of jobs to it, with any number of steps inside each job, built around exactly what your workflow needs. Values in a V3 template are configured at the service level — each service using the template can set its own values.
Note: Parallel Step and Conditional Step are not supported in V3 yet. Only Normal Steps can currently be added to a V3 template.