Examples

Use these sample YAML files as boilerplate to get started with your workflows.

circle-exclamation

Pull Request

This pipeline (pr-pipeline.yml) is invoked whenever you create or update a Pull Request (PR). Its purpose is to test that each of the added or updated PowerOns are valid.

trigger: none # This pipeline is triggered by pull requests via Branch Policies

# Dynamic variable group selection based on target branch
# PRs to main use prod credentials, PRs to stage use stage credentials, all others use dev
variables:
  - ${{ if eq(variables['System.PullRequest.TargetBranch'], 'refs/heads/main') }}:
    - group: symitar-prod
  - ${{ elseif eq(variables['System.PullRequest.TargetBranch'], 'refs/heads/stage') }}:
    - group: symitar-stage
  - ${{ else }}:
    - group: symitar-dev

pool:
  name: ci-symitar

workspace:
  clean: all

steps:
- checkout: self
  fetchDepth: 0
  # In the PR context, this will only validate changes between target and source branches
- task: ValidatePowerOn@1
  displayName: 'Validate changed PowerOn files'
  inputs:
    connectionType: ssh
    apiKey: $(apiKey)
    symitarHostname: $(symitarHostname)
    sshUsername: $(sshUsername)
    sshPassword: $(sshPassword)
    symitarUserNumber: $(symitarUserNumber)
    symitarUserPassword: $(symitarUserPassword)

Merge Request

This pipeline (merge-pipeline.yml) is automatically invoked when PRs are merged to either main or stage branches and will do two things:

Validate Changed PowerOns

This is done by comparing the PR content relative to the target branch.

Prepare an Artifact

This will be referenced as "point in time" data to synchronize the Symitar host with during the release process

Release

This pipeline (release-pipeline.yml) is automatically invoked at the successful completion of our symitar-merge build pipeline which is just pointing to the merge-pipeline.yml file above. You'll notice it only triggers on main branch, since this pipeline includes both Stage and Prod deployments.

This pipeline has a bit more to it but can be split up in the following way:

Stage Validation -> Stage Deployment

All that you need to know here is that we're effectively doing the exact same thing only the *Validation stage is executing the SynchronizeDirectory task with isDryRun set to true so that we can visualize the prescribed changes prior to deployment and get any approvals necessary along the way.

Prod Validation -> Prod Deployment

For this section, we're doing the same work but for a different environment, Prod.

Last updated