Skip to content

Latest commit

 

History

History
166 lines (126 loc) · 7.18 KB

README.md

File metadata and controls

166 lines (126 loc) · 7.18 KB

Maestro

Dependency update flow

The following diagram shows how a dependency update PR progresses from opening to merging. The flow is triggered when a subscription is triggered by a user or on a schedule.

flowchart
    SubscriptionTrigger(Subscription is triggered)
    Exist{Does a PR\nalready exist?}
    State{What state\nis the PR in?}
    PolicyState{What state\nare the check\npolicies in?}
    Create(Create a new PR)
    CleanUp((Clean up\nbranch))
    TagPeople(Notify/tag people)
    UpdatePR(Update PR,\nif possible)
    MergePR(Merge PR)
    UpdateLastBuild((Update\nLastAppliedBuild\nin BAR))
    Timer(Periodic timer)

    Exist--Yes-->State
    Exist--No -->Create
    SubscriptionTrigger-->Exist

    State--Open-->PolicyState
    State--Merged-->UpdateLastBuild
    State--Closed-->CleanUp

    PolicyState--Checks OK-->MergePR
    MergePR-->UpdateLastBuild
    PolicyState--Failed checks-->TagPeople
    TagPeople-->UpdatePR
    %% Cannot update
    PolicyState--Pending policies-->Timer
    %% Can update
    PolicyState--Conflict-->UpdatePR
    Timer--Check PR-->State
    Create--Set timer-->Timer
    UpdatePR--Set timer-->Timer

subgraph Legend
    MaestroAction(Action)
    ExternalImpulse(Trigger)
    EndOfFlow((End of flow))
end

classDef Action fill:#00DD00,stroke:#006600,stroke-width:1px,color:#006600
classDef End fill:#9999EE,stroke:#0000AA,stroke-width:1px,color:#0000AA
classDef External fill:#FFEE00,stroke:#FF9900,stroke-width:1px,color:#666600
class Create,TagPeople,NoAction,UpdatePR,MergePR,MaestroAction Action
class UpdateLastBuild,CleanUp,EndOfFlow End
class SubscriptionTrigger,Timer,ExternalImpulse External
linkStyle 2,12 stroke-width:2px,fill:none,stroke:#FFEE00,color:#FF9900
Loading

The above flow only applies to the usual dependency flow updates (version files, etc.). The flow works a little bit different for the code-enabled subscriptions that flow code between product repos and the VMR. For those, the PR branch is created by the Product Construction Service.

flowchart
    SubscriptionTrigger(Code-enabled\nsubscription triggered)
    PRExists{Does a PR\nalready exist?}
    BranchExists{Does a branch\n exist?}
    CreatePR(Create a new PR)
    PRState{What state\nis the PR in?}
    CleanUp((Clean up\nbranch))
    TagPeople(Notify/tag people)
    UpdatePR(Call to PCS\nUpdate branch)
    MergePR(Merge PR)
    Timer(Periodic timer)
    CreateBranch(Call to PCS:\nRequest PR branch)
    PolicyState{What state\nare the check\npolicies in?}
    UpdateLastBuild((Update\nLastAppliedBuild\nin BAR,\nclean up branch))

    SubscriptionTrigger-->PRExists
    PRExists--No -->BranchExists
    PRExists--Yes-->PRState
    BranchExists--Yes-->CreatePR
    BranchExists--No -->CreateBranch
    CreateBranch--PCS pushes a branch,\ntriggers the subscription-->SubscriptionTrigger

    PRState--Open-->PolicyState
    PRState--Merged-->UpdateLastBuild
    PRState--Closed-->CleanUp

    PolicyState--Checks OK-->MergePR
    MergePR-->UpdateLastBuild
    PolicyState--Failed checks-->TagPeople
    TagPeople-->Timer
    %% Cannot update
    PolicyState--Not updatable PR\npending policies, conflicts.. -->Timer
    %% Can update
    Timer--Check PR-->PRState
    CreatePR--Set timer-->Timer
    UpdatePR--Set timer-->Timer

subgraph Legend
    MaestroAction(Action)
    ExternalAction(External call)
    ExternalImpulse(Trigger)
    EndOfFlow((End of flow))
end

classDef Action fill:#00DD00,stroke:#006600,stroke-width:1px,color:#006600
classDef End fill:#9999EE,stroke:#0000AA,stroke-width:1px,color:#0000AA
classDef External fill:#FFEE00,stroke:#FF9900,stroke-width:1px,color:#666600
classDef PCSCall fill:#DD0000,stroke:#660000,stroke-width:1px,color:#ffffff

class CreatePR,TagPeople,NoAction,MergePR,MaestroAction Action
class UpdateLastBuild,CleanUp,EndOfFlow End
class SubscriptionTrigger,Timer,ExternalImpulse,PCSFinished External
class CreateBranch,UpdatePR,ExternalAction PCSCall
Loading

Validation Process in dev and int environments

For any non-deployment code changes, the expectation is to have run the tests corresponding to the service locally to confirm that the change works before putting up the PR. The tests for each of the major areas in arcade-services are as below:

For any deployment changes, the only way to test would be to kick off the build pipeline that deploys the intended service from the dev branch to staging / int environment.

⚠️ 😓 💥

This comes with a significant overhead of a possibility of leaving the int deployments in a broken or non-responsive state, which then would require significant manual effort to undo the damage especially with the Service Fabric Clusters. This process should only be done if and only if absolutely necessary and after obtaining management approval.

Steps:

  • Run the arcade-official-ci pipeline (based on azure-pipelines.yml) from your dev branch.

  • Once the testing is done, rerun the pipeline for main branch to return the deployment to a last known good.

BARViz Best Practices

How to Understand the State of a Build and Channel

Each of the links on the left side bar represent a channel for a product. Clicking on one of these links will load the current build state for a channel.

The two main states of a channel’s current build are as follows:

  • ✅ Current build is good.

  • ⚠️ There are issues with this build. The message at the top of the build's page will give you more information as to the issue, but most likely is one of the following issues:

    • The repository is not running the latest version of the Arcade toolset. Older versions of the Arcade toolset are incompatible with determining the state of the build.
    • Latest builds are failing

While looking at a build, you may notice highlighted (in yellow) dependencies. These denote the dependencies that are an older version than another of the same dependency used in the build. This should help the teams to identify issues with dependency coherency within a build.

When mousing over a dependency, you may notice icons that show up along the left-hand side of the list. The icon at the top of the column provides help for understanding these icons. These icons are to assist in understanding the hierarchy of the dependency graph and to point out conflicting dependencies within the build.

How to Understand Versions and Hashes Used for a Build

The number at the top of the build's page, next to the URL for the repository, is the current build number of the repository. The link of the hash below the URL will take you to the AzDO repository and the hash referenced so that the user can see all the commits that are a part of the latest build.

Similarly, each dependency denotes the version of that dependency used and a link to the hash of the latest commit that was contained in the build.

How to Onboard a New Repository

If you would like to see your repository on BARViz, it needs to be published to the Build Asset Registry. Please see the Darc documentation.