Automated Deployment through ADO Pipeline (Preferred)

Since Yalla is underpinned by ArgoCD, a popular declarative gitops continuous delivery tool for Kubernetes, deployments of new artifact versions is effected through changes to files in git repositories. To achieve this Yalla supports two methods: using the Yalla CLI and using the Yalla provided ADO pipeline tasks (which uses the CLI under the covers). The latter is the Yalla recommended method for a fully automated deployment model.

Yalla CLI

$ yalla deployment create --help
Create a deployment
Usage:
  yalla deployment create [flags]
Flags:
      --client-secret string     Client secret for authentication
      --commit-uri string        URI of the commit associated with the change
      --deployments-url string   URL for the deployments service (default "https://deployments.internal.accelerate-prod.bpaws.com")
      --enable-deployments-v2    Use the new deployments service (beta testing)
      --environment string       Environment to deploy to (e.g., dev, staging, prod)
  -h, --help                     help for create
      --pat string               Personal access token to connect to Azure DevOps APIs
      --platform string          Name of the federated platform the service belongs to (leave empty for multi-tenant)
      --product string           Name of the Yalla product the service belongs to
      --service string           Name of the service
      --version string           URI of the artifact to be deployed

Once the CLI is installed you can use the deployment create command to create a new deployment for a service instance (an instance of a service under a product within a platform deployed to a specific environment).

If no cached oauth token exists locally you will be asked to authenticate in the usual way (via a browser login page). Whilst the cached token remains valid (usually 60 minutes) you should be able to create more deployments without further authentication.

The default deployment artifact type is container. Use --type helm to specify a helm chart deployment.

The version should be the full artifact URI so in the case of a container it should be registry/repository/image:tag and for a helm chart chartname:version (just the chart name and version, not the repository/registry).

Your helm chart overrides (which allow specification of a custom deployment_chart) should be in your environment based values.yaml and not service.yaml. Both work but only the former is supported by the Yalla automated deployment flow.

Container example:

$ yalla deployment create \
    --platform foo \
    --product bar \
    --service baz \
    --version dml.bpglobal.com/my-repository/my-image:1.0.0 \
    --commit-uri "https://dev.azure.com/bp-digital/DevOps-SRE/_git/my-repo/commit/0123456789abcdef"

Helm example:

$ yalla deployment create \
    --platform accelerate \
    --product accelerate \
    --service wicksy \
    --version yalla-app:0.20.23 \
    --commit-uri "https://dev.azure.com/bp-digital/DevOps-SRE/_git/yalla-infra-catalogue/commit/b4ae682e" \
    --type helm

Yalla ADO Pipeline Task

The CreateYallaDeployments ADO task is essentially a wrapper around the Yalla CLI, and is the recommended way of managing deployments.

It can be called once your image has been built, scanned and pushed to DML (which the CreateYallaBuildPush task can assist with).

This simple example demonstrates using these tasks to build, push and deploy a docker image. A full working example pipeline is available in the Yalla monorepo.

pool:
  name: GenericPoolLinux-SS
steps:
  # Build and push the image to artifactory
  - task: CreateYallaBuildPush@1
    displayName: Scan & Push
    name: BuildAndPush
    inputs:
      ApplicationPackageID: SPKG0000001
      BuildImage: true
      DockerFilePath: ./Dockerfile
      ImageRepository: my-project-image-repo
      ImageTags: my-image:$(Build.BuildId)
      JFrogServiceConnection: BP_JFrog_Artifactory_V2
      WizServiceConnection: BP_CWPP_SECURITY_GC
      WizProjectId: 6430bc9a-29c4-505f-9e8b-fdc5d661c903
      WizScanTags: |
        spkg=SPKG0000001
        source=AzureDevOps
  # deploy the updated image to Yalla
  - task: CreateYallaDeployments@1
    displayName: Yalla Deployment
    inputs:
      YallaProduct: yalla
      Deployments: |
        my-service,$(BuildAndPush.PublishedImages)
      YallaDeploymentConnection: YALLA_DEPLOYMENT_SHARED

To allow your pipeline(s) to create a deployment for your platform you should add a list of repositories that trigger pipelines that are allowed to do this by following Allowing Repositories to Trigger Deployments

Adding Digital Change integration to your pipeline

If you want to integrate with the ServiceNow Digital Change API as part of your pipeline, you can make use of bp's ADO extension for ServiceNow.

The Yalla deployment template is currently asynchronous, meaning that your change request may finish as "Closed - Successful" even if an underlying deployment fails. Future work to integrate Digital Change natively into Yalla will address this.

Creating a Change Request Template

To start, you will need to create a ServiceNow Change Request template for your IT Service. It will then be approved by someone on the ServiceNow Change team.

Creating a service connection to ServiceNow in Azure DevOps

Next, you will need to create an Azure App Registration and request access to the ServiceNow REST API. Then create a service connection of the "BP ServiceNow" type in your ADO project with the details of your app registration, selecting OAuth for the auth method.

Pipeline Example

The following is an example of a pipeline that will:

• raise the CR in SNOW
• progress the CR to "Implement"
• deploy to Yalla
• close the CR

      - job: CreateCR
        displayName: "Create and Implement CR in ServiceNow"
        pool: "GenericPoolLinux-SS"
        timeoutInMinutes: 10
        dependsOn:
          - BuildAndTest
        steps:
          - task: snow-change@5
            displayName: "Create CR"
            name: createRequest
            inputs:
              ServiceNowEndpoint: 'AccelerateDigitalChangeAPI'
              TemplateName: 'Standard Change Template for Accelerate Automated Releases'
              Requester: '$(Build.RequestedForEmail)'
              Approver: 'liam.bennett@bp.com'
              WorkItems: '$(System.TeamFoundationCollectionUri)$(System.TeamProject)/_build/results?buildId=$(Build.BuildId)'
          - script: |
              echo "##vso[task.setvariable variable=changeNumber;isOutput=true]$(createRequest.number)"
            name: changeNumber
            displayName: Export CR Number
          - task: snow-change@5
            displayName: 'Implement CR'
            inputs:
              ServiceNowEndpoint: 'AccelerateDigitalChangeAPI'
              State: 'Implement'
              ChangeRecordId: '$(createRequest.number)'
      - task: CreateYallaDeployments@1
        displayName: Yalla Deployment
        inputs:
          YallaProduct: yalla
          Deployments: |
            my-service,$(BuildAndPush.PublishedImages)
          YallaDeploymentConnection: YALLA_DEPLOYMENT_SHARED
      - job: CloseCR
        displayName: "Close CR in ServiceNow"
        pool: "GenericPoolLinux-SS"
        timeoutInMinutes: 10
        dependsOn:
          - CreateCR
          - YallaDeploymentsInit
          - Deploy
        steps:
          - task: snow-change@5
            displayName: "Close CR"
            inputs:
              ServiceNowEndpoint: 'AccelerateDigitalChangeAPI'
              ChangeRecordId: '$(changeRequest)'
              State: 'Close'
              ApplicationVersion: '$(Build.BuildNumber)'
              ChangeStatusFrom: 'stage'
            condition: always()

Next Steps

Next, you should get familiar with Yalla Monitoring & Observability