Architecture, Azure Pipelines, Diagrams

Azure Pipelines – Architecture Diagrams as Code

Over the past few years I have drawn many Architecture diagrams in a variety of tools like drawio, visio, Lucid Chart, etc. and always found there were many hours spent doing rework and updates.

I generally draw diagrams using the C4 model for detailed architecture but still would have drawn them by hand and totally forgetting about the fact there is a lot of support for building diagrams as code. First time I looked at the C4 model I used code to draw diagrams, so why had I not been using it? to be honest I have no idea why, but it’s definitely time to embrace it again.

If you are not familiar with the C4 model I suggest you checkout the website and I recommend Simon Brown’s books on Software Architecture for Developers, which is available on Leanpub.

Getting Started

So, I recently embarked on creating diagrams as code using the C4 model and Structurizr. First thing is create a free account on Structurizr to get started.

I now needed to decide what to language to use for my diagram as code. Structurizr supports a number of languages for authoring, Java, .NET, TypeScript, PHP, Python, Go and of course its own DSL. I choose the Structurizr DSL for my diagram as it looked easy enough. For editing the code I used Visual Studio Code and an extension for code highlighting by Ciaran Treanor. The DSL demo page and language reference were really helpful to get started as well as the examples.

Building architecture diagrams using the C4 model is great and using the DSL made it easy to build my diagram quite quickly and using the demo page I could see what my diagram was going to look like.

Publish

Having created my diagram as code and added it to source control, I now needed to push my diagram to my Structurizr workspace. Structurizr has a CLI that you can use to do this.

structurizr-cli push -id <my workspace> -key <workspace key> -secret <workspaceSecret> -workspace mydiagram.dsl

The details for the workspace can be found on your Structurizr page by selecting ‘Show more’.

The CLI has other features including exporting to different formats e.g. Mermaid (for more details on the supported outputs see the website)

structurizr export -workspace mydiagram.dsl -format mermaid

Having published my diagram to my workspace, it would be really good to automate this process so any changes to the diagram get pushed.

Currently I am using Azure Pipelines a lot, so it seemed fitting to create this process using Azure Pipelines YAML.

Building the Pipeline

This should be straight forward, I just need to perform the same steps as I did locally to push my diagram to Structurizr.

The build pipeline automatically checkouts my code from my repo so that step is done for me. The Microsoft Build Agents already have HomeBrew installed so that makes installing the CLI simple.

- bash: |
    brew install structurizr-cli
  displayName: 'Install Structurizr'

Pushing to Structurizr needs a number of parameters which should be kept secret so adding them as secure variables in the Pipeline is one solution.

- bash: |
    structurizr-cli push -id $(workspaceId) -key $(workspaceKey) -secret $(workspaceSecret) -workspace $(workspaceFile)
  displayName: 'Push Diagram to Structurizr'

Enhancing the Pipeline

The diagram has been updated in Structurizr but I now usually need images to add to a presentation or documentation. I could go to Structurizr and export the images for each diagram by hand but that takes time and is not helpful is someone else needs them.

Fortunately there are some examples of how to do this using Puppeteer with Structurizr on GitHub which is great and the export of private diagrams worked out of the box with no modification.

The pipeline can be updated now to Install Puppeteer

- bash: |
   npm install puppeteer 
  displayName: 'Install Puppeteer'

And get the example from the Structurizr/Puppeteer repo

- bash: |
    git clone 'https://github.com/structurizr/puppeteer.git'
  displayName: "Get Structurizr Puppeteer"    

Using the example and providing the required details, png files can now be exported.

- bash: |    
    cd $(Build.ArtifactStagingDirectory)
    node $(System.DefaultWorkingDirectory)/puppeteer/export-private-diagrams.js $(workspaceUrl) $(workspaceUsername) $(workspacePassword) png $(workspaceId)
  displayName: 'Export Diagram from Structurizr'

Or svg files.

- bash: |    
    cd $(Build.ArtifactStagingDirectory)
    node $(System.DefaultWorkingDirectory)/puppeteer/export-private-diagrams.js $(workspaceUrl) $(workspaceUsername) $(workspacePassword) svg $(workspaceId)
  displayName: 'Export Diagram from Structurizr'

The images are outputted to the ArtifactStagingDirectory and can now be published as an artifact.

- publish: '$(Build.ArtifactStagingDirectory)'
  displayName: Publish Diagrams
  artifact: 'mydiagrams'

The artifacts will be individual files and so it might be easier to zip them for easier download from Azure Pipelines using the ArchiveFiles task.

 - task: ArchiveFiles@2
   inputs:
      rootFolderOrFile: '$(Build.ArtifactStagingDirectory)'
      archiveFile: '$(Build.ArtifactStagingDirectory)/diagrams.zip' 
 - publish: '$(Build.ArtifactStagingDirectory)/diagrams.zip'
   displayName: Publish Diagrams
   artifact: 'mydiagrams'

Final Pipeline

Putting all that together, my final pipeline looks like this:

trigger: 
- main

pr: none

variables:
  workspaceFile: 'mydiagram.dsl'
  isMain: $[eq(variables['Build.SourceBranch'], 'refs/heads/main')]

jobs:
  - job: UpdateArchitecture
    displayName: Update Architecture
    condition: and(succeeded(), eq(variables.isMain, true))
    pool:
      vmImage: ubuntu-18.04
    steps:
      - bash: |
          brew install structurizr-cli
          brew info structurizr-cli
        displayName: 'Install Structurizr'
      - bash: |
          npm install puppeteer 
        displayName: 'Install Puppeteer'
      - bash: |
          git clone 'https://github.com/structurizr/puppeteer.git'
        displayName: 'Get Structurizr Puppeteer'
      - bash: |
          structurizr-cli push -id $(workspaceId) -key $(workspaceKey) -secret $(workspaceSecret) -workspace $(workspaceFile)
        displayName: 'Push Diagram to Structurizr'
      - bash: |    
          cd $(Build.ArtifactStagingDirectory)
          node $(System.DefaultWorkingDirectory)/puppeteer/export-private-diagrams.js $(workspaceUrl) '$(workspaceUsername)' '$(workspacePassword)' png $(workspaceId)
        displayName: 'Export Diagram from Structurizr'
      - publish: '$(Build.ArtifactStagingDirectory)'
        displayName: Publish Diagrams
        artifact: 'mydiagrams'

Final Thoughts

I started on a journey to automate building architecture diagrams and export the images and this satisfies todays need but in the future I may need to enhance the pipeline to push the images to another system or export them in to another format.

I will certainly be using this article to remind me about diagrams as code, I hope you consider diagrams as code for you own needs and that this has been useful to share.

Happy diagramming.

Azure Pipelines, DevOps, Testing

Azure Pipelines – Running UI Tests on Multiple Agents

When creating a build pipeline one area that seems to get a lot of attention is running UI tests. We want to get feedback as quickly as possible about our code changes.

Test frameworks tend to offer a way of running tests in parallel which is great but what if I want to split tests up over multiple machines and run them in parallel? This isn’t a new problem and there have been many solutions to this, for this article I am going to focus on achieving this in Azure DevOps Pipelines with some .NET code and just using YAML.

UI Tests

I have a project in Visual Studio that contains a basic ASP.NET Core website project and a UI test project using Selenium and NUnit. I deployed the website to Azure ready for the tests to be ran against it.

Azure Pipelines provides a Parallel Strategy, combining that with the VSTest Task will automatically divide up the tests up based on the number of parallel agents.

For this example I am going to use two jobs, one to build the tests and create the output as artifacts and one to download the tests and perform the test run. The second job is configured to run on 5 agents.

The YAML for the pipeline looks like this:

trigger: 
  - master

variables:
  buildConfiguration: Release
  uiTestFolder: 'uitests'

jobs:
- job: BuildTests
  displayName: Build UI Tests
  pool:
    vmImage: windows-latest
  steps:
  - task: DotNetCoreCLI@2
    displayName: Restore Packages
    inputs:
      command: 'restore'
      projects: 'mytests/*.csproj'
  - task: DotNetCoreCLI@2
    displayName: Build Tests
    inputs:
      command: 'build'
      projects: '**/mytests.csproj'
      arguments: '--configuration $(buildConfiguration) -o $(Build.ArtifactStagingDirectory)/$(uiTestFolder)'
  - task: PublishPipelineArtifact@1
    displayName: Upload Library
    inputs:
      targetPath: '$(Build.ArtifactStagingDirectory)/$(uiTestFolder)'
      artifactName: $(uiTestFolder)  
- job: RunTests
  displayName: Run UI Tests
  dependsOn: BuildTests
  pool:
    vmImage: windows-latest
  strategy:
    parallel: 5
  variables:
      siteName: mytest-app
      baseSiteUrl: 'https://$(siteName).azurewebsites.net/'
  steps:
  - checkout: none
  - task: DownloadPipelineArtifact@2
    displayName: Download Tests
    inputs:
      buildType: 'current'
      artifactName: '$(uiTestFolder)'
      targetPath: '$(Pipeline.Workspace)/$(uiTestFolder)'
  - task: FileTransform@2
    displayName: Configure Test Run
    inputs:
      folderPath: '$(Pipeline.Workspace)'
      xmlTransformationRules: ''
      jsonTargetFiles: '**/*settings.json'
  - task: PowerShell@2
    displayName: Check File Substitution
    inputs:
      targetType: 'inline'
      script: 'Get-Content -Path $(Pipeline.Workspace)/$(uiTestFolder)/testsettings.json'
      pwsh: true
  - task: VSTest@2
    displayName: Run UI Tests
    inputs:
      testSelector: 'testAssemblies'
      testAssemblyVer2: |
        **\*tests.dll
        !**\*TestAdapter.dll
        !**\obj\**
      searchFolder: '$(Pipeline.Workspace)/$(uiTestFolder)'
      uiTests: true
      runInParallel: false
      testRunTitle: 'Basic UI Tests'

NOTE: At the time of writing the VSTest Task can only run on the windows agents with either Visual Studio Installed or by using the Visual Studio Test Platform Installer Task.

You might notice that in the VSTest task ‘runInParallel’ is set to false, this is because UI tests can cause issues running in parallel on the same box.

After the test has been ran you can see the results in the Azure DevOps UI. There is the Build UI Tests job and then each Run UI Tests is given a number for each parallel run on a different agent.

NOTE: the number of parallel jobs depend on the amount of agents you can run in your parallel in your Azure DevOps configuration and the number of available agents when the job runs.

Conclusion

Using the VSTest task and parallel strategy is a very simple way to get UI tests to run on multiple agents with a .NET project.

I found my example didn’t really offer much gain in terms of time but I only had 14 UI tests and just using one agent performed better than multiple agents. I expect the gains would be seen with a large test suite, I would suggest trying the test runs with different numbers of agents to see what works best for your tests. You might also gain benefits running the UI tests on your own agents.

Additional Information