Skip to content

SSW Rules - Dashboard Build Widget #445

@piers-sinclair

Description

@piers-sinclair

@wicksipedia @william-liebenberg @bradystroud @JackLeerson @SebastienBoissiere

On Azure DevOps we have both SSW Rules and SSW Rules Content building in the production pipeline. The SSW Rules website builds take much longer than SSW Rules Content changes. We need to be able to visualize these changes so that abnormalities in build times are easily spotted.

image
Figure: From https://github.com/SSWConsulting/SSW.Rules/blob/main/_docs/images/DevOps%20Release%20Management%20Architecture.png

image
Figure: The production build times – We could move this functionality to GitHub Actions

Based on my research, to address this issue we have 4 options:

Option # 1 Migrate the CI/CD process to GitHub Actions (recommended)

a) Using GitHub actions would allow us to filter the workflow triggers by event type. SSW Rules Content would trigger the workflow via a repository dispatch event as per https://github.community/t/trigger-a-workflow-from-another-workflow/17395 while the website would trigger it via a push/pull request event. This means that we could filter the builds to show only content builds or only website builds.

image
Figure: How to filter by event type

b) This solution is recommended because we plan to migrate everything to GitHub anyway.
c) One potential problem with this solution is that examining workflow run times is in a list rather than a graph.

Option # 2 Do nothing

a) It may not be worth fixing this issue because it will not be a trivial task

Option # 3 Create a PowerBI report to visualize the problem

a) This method allows for visualization of the issue without affecting how the current pipelines work.

Option # 4 Create a separate build pipeline for SSW Rules Content in Azure DevOps (not recommended)

a) This option is the only way to accomplish this completely in Azure DevOps but it is not recommended because it will make the deployment process confusing and inconsistent. For example, it will not be clear what the most recently deployed build is.

Course of Action

As per my conversation with @adamcogan ,

  1. Action # 3 for now and once we have one month of data if it still makes sense then Action # 1

AB#60889

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions