Vega Release Cycle

vega-release-cycle-chart

Pre-release Phases

Grooming Phase

In the grooming phase we consume input from Vega Clients, Vega Quality Assurance (QA) specialists, Vega Designers, and Vega Developers. We then groom them into the task queue. Based on the story category, we prioritize tasks in the following order:

  1. Critical issues (Bugs reported by clients, release blockers/regressions found by QA specialists).
  2. Feature requests from clients.
  3. New components designed by Vega Designers not yet required by clients.
  4. QA-reported issues
  5. Improvements raised by Vega Developers (Code Refactoring, Functionality, Re-design, etc.)

Tasks in the queue are triaged by Vega developers after prioritization. For issues with the same priority, we introduce these in First-in-first-out (FIFO) order.

Drafting Phase

Once a story is picked up by Vega developers, at least one merge request must be created before code change commits. Before the merge request can be merged into the main branch, several requirements must be met:

  1. Code review with checklist below:
    • Verification of feature requirements
    • Code readability
    • Code style (design patterns)
    • Clear naming
    • Code duplications
    • Test coverage
    • Documentation
  2. Pipeline verification, which covers:
    • Passing all tests
    • Testing that coverage meets requirements
    • Code linting pass
    • Package must compile and build without errors.
  3. QA sign off ensures:
    1. The code change reaches the story acceptance criteria

      Acceptance Criteria Definition: Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder. (via Microsoft Press)

    2. No regressions found in the component scope

Merging Phase

After merging code to the main branch, we deploy to Storybook with the latest version of Vega for demonstration purpose, including:

  1. Storybook entry for each component
  2. Storybook entry for demo sites built with Vega components

Before publishing the package based on a weekly schedule, Vega QAs will conduct a final round of testing for all commits since the last published version through:

  1. Verification in Storybook page.
  2. Verification in client application sandbox environment.

    Note: this is a short term solution to gain more confidence in successfully delivering results to the current partner clients. We will deprecate this step after Vega becomes stable.

Publishing Phase

In the publishing phase, we publish the Vega packages to the npm registry and send out a notification to clients.

Release Criteria

Given the above workflow within the Vega Release Cycle, we guarantee that the vega package is well tested at the following levels before publishing:

  1. Unit Testing (UT) - Functionality Module Design (Done in “Drafting Phase - Pipeline verification”)
  2. Component Integration Testing - Architecture Design (Done in “Drafting Phase - Pipeline verification”):
    • Component E2E workflow tests for the functionality must be tested within a browser context instead of in UT.
    • Component visual regression tests
    • Component a11y tests with standard wcag2a, wcag2aa, wcag21a, wcag21aa
  3. Story Acceptance Test - Requirements Design (Done in “Drafting Phase - QA Sign Off”)
  4. System Integration Test - System Design (Done in “Merging Phase - QA Sign Off”)

    Note: For all issues found before the publishing phase, we require developerss to add corresponding test cases in order to avoid duplicating the manual testing efforts from QA side.