BETA Release config and process

[blackfalcon]

BETA Release config and process

Problem

The current build and release process, designed for environments supporting rapid continuous delivery and deployment, has become a challenge for Auro as it has matured. Instead of providing an advantage, it has turned into a distraction.

Teams have expressed concerns about the frequent release of updates that are incompatible with other component versions and insufficient regression testing. Additionally, there is feedback that rapid updates cause issues for development teams that typically review dependencies only quarterly.

To address these issues, the team created a Release Candidate (RC) process to bundle multiple updates into a single release. However, the constraints of this RC development process necessitated releasing updates before they were fully tested. Furthermore, updates in an RC were unusable until the entire feature set was officially released.

Recommendation

To resolve these issues, we recommend a two-part solution: revive the previous RC development process and implement a new BETA package release process.

1. Revive and Enhance the RC Process:

   • Reinstate the RC development process to bundle updates and deploy them in a single release.
   • Ensure updates are thoroughly tested before being released from the RC.

2. Implement a BETA Package Release Process:

   • Introduce a permanent beta branch alongside the main branch in the repository.
   • As new code is merged into the beta branch, the Semantic Release process will generate a new BETA versioned release.

BETA releases will be clearly communicated to the organization as preliminary versions that may contain issues. These versions will be labeled as "use at your own risk" until fully tested and deemed ready for official release.

Development teams will be encouraged to use BETA versions with the understanding that there may be issues or compatibility concerns with other Auro components.

This proposed BETA process will include the following updates:

• Clear documentation and communication regarding the nature and purpose of BETA releases.
• Encouragement for teams to test BETA versions in their environments to identify and report issues early.
• A structured feedback mechanism to address and resolve any problems identified in BETA releases before official deployment.

Auro Doc Site page

There is to be a new page added to the doc site for developer education about the BETA process. This document will explain the full process of BETA development, define timelines and testing processes for code going from BETA to Prod release, and provide information on how to install, test, and submit issues for BETA versions of code.

Repo config

Repo configuration for BETA releases requires the following steps:

1. Create a new branch, beta, from the main branch. Publish the new branch.
2. On the main branch edit the ./package.json file, see Figure 1 below.
3. On the main branch edit the ./.github/workflows/testPublish.yml file, see Figure 2 below.
4. On the main branch edit the ./.github/settings.yml file, see Figure 3 below.
5. Push the changes into the main branch with a build commit and publish code.
6. Once published, REBASE the beta branch on main and --force publish.

Figure 1

Update the ./package.json release object so that Semantic Release knows there is a new beta branch and that it's allowed to pre-release updated versions.

// Find the following code
// Be sure to use MAIN or MASTER, whichever the head branch is for that repo

  "release": {
    "branch": "main",
    ...
  }
  
// Update to the following

  "release": {
    "branches": [
      {
        "name": "main"
      },
      {
        "name": "beta",
        "prerelease": true
      }
    ],
    ...
  }

Figure 2

Update the ./.github/workflows/testPublish.yml file to include the beta branch when evaluating releases.

// Find the following code
// Be sure to use MAIN or MASTER, whichever the head branch is for that repo

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

// Update to the following

on:
  push:
    branches: [ main, beta ]
  pull_request:
    branches: [ main, beta ]

Also...

// Find the following code

if: github.event_name == 'push' && github.ref == 'refs/heads/main'

// Update to the following

if: github.event_name == 'push' && github.ref == 'refs/heads/main' || 'refs/heads/beta'

Figure 3

Update the ./.github/settings.yml file to add branch protection for beta.

// find the following code

branches:
  - name: main
    # https://developer.github.com/v3/repos/branches/#update-branch-protection
    # Branch Protection settings. Set to null to disable
    protection:
      # Required. Require at least one approving review on a pull request, before merging. Set to null to disable.
      required_pull_request_reviews:
        # The number of approvals required. (1-6)
        required_approving_review_count: 1
        # Dismiss approved reviews automatically when a new commit is pushed.
        dismiss_stale_reviews: true
        # Blocks merge until code owners have reviewed.
        require_code_owner_reviews: true
        # Required. Require status checks to pass before merging. Set to null to disable
        # Specify which users and teams can dismiss pull request reviews. Pass an empty dismissal_restrictions object to disable. User and team dismissal_restrictions are only available for organization-owned repositories. Omit this parameter for personal repositories.
        dismissal_restrictions:
          users: ["blackfalcon"]
      # Required. Require status checks to pass before merging. Set to null to disable
      required_status_checks:
        # Required. Require branches to be up to date before merging.
        strict: true
        # Required. The list of status checks to require in order to merge into this branch
        contexts: ["test (18.x)", "test (20.x)", "license/cla"]
      # Required. Enforce all configured restrictions for administrators. Set to true to enforce required status checks for repository administrators. Set to null to disable.
      enforce_admins: false
      # Required. Restrict who can push to this branch. Team and user restrictions are only available for organization-owned repositories. Set to null to disable.
      restrictions: null
      # Prevent merge commits from being pushed to matching branches
      required_linear_history: true
      

