Reusable and standardised workflow definitions that encapsulate one or more execution steps required to perform a specific activity across your software delivery lifecycle.
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:
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.
ABenefits of Application-Level Templates
Supports application-specific requirements.
Enables team-level customisation.
Accommodates specialised build and deployment logic.
Reduces dependency on platform administrators.
BBenefits 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.
A job template defines a repeatable process that ensures all applications follow the same execution pattern.
2Multi-Step Orchestration
A template can contain multiple catalogue steps executed sequentially or conditionally as part of a complete workflow.
3Reusability
The same template can be used by multiple applications and teams, reducing duplication and ensuring consistency.
4Governance
Organisations can enforce mandatory controls, such as:
Security Scanning
Quality Gates
Approval Workflows
Validation Checks
Audit Requirements
Relationship Between Step Catalogue, Job Template, Pipeline, and Applications #
1Step 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:
2Job 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:
3Job Template → Applications
Job Templates can be associated directly with applications at the Service–Environment level. This is important because the configuration and operational requirements of a service can vary across environments. In BuildPiper, a Service represents the logical microservice, while a Service Environment represents that service attached to a specific Application Environment.
For example:
settings like ConfigMaps, Secrets, and other service values can be different for each environment — Dev, QA, Stage/UAT, and Production. The amount of checking done before deployment can differ too. Teams often run a quick, basic set of checks in Dev to move fast, then run more thorough checks in Stage or UAT before the change goes live in Production.
Associating Job Templates at the Service–Environment level therefore provides the flexibility to define and execute environment-specific jobs and validations based on the requirements of each stage of the application lifecycle.
Therefore, Job Template selection is provided at the Service Environment level rather than only at the Service, Application Environment, or Application level.
