Blog

Why This Example of CI in .NET?

1. .NET is not easily configured to do discrete CI steps that use intermediate product from the previous steps, and documentation can be misleading or even lacking
2. Developing and debugging pipeline yaml is still more of a brute-force, try, try again effort rather than a sophisticated, efficient effort
3. Validating that the pipeline jobs and steps do the intended in terms of efficient use of resources is not always at the forefront of CI approaches — sometimes, it’s “It works!” meaning the intended product is generated
4. Visibility into pipeline metrics such as storage consumption or duration of pipeline can be missing

Example Scope vs “Real World”

• This example’s workflow covers only a trigger of a basic push to the GitHub repository.
  • For a live system, we would likely to have story, master, and release branches as well as merge request to take into account in our plan
• This approach does not emulate a complex repo of multiple subsystems but can be adapted for such
• Caching and artifacts are included as examples of better practices
  • Generally, for a simple project with few dependencies, caching and artifacts may not be worth the network load or worth maintaining a more complex yaml — depending on your CI optimization goals
• For real systems, take an additional step of deploying the app to a testing environment where other apps live, to test how the app plays well with others
  • If possible, automate this automated as part of the CI as systems-level testing (aka integration testing)
• This approach covers only CI, not CD; a later post will cover deployment

GitHub Actions Workflow Yaml

While this example uses GitHub Actions workflow, you can adapt the approach to other CI tools.

Matching the diagram above, the yaml shows the CI approach used. Before we discuss CI stages, let’s take a look at how the yaml starts.

name: LabDemo.MinimalApi.BuildByStages
run-name: ${{ github.actor }} is experimenting with GitHub actions 🚀
on: [push]

env:    
    PROJECT: LabDemo.MinimalApi
    TEST_PROJECT: LabDemo.MinimalApi.Tests
    BUILD_ARTIFACT_NAME: build
    PUBLISH_ARTIFACT_NAME: publish
    BUILD_PATH: build
    PUBLISH_PATH: publish

jobs:

First, on push. On line 3 the workflow runs whenever a push to the repository happens.

• This demo app’s CI has no special use cases for pull requests or branches.

Second, workflow-global variables. On line 5 we establish environment variables.

• Ensures consistency in the workflow
• Makes the yaml less error-prone
• Makes reuse of this yaml for another project much easier.

Important Caveat About Caching

The following applies to GitHub Actions. For other tools, the caching may work differently. Think it through.

You must use the cache action in your workflow before you need to use the files that might be restored from the cache. If the provided key matches an existing cache, a new cache is not created and if the provided key doesn’t match an existing cache, a new cache is automatically created provided the job completes successfully. — GitHub Actions Cache README