// replace with the following

branches:
  - &default_protection
    # https://developer.github.com/v3/repos/branches/#update-branch-protection
    # Branch Protection settings. Set to null to disable
    protection:
      # Required. Require at least one approving review on a pull request, before merging. Set to null to disable.
      required_pull_request_reviews:
        # The number of approvals required. (1-6)
        required_approving_review_count: 1
        # Dismiss approved reviews automatically when a new commit is pushed.
        dismiss_stale_reviews: true
        # Blocks merge until code owners have reviewed.
        require_code_owner_reviews: true
        # Required. Require status checks to pass before merging. Set to null to disable
        # Specify which users and teams can dismiss pull request reviews. Pass an empty dismissal_restrictions object to disable. User and team dismissal_restrictions are only available for organization-owned repositories. Omit this parameter for personal repositories.
        dismissal_restrictions:
          users: ["blackfalcon"]
      # Required. Require status checks to pass before merging. Set to null to disable
      required_status_checks:
        # Required. Require branches to be up to date before merging.
        strict: true
        # Required. The list of status checks to require in order to merge into this branch
        contexts: ["test (18.x)", "test (20.x)", "license/cla"]
      # Required. Enforce all configured restrictions for administrators. Set to true to enforce required status checks for repository administrators. Set to null to disable.
      enforce_admins: false
      # Required. Restrict who can push to this branch. Team and user restrictions are only available for organization-owned repositories. Set to null to disable.
      restrictions: null
      # Prevent merge commits from being pushed to matching branches
      required_linear_history: true

  - name: main
    <<: *default_protection

  - name: beta
    <<: *default_protection

Non SemVer process

While the BETA release process is widely supported, the BETA npm version type, e.g. 1.0.0-beta.4 is not officially supported by SemVer.

This means that some automated tools MAY NOT easily support the installation or updating of these BETA releases. To some extent this is to be expected as using BETA releases should be a task that requires manual intervention as an acknowledgment of the scenario.

Updated repos

List of completed repos.

Repo	commit
WC-Generator repo	b2fba31
WC-Generator template	b2fba31
WCSS	AlaskaAirlines/WebCoreStyleSheets@58d3f7b
Library	AlaskaAirlines/auro-library@694b2aa
icons	AlaskaAirlines/Icons@149fcd6
auro-skeleton	AlaskaAirlines/auro-skeleton@51ab82d
auro-table	AlaskaAirlines/auro-table@72d3d01
auro-toast	AlaskaAirlines/auro-toast@23bb147
auro-pane	AlaskaAirlines/auro-pane@8b3d856
auro-datetime	AlaskaAirlines/auro-datetime@96f0741
auro-popover	AlaskaAirlines/auro-popover@166415e
auro-radio	AlaskaAirlines/auro-radio@cd0fa9c
auro-loader	AlaskaAirlines/auro-loader@d3e4371
auro-dialog	AlaskaAirlines/auro-dialog@bfd2360
auro-drawer	AlaskaAirlines/auro-drawer@6ab40e0
auro-header	AlaskaAirlines/auro-header@72fe39b
auro-dropdown	AlaskaAirlines/auro-dropdown@95be7d8
auro-alert	AlaskaAirlines/auro-alert@178b1ea
auro-badge	AlaskaAirlines/auro-badge@5c81c0b
auro-hyperlink	AlaskaAirlines/auro-hyperlink@96618e1
auro-icon	AlaskaAirlines/auro-icon@8ef24c9
auro-menu	AlaskaAirlines/auro-menu@46050b8
auro-lockup	AlaskaAirlines/auro-lockup@35ac65d
auro-avatar	AlaskaAirlines/auro-avatar@6ac1e44 and AlaskaAirlines/auro-avatar@f58eead
auro-flight	AlaskaAirlines/auro-flight@1eae27e
auro-input	AlaskaAirlines/auro-input@c2fc1c4
auro-backtotop	AlaskaAirlines/auro-backtotop@80a796b
auro-select	AlaskaAirlines/auro-select@3a89bb1
auro-accordion	AlaskaAirlines/auro-accordion@7458c7f
auro-card	AlaskaAirlines/auro-card@68a8d9d
auro-checkbox	AlaskaAirlines/auro-checkbox@99f3847
auro-carousel	AlaskaAirlines/auro-carousel@78a1947
auro-formvaliator	AlaskaAirlines/auro-formvalidation@d119fe2
auro-flightline	AlaskaAirlines/auro-flightline@7b5a743
auro-nav	AlaskaAirlines/auro-nav@0e37d2f
auro-sidenav	AlaskaAirlines/auro-sidenav@f2439a4
auro-combobox	AlaskaAirlines/auro-combobox@47f5439
auro-datepicker	AlaskaAirlines/auro-datepicker@e5d739f
auro-button	AlaskaAirlines/auro-button@1e4e4fb
auro-background	AlaskaAirlines/auro-background@544d060
auro-banner	AlaskaAirlines/auro-banner@7182414

