sfops - On Push to Branch

The below sections details the workflow that get triggered on a push to the main and release/* branches

name: 'sfops - On Push to Branch'


on:
  push:
    branches:
      - 'main'
      - 'release/**'

  workflow_dispatch:



#Set the environment variables for tracking metrics
env:
  SFPOWERSCRIPTS_DATADOG: 'true'
  SFPOWERSCRIPTS_DATADOG_HOST: '${{ secrets.DATADOG_HOST }}'
  SFPOWERSCRIPTS_DATADOG_API_KEY: '${{ secrets.DATADOG_API_KEY }}'


jobs:
   build-test-publish:
    name: 'Build & Publish'
    uses:   flxbl-io/sfops-gh-actions/.github/workflows/push-to-branch.yml@main
    with:
       releaseconfig: 'config'
       branchname: ${{ github.ref_name }}
       pathToReleaseConfigs: 'config'
       dashboard-repo: ${{ vars.SFOPS_DASBHOARD_REPO }}
       releasename: ${{ vars.RELEASENAME }}
       metrics-provider:  ${{ vars.SFOPS_METRICS_PROVIDER }}
       workitem-url: ${{ vars.SFOPS_ISSUETRACKER_URL }}
       workitem-filter:  ${{ vars.SFOPS_ISSUETRACKER_WORKITEM_FILTER }}
       sfopsbot-app-id: ${{ vars.SFOPSBOT_APP_ID }}
    secrets:
      DEVHUB_SFDX_AUTH_URL: ${{ secrets.DEVHUB_SFDX_AUTH_URL }}
      SB_SFDX_AUTH_URL: ${{ secrets.SB_SFDX_AUTH_URL }}
      DATADOG_API_KEY: ${{ secrets.DATADOG_API_KEY }}
      DATADOG_HOST: ${{ secrets.DATADOG_HOST }}
      SFOPSBOT_APP_PRIVATE_KEY: ${{ secrets.SFOPSBOT_APP_PRIVATE_KEY }}
      NPM_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Within an individual build-deploy-publish cycle, the following happens in sequence

1. Impacted packages are detected and queued for build

2. Upon successful completion of the build, the packages that are created are deployed in parallel to a dynamic list of deployment targets. These deployment targets form your test environments

3. If all the deployment targets succeeded, the packages are published and a release candidate is created for the corresponding domain

There could be 0..N deployment targets, and these deployment targets are marked by the filter "type:test, branch:<current_branch>", If no deployment targets , the process is skipped and moved to publish. The deployment targets could be dynamic or static

One then could determine, after further testing whether the release candidate created (upon publish) can be promoted to production or rejected. Though this workflow assumes the following - Any manual pre steps have to be undertaken before the change is merged to trunk, - The pipeline only deals with deploying to environments and doesnt consider the time spend in tesing and the testing approach in general - You must manually orchestrate or block other merges from being pushed to these environments while testing is underway. (sfops has a more stringent deploy from branch model, which would deploy a feature branch to test environments, before it can be merged to trunk) As you must have noticed, these tests are more quality gates. Tests such as User Acceptance Testing should be carried out before the work item is merged to the branch. If any bugs are discovered at this stage, these should be fixed in priority or the feature should be toggled off or excluded from release candidate for further promotion.