Guidance on splitting the build and deploy phases

[aaronpowell]

When you run azd deploy it will perform a build of the project that you're trying to deploy, but from a CI/CD perspective, this can make it opaque as to which point an error occurred or prevent you from placing a gate in the pipeline to prevent excessive deployments. Essentially, so you could do this:

flowchart LR
  Build --> Provision --> Deploy

Loading

This way, if there is a failure in the Build phase, say a compilation error, you won't run the Provision or Deploy phases, reducing the feedback cycle. Additionally, you could inject more parallel phases before Provision, such as running tests, performing linting, etc.

It would be good if there was some guidance on what the approach should be on how you would split the two phases apart so there's a clear step in the pipeline file for each phase.

This will also make it easier to have reusable build assets (such as container images) that get migrated between environments, without a rebuild.

[tonybaloney]

I've split the workflows for the template I'm working on into 2 actions files.

The first runs on commits to main and pull-requests

flowchart LR
  Build --> Test --> Merge

Loading

The main branch is protected and requires this workflow to pass to merge.

name: Validate application
on:
  workflow_dispatch:
  push:
    branches:
      - main
      - master
  pull_request:
    branches:
      - main
      - master

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Azure CLI script
        uses: azure/CLI@v1
        with:
          inlineScript: az bicep build -f infra/main.bicep

 //    ... test and lint my application

Then the deployment flow works off main only and does the remaining steps.

flowchart LR
 Commit --> Provision --> Deploy

Loading

The latest update to azd will set the auto-generated actions file to only run on main/master.

The biggest downside so far is that if someone force-pushes to the main branch it'll deploy without having tested.

[aaronpowell]

But that still won't necessarily address the workflow of approve release to environment X, unless you're expecting that the main branch workflow is really just dump in what it's doing.

Take this workflow for example: https://github.com/aaronpowell/httpstatus/blob/main/.github/workflows/main.yaml

There are two jobs, build-images and deploy-azure. In the first phase, it'll generate a container image and publish it to GH Packages and ACR, then it requires a manual approval to "release" that container image to the AppService that the site runs on. This just gives an additional final approval before something is published to production.

Another example is the workflow here: https://github.com/aaronpowell/azure-remix-stack/blob/v2/.github/workflows/deploy.yml

In this one, there's a few parallel jobs, linting, type checking, unit testing, headless browser testing and (ideally) compilation. Once all five jobs have passed, we can then provision the infrastructure, then finally take the output of the compilation step and package it for an Azure deployment.

Now yes, we can create additional workflows, protect branches based on workflow outcomes, create custom jobs, etc. but that's why I've raised the discussion the guidance, with azd simplifying the developer workflow, what's the best way to support fine control over the CI/CD aspect of it.