Script for commit:

build: add BETA release support

This commit updates the repo's build scripts to be compliant with
BETA releases described in this discussion:

https://github.com/orgs/AlaskaAirlines/discussions/556

Process

The BETA release process will resemble much of the well-known git flow, but only requires the beta branch in place of the develop branch.

The [beta] branch should be used when preparing new production releases. Typically, the work being performed on [beta] branches concerns finishing touches and minor bugs specific to releasing new code, with code that should be addressed separately from the main development branch.

The BETA process will mean that NO FEATURE branches are ever created from main, but always from beta.

The feature branch is the most common type of branch in the Git flow workflow. It is used when adding new features to your code.

When working on a new feature, you will start a feature branch off the [beta] branch, and then merge your changes back into the [beta] branch when the feature is completed and properly reviewed.

Conversely, bug fixes will require following the git flow hot fix process.

In Git flow, the hotfix branch is used to quickly address necessary changes in your main branch.

The base of the hotfix branch should be your main branch and should be merged back into both the main and develop branches. Merging the changes from your hotfix branch back into the develop branch is critical to ensure the fix persists the next time the main branch is released.

It should be noted that the BETA process SHOULD NOT be used as a way to release an incomplete concept quickly. All merges into BETA should be considered READY FOR PROD at any moment.

Expected outcomes

Implementing the proposed updates is expected to yield several key outcomes:

1. Improved Stability and Compatibility:

   • By reinstating the RC process and ensuring thorough testing before release, updates will be more stable and compatible with other components.
   • Fewer incidents of incompatibility and regression issues, resulting in smoother integration and fewer disruptions for development teams.

2. Enhanced Quality Assurance:

   • The introduction of a BETA package release process will provide an additional layer of testing.
   • Early identification and resolution of bugs and issues will lead to higher-quality releases.

3. Increased Flexibility for Development Teams:

   • Teams can choose to adopt BETA versions to access new features early, allowing for more flexibility in development cycles.
   • This approach accommodates teams that review dependencies infrequently, aligning better with their workflows.

4. Better Risk Management:

   • Clear communication that BETA versions are "use at your own risk" will help manage expectations and encourage cautious adoption.
   • Teams can test BETA releases in controlled environments before full deployment, mitigating potential risks.

5. More Efficient Release Management:

   • Bundling updates in RCs will streamline the release process, reducing the overhead associated with frequent, smaller updates.
   • More predictable release schedules will improve planning and coordination across teams.

6. Enhanced Collaboration and Feedback Loops:

   • Encouraging the use of BETA versions will foster a more collaborative environment, where teams provide feedback and contribute to improving the final release.
   • Structured feedback mechanisms will ensure that issues are promptly addressed, leading to continuous improvement.

7. Reduced Disruption and Increased Productivity:

   • Minimizing disruptive, incompatible updates will allow teams to focus on their core tasks without frequent interruptions.
   • Overall productivity is expected to increase as development teams experience fewer unexpected issues and smoother integration processes.

8. Clearer Communication and Documentation:

   • Clear documentation of the BETA process and expected use will improve understanding and adoption across the organization.
   • Better communication regarding the nature and purpose of BETA and RC releases will align team expectations and practices.

These outcomes collectively aim to enhance the efficiency, stability, and quality of the build and release process, ultimately supporting the organization's goals and development practices.