Promotion building blocks

Explore entities and their roles in the promotion process

If you are new to promotions in GitOps, you may find it useful to review the entities involved in the promotion process, and their roles.
There are the core entities that define the structure of your development deployment lifecyles, and promotion-specific entities, which are advanced entities each dedicated to a different aspect of the promotion process.

For a complete end-to-end continuous delivery with Codefresh GitOps promotions, see Promotions: End-to-end guide.

Building blocks

A promotion comprises several building blocks, optional and required, each serving a specific role in the promotion and deployment process. The table describes the core and promotion-specific entities.

Entity	Role in promotions	Created by	Learn more
Core entities These entities define the structure of your deployment. Core entities support standard promotion flows, allowing you to trigger promotions that cover typical deployment scenarios. You can initiate manual promotions between two environments using drag-and-drop and other options. See Promotion tutorials.
Applications (Required)	Applications are the core units around which promotions revolve. Each Argo CD application can be promoted individually or as part of a product.	Users with ABAC permissions	Creating applications
Product (Required)	A Product in Codefresh GitOps groups related applications into a single entity. This simplifies promotions by allowing you to promote applications within the product across different environments, rather than promotion each application manually.	Users	Products
Environments (Required)	Environments are where your applications live and promotions happen. Typically, environments reflect your software lifecycle and deployment stages. You need at least two environments: Trigger environment: Where a change starts the promotion flow, initiated by a manual commit or pull request. Target environments: The environments where changes are promoted after the trigger environment.	Users	Environments
Promotion building blocks These entities are purpose-built for promotions and support advanced scenarios by enabling complex, multi-environment promotion flows with precise definitions and control. Promotion building blocks allow you to orchestrate multi-environment promotion processes, define exactly what gets promoted, and set specific conditions for each promotion. For example, you can quickly set up automated promotion flows, integrate tests and policies, and enforce governance over each promotion stage, giving you total control over how promotions are executed across your environments.
Promotion Flows	Promotion flows orchestrate the movement of applications through environments, ensuring a controlled and automated promotion process for applications within the same product.	Account administrators	Creating Promotion Flows
Promotion Settings	Promotion settings specify what gets promoted across environments. With products, these settings can be defined within the product’s configuration, either inline exclusive to the product, or as a reusable promotion template.	Users with ABAC permissions	Promotion settings for products
Promotion Workflows	A Promotion Workflow is an Argo Workflow which runs tests and validations that match the requirements of the promotion lifecycle. They can run smoke tests, rollback mechanisms, database validation checks, or performance tests.	Users with ABAC permissions	Promotion Workflows
Promotion Policy	A Promotion Policy outlines the actions taken when changes are promoted. It combines workflows that test and validate the environment, with the promotion action, like commits or pull requests.	Account administrators	Promotion Policies

Promotion entities and GitOps Runtimes

Most of the core and promotion-specific entities are stored as Custom Resource Definitions (CRDs) in the Shared Configuration Repository of the GitOps Runtime designated as the Configuration Runtime. If you have more than one Configuration Runtime, Codefresh automatically consolidates the settings into a single set of promotion manifests.

NOTE
In the documentation, we use Shared Configuration Repository or Shared Config Repo for clarity.
In code samples and internal references, it is represented as isc.

Related articles

About promotions
Promotions: End-to-end guide
Triggering promotions
Tracking product releases