localurl:/docs/promotions/create-promotion-sequence/

-title:Promotion tutorials

localurl:/docs/promotions/promotion-scenarios/

-title:Entity configuration

localurl:/docs/promotions/entities

-title:YAML specs

localurl:/docs/promotions/entities/yaml/

-title:Trigger promotions

localurl:/docs/promotions/trigger-promotions/

-title:Tracking releases for products

url:"/promotions-overview"

-title:Getting started

url:"/getting-started"

-title:Promotion tutorials

url:"/promotion-scenarios"

-title:Promotion building blocks

url:"/promotion-components"

-title:Promotion setup guidelines

url:"/create-promotion-sequence"

-title:Entity configuration

url:"/entities"

sub-pages:

-title:Promotion Flows

url:"/promotion-flow"

-title:Promotion Policies

url:"/promotion-policy"

-title:Promotion Workflows

url:"/promotion-workflow"

-title:Product Settings

url:"/product-promotion-props"

-title:YAML specs

url:"/yaml"

sub-pages:

-title:Promotion Flows

url:"/promotion-flow"

-title:Promotion Policies

url:"/promotion-policy"

-title:Promotion Workflows

url:"/promotion-workflow"

-title:Customize product promotion settings

url:"/product-promotion-props"

-title:Promotion entity YAMLs

url:"/yaml"

sub-pages:

-title:Product YAML

url:"/product-crd"

-title:Promotion Template YAML

title:"Quick start: Advanced Promotion Flow with Promotion Workflows"

description:"Promote product apps between multiple environments with promotion conditions"

group:gitops-quick-start

toc:true

redirect_from:

-/docs/promotions/promotion-scenarios/policy-multi-env-promotion/

With a Promotion Flow you can[automate promotions across multiple environments]({{site.baseurl}}/docs/gitops-quick-start/multi-env-sequential-flow/).

This quick start explores how to enhance Promotion Flows by configuring conditions for each environment in the flow, ensuring that changes are promoted to environments only on meeting the specific requirements for the environment.

You can automate and enforce gates throughout your promotion processes using Promotion Workflows.

Promotion Workflows are essentially Argo Workflows customized for promoting changes through your environments.

For detailed information, see[Configuring Promotion Workflows]({{site.baseurl}}/docs/promotions/promotion-workflow/).

Promotion Workflows are designed to define the conditions under which changes are promoted to the next environment. They provide a way to automate testing, quality checks, validation, and any other requirements based on your deployment process, establishing gates that control the flow of changes between environments.

You can create workflows tailored to the specific tasks required during a promotion and categorize them based on the stage of the promotion process in which they are executed, as Pre- and Post-Action Workflows.

A Promotion Workflow that runs_before the promotion action is triggered_. These workflows can be used for tasks like smoke tests, unit tests, security scans, or any other validation that must pass before a change is promoted to the next environment.

The Pre-Action Workflow plays a critical role in ensuring that changes meet all necessary requirements before being promoted to the next environment. It acts as the gatekeeper, validating changes and stopping the promotion if any tests or validations fail.

A Promotion Workflow that runs_after the promotion action has completed_. These workflows can be used for tasks like performance monitoring, database migrations, or notifications to inform stakeholders that the promotion is complete.

The Post-Action Workflow allows you to monitor and verify the effects of the promotion after it has taken place. This workflow helps ensure the promoted changes behave as expected in the new environment.

*[GitOps Runtime]({{site.baseurl}}/docs/quick-start/gitops-quick-start/runtime/)

*[Git Source]({{site.baseurl}}/docs/gitops-quick-start/gitops-runtimes/create-git-source/) to store application manifests

*[Environments]({{site.baseurl}}/docs/gitops-quick-start/products/quick-start-gitops-environments/)

For a Promotion Flow, you need at least three environments.

Here we use`dev`,`qa`, and`prod`.

*[Products]({{site.baseurl}}/docs/gitops-quick-start/products/quick-start-product-create/)

*[Applications]({{site.baseurl}}/docs/gitops-quick-start/products/create-app-ui/)

Each environment must have an application for the product.

For example,`demo-trioapp-dev`,`demo-trioapp-qa`, and`demo-trioapp-prod`representing the development, testing, and production versions.

The structure of the repos with the resources accessed by the applications must be consistent across all the three applications.

