Skip to main content

Development Workflow

Rizing development uses a release branching model, with advancements to environments happening automatically after Pull Requests are merged. See Branching Model for more details on branching.

Branching model

Release model

Workflow Steps​

Release branch​

  1. A new release branch is created to initiate work for an active release.

    ex: release/omni/v1.0.0

Feature branches​

  1. Feature branches are created off of the release branch to do work

    ex: omni/russell.green/1234-updating-user-guide

  2. Once feature branches are completed, a Pull Request is made

    [feature branch] ---> [release branch]

Quality Assurance​

  1. The PR pipeline will automatically create a sandboxed DEV environment site for testing
  2. Testers will test the "sandbox" site and approve the PR once acceptance criteria is met
  3. Technical reviewers will review the code and approve based on technical standards being met (see Coding Standards)

    Required approvals are enforced via ADO branch policies

  4. Once all approvers approve the PR, it will get merged
  5. The PR merge will automatically deploy the merged code (release branch) to the release site

    ex: https://omni-v1-0-0.rizing.dev

  6. This process will repeat for all features/bugs in this release

Regression Testing​

  1. Regression testing (testing the combined feature branches together) can occur on the release branch at anytime

Generate Release​

  1. Once a version is ready to be released, a PR will be created to merge the release branch into the main branch

    ex: [release/omni/v1.0.0] ---> [main]

  2. The release branch will be tested against the release testing branch (plus any other testing)
  3. Once all testing is done and minimum approvals have been met, the PR will be merged

Production Deployment​

  1. Upon PR merging from release branch to main, a pipeline will automatically deploy the application to the production environment

Workflows​

General Deployment Workflow​

Deployments, to all environments, should be automated (where possible), repeatable, and restricted based on Azure DevOps policies. Each product may differ on the exact deployment targets and strategies, however, the general principles should be applied globally. Below is a typical application deployment workflow for a containerized application.

Workflow Diagram

PR Workflow​

All changes to the source code must be made through a Pull Request. The Pull Request provides an opportunity for the code to be reviewed, tested, and verified before ever making it into the stable code base (and ultimately a release). See Pull Requests for more details.

PR workflow diagram source

Workflow​

References​