Skip to main content

Automated Deployment Flow

Yalla works best using the continuous delivery model, where changes are released to live environments immediately after code changes. Yalla offers an automated deployment flow which can be defined in your platform.yaml file.

project:
  deployment_flow:
    - phase: 1
      env_name: "staging"
    - phase: 2
      env_name: "production"

Then, at the end of your CI pipeline, you can invoke the Yalla CLI to create a new deployment for your application, specifying the container image and version to deploy.

Yalla will then promote this image to the first environment in your deployment flow, and will continue promoting all the way to production provided the deployment passes health probes and readiness checks.

Getting Started​

To integrate a deployment flow into your Azure DevOps pipeline, follow the guidance in the deployments documentation: Automated Deployment through ADO Pipeline (Preferred)

Allowing Repositories to Trigger Deployments​

To ensure that only approved repositories that trigger pipelines that use the Yalla CLI to create a deployment are allowed to do so you can use the allowed_deploy_repos key under project to define a list of ADO repository URLs. For example:

project:
  name: myplatform
  description: my test platform
  allowed_deploy_repos:
    - https://dev.azure.com/bp-digital/DevOps-SRE/_git/accelerate-monorepo
    - https://dev.azure.com/bp-digital/DevOps-SRE/_git/yalla-infra-catalogue
  deployment_flow:
    - phase: 1
      env_name: "staging"
    - phase: 2
      env_name: "production"

This would mean that only build pipelines triggered by either of the two repositories listed could yalla deployment create... a deployment for this platform.

Adding approval gates for Production​

Some teams may want to manually validate their changes before they are released into production. To do this, we recommend configuring the "Admin" group as approvers for the production environment.

This can be done in the deployment_flow section of platform.yaml. Individual users are not supported in this list as it would require them to approve every deployment, which could be problematic if people are away. If in doubt, keep your admin group to a small list of trusted approvers.

project:
  name: playground
  description: Playground project for testing
  access:
    admins:
      - user.one@bp.com
      - user.two@bp.com
  deployment_flow:
  - phase: 1
    env_name: staging
  - phase: 2
    env_name: production
    approvers: # Admins from above will be required approvers for production.
    - Admin

Once configured, pull requests for production will require an additional reviewer before they can be merged.