If it works for you, copy the corresponding subfolders in[demo-applications](https://github.com/codefresh-sandbox/codefresh-quickstart-demo/tree/main/demo-applications) with the resources.<!--- add a link to the repo?-->

*[Promotion Workflows]({{site.baseurl}}/docs/promotions/entities/promotion-workflow/#create-promotion-workflows)

To ensure each environment's specific requirements are met, assign Promotion Workflows to govern promotion behavior.

In this quick start, we’ll define the Promotion Workflows to govern promotion behavior for the`qa` and`prod` environments.

1. From the Promotion Flow list, select the Promotion Flow you created,`multi-env-sequential-promotion` for the quick start.

1. In the Settings panel, update the**Version** to indicate changes in the flow, for example,`2.0`.

1. Assign the workflows by clicking the respective controls and selecting the Promotion Workflows and the Promotion Action from the list.

The example below shows the Pre-Action Workflows available.

{% include

image.html

lightbox="true"

file="/images/quick-start/promotions/quick-start-seq-promo-policy-settings.png"

url="/images/quick-start/promotions/quick-start-seq-promo-policy-settings.png"

alt="Promotions quick start: Pre-Action Workflow to govern promotion behavior for environment"

caption="Promotions quick start: Pre-Action Workflow to govern promotion behavior for environment"

max-width="60%"

%}

{% include

image.html

lightbox="true"

file="/images/quick-start/promotions/quick-start-seq-promo-policy-populated.png"

url="/images/quick-start/promotions/quick-start-seq-promo-policy-populated.png"

alt="Promotions quick start: Target environment configured with Promotion Workflows and Action"

caption="Promotions quick start: Target environment configured with Promotion Workflows and Action"

max-width="60%"

%}

{:start="4"}

1. Repeat_step 3_ to select the Promotion Workflows and Actions for the other target environments in the Promotion Flow.

For this quick start, we'll select the same workflows and the same promotion action for`prod` as we did for`qa`.

Here's the YAML view of the flow with the workflows and promotion actions.

{% include

image.html

lightbox="true"

file="/images/quick-start/promotions/quick-start-seq-promo-policy-yaml.png"

url="/images/quick-start/promotions/quick-start-seq-promo-policy-yaml.png"

alt="Promotions quick start: YAML view of Promotion Flow with Promotion Workflows"

caption="Promotions quick start: YAML view of Promotion Flow with Promotion Workflows"

max-width="60%"

%}

{:start="5"}

1. To save the changes, click**Save Promotion Flow**.

1. Continue with[Trigger Promotion Flow and monitor product release](#trigger-promotion-flow-and-monitor-product-release).

Trigger the Promotion Flow updated with the appropriate Pre- and Post-Action Workflows, and monitor its progress.

The difference between the previous release (without workflows), and this one (with workflows), for the same Promotion Flow (`multi-env-sequential-promotion`), is that changes will only be promoted to the next environment when all workflows associated with the previous environment are complete.

1. Open the Promotion Flow, for example,`multi-env-sequential-promotion` and click**Trigger**.

1. Select the product, the application to promote, and then click**Trigger** once again.

1. Click**View Release Details**.

In the example below, the current release view shows the`qa` and`prod` environments with the Pre- and Post-Action Workflows defined for each environment.

{% include

image.html

lightbox="true"

file="/images/quick-start/promotions/quick-start-seq-promo-policy-release.png"

url="/images/quick-start/promotions/quick-start-seq-promo-policy-release.png"

alt="Promotions quick start: Release view for gated Promotion Flow"

caption="Promotions quick start: Release view for gated Promotion Flow"

max-width="60%"

%}

In the next quick start for promotions, we'll explore how to configure a Promotion Flow with parallel promotions, allowing changes to be promoted simultaneously across multiple environments.

[Quick start: Advanced Promotion Flow: Parallel promotions across environments]({{site.baseurl}}/docs/gitops-quick-start/parallel-multi-env-promotion/)

Now that you’ve mastered the basics, learn more on promotion settings for products and configuring promotion entities.

[Configuring version and promotable properties for products]({{site.baseurl}}/docs/products/promotion-version-properties/)

[Configuring promotion flows and triggers for products]({{site.baseurl}}/docs/products/promotion-flow-triggers/)

Codefresh makes it easy to automate and enforce gates throughout your promotion processes using Promotion Workflows.

Promotion Workflows are essentially Argo Workflows customized for promoting changes through your environments.

For detailed information, see[Configuring Promotion Workflows]({{site.baseurl}}/docs/promotions/entities/promotion-workflow/).

For detailed information, see[Configuring Promotion Workflows]({{site.baseurl}}/docs/promotions/promotion-workflow/).

Promotion Workflows are designed to define the conditions under which changes are promoted to the next environment. They provide a way to automate testing, quality checks, validation, and any other requirements based on your deployment process, establishing gates that control the flow of changes between environments.

*[Create Promotion Workflows]({{site.baseurl}}/docs/promotions/entities/promotion-workflow/#create-promotion-workflows)

*[Create Promotion Workflows]({{site.baseurl}}/docs/promotions/promotion-workflow/#create-promotion-workflows)

*[OAuth2]({{site.baseurl}}/docs/administration/account-user-management/oauth-setup/) authentication applications

* Manifests for promotion entities:

*[Products]({{site.baseurl}}/docs/products/configure-product-settings/)

*[Promotion Workflows]({{site.baseurl}}/docs/promotions/entities/promotion-workflow)

*[Promotion Policies]({{site.baseurl}}/docs/promotions/entities/promotion-policy/)

*[Promotion Flows]({{site.baseurl}}/docs/promotions/entities/promotion-flow/)

*[Promotion Workflows]({{site.baseurl}}/docs/promotions/promotion-workflow)

*[Promotion Policies]({{site.baseurl}}/docs/promotions/promotion-policy/)

*[Promotion Flows]({{site.baseurl}}/docs/promotions/promotion-flow/)

*[Promotion Templates]({{site.baseurl}}/docs/products/configure-product-settings/#configure-promotion-settings)

See[Shared Configuration Repo structure](#shared-configuration-repo-structure).

| Shared Configuration Repo| Description|

| ----------| --------|

|`resources/all-runtimes-all-clusters`| Contains resource manifests applied to all the GitOps Runtimes in the account and to all the clusters managed by those Runtimes. In the above example,`manifest2.yaml` is applied to both`runtime1` and`runtime2`.|

|`resources/all-runtimes-all-clusters/promotion-workflows`| Stores manifests of Promotion Workflows, available to all Runtimes in the account.<br>See[Promotion Workflows]({{site.baseurl}}/docs/promotions/entities/promotion-workflow).|

|`resources/all-runtimes-all-clusters/promotion-workflows`| Stores manifests of Promotion Workflows, available to all Runtimes in the account.<br>See[Promotion Workflows]({{site.baseurl}}/docs/promotions/promotion-workflow).|

|`resources/control-planes`| Optional. When defined, applies every resource manifest to each Runtime’s`in-cluster`. Config map resources for example, when committed to this subdirectory, are deployed to each Runtime’s`in-cluster`.|

|`resources/app-projects`| Contains application project resources which control deployment destinations for applications.|

|`resources/configurations`| Contains platform-level resources which are Runtime-agnostic, essential for functionality related to product and promotion entities in GitOps.|

|`resources/configurations/products`|Contains manifests of product entities. All settings including source location for application version, promotable properties, promotion flows with trigger conditions if defined are saved. Note that applications assigned to products are not saved in the manifest. Product manifests are available to users with the required ABAC permissions. <br>See[Product Settings]({{site.baseurl}}/docs/products/configure-product-settings/) and[Product YAML]({{site.baseurl}}/docs/promotions/entities/yaml/product-crd/).|

|`resources/configurations/promotion-flows`| Contains manifests of promotion flows with the trigger and target environments, and custom promotion policy settings, if any.<br>See[Promotion Flow configuration]({{site.baseurl}}/docs/promotions/entities/promotion-flow/) and[Promotion Flow YAML]({{site.baseurl}}/docs/promotions/entities/yaml/promotion-flow-crd/).|

|`resources/configurations/promotion-policies`| Contains manifests of promotion policies with the Pre- and Post-Action Workflows if defined, the Promotion Action, and target products and environments.<br>See[Promotion Policy configuration]({{site.baseurl}}/docs/promotions/entities/promotion-policy/) and[Promotion Policy YAML]({{site.baseurl}}/docs/promotions/entities/yaml/product-crd/).|

|`resources/configurations/promotion-templates`| Contains manifests of promotion templates defining the sources for the release version and the properties to be promoted. <br>See[Promotion Template configuration]({{site.baseurl}}/docs/products/configure-product-settings/#configure-promotion-settings) and[Promotion Template YAML]({{site.baseurl}}/docs/promotions/entities/yaml/promotion-template-crd/).|

|`resources/configurations/products`|Contains manifests of product entities. All settings including source location for application version, promotable properties, promotion flows with trigger conditions if defined are saved. Note that applications assigned to products are not saved in the manifest. Product manifests are available to users with the required ABAC permissions. <br>See[Product Settings]({{site.baseurl}}/docs/products/configure-product-settings/) and[Product YAML]({{site.baseurl}}/docs/promotions/yaml/product-crd/).|

|`resources/configurations/promotion-flows`| Contains manifests of promotion flows with the trigger and target environments, and custom promotion policy settings, if any.<br>See[Promotion Flow configuration]({{site.baseurl}}/docs/promotions/promotion-flow/) and[Promotion Flow YAML]({{site.baseurl}}/docs/promotions/yaml/promotion-flow-crd/).|

|`resources/configurations/promotion-policies`| Contains manifests of promotion policies with the Pre- and Post-Action Workflows if defined, the Promotion Action, and target products and environments.<br>See[Promotion Policy configuration]({{site.baseurl}}/docs/promotions/promotion-policy/) and[Promotion Policy YAML]({{site.baseurl}}/docs/promotions/yaml/product-crd/).|

|`resources/configurations/promotion-templates`| Contains manifests of promotion templates defining the sources for the release version and the properties to be promoted. <br>See[Promotion Template configuration]({{site.baseurl}}/docs/products/configure-product-settings/#configure-promotion-settings) and[Promotion Template YAML]({{site.baseurl}}/docs/promotions/yaml/promotion-template-crd/).|

|`resources/runtimes/<runtime_name>`| Optional. Runtime-specific subdirectory. Every resource manifest in a runtime-specific subdirectory is applied to only the GitOps Runtime defined by`<runtime_name>`. In the above example,`manifest4.yaml` is applied only to`runtime1`, and`manifest5.yaml` is applied only to`runtime2`.|