2.4. Standards: Repository Access and Branch Protection Policy - rdkcentral/ut-core GitHub Wiki

Purpose

This policy establishes a structured and secure workflow for code changes, defining distinct roles for the Layer Release Team, Contributors, and CodeOwners (typically architects). It utilises the GitFlow branching model to maintain code quality and control releases, with CodeOwners playing a key role in planning and release cadence.

This project employs a layered architecture where the image assembly is divided into distinct functional components, each potentially managed by an independent layer release teams. Each component team is responsible for the development, testing, and release of their specific component.

Where common functionality exists, the component team proposing a change will request review from the CODEOWNERS, once approved they will merge the change in accordance with an agreed process. CODEOWNERS will then perform the release process.

  • Image Layers:

    • Vendor Layer: Contains vendor specific implementation and configurations.
    • Middleware Layer: Provides core common services and functionality.
    • Application Layer: Implements the applications.

  • Independent Release Teams:

    • Autonomy: Each team maintains a high degree of autonomy over their layer, allowing independent release cadence.
    • Coordination: Teams collaborate and synchronise when changes affect shared functionalities or dependencies.

Actors and Roles

  1. Contributors Team (Engineers):

    • Responsibilities:
    • Permissions:
      • Write access to feature branches.
      • Write access to develop for approved feature branches.
      • Read access to main
      • No direct merge access to main.

  2. CodeOwners Team (Architects):

    • Responsibilities:
      • Review and approve PRs.
      • Plan milestones and determine release cadence.
      • Release authority (decide when to merge to main).
      • Note: May not directly make code changes.
    • Permissions:
      • Write access to develop for approved feature branches.
      • Read access to all branches.
    • Configuration:
      • Defined in the ./github/CODEOWNERS file.

  3. Layer Release Team:

    • Responsibilities:
      • Release Content: Determine the specific versions of previously released components to be incorporated into the new layer release.
      • Update Configuration: Modify configuration files to reference the selected component versions.
      • Create the layer release branch from develop
      • Merge code from release branch to main.
      • Tag are created on main caused by git-flow
      • Merge from main to develop caused by git-flow
      • Push changes to main and develop, including tags.
    • Permissions:
      • Write access to main & develop.
      • Read access to all branches.

Branch Protection

  • main:

    • Strictly protected.
    • Only the Release Team can merge.
    • Tags used to mark releases.
    • Maintains a history of feature releases.

  • develop:

    • Protected.
    • Requires a pull request from a feature branch with approval from CodeOwners to merge.
      • Release team bypass this requirement
    • Contributors and CodeOwners can merge.
    • Maintains a history of feature integrations.

Workflow

  1. Planning: CodeOwners plan milestones and determine the release cadence.
  2. Branching: Contributors create feature branches from develop.
  3. Development: Contributors work on their feature branches.
  4. Pull Request: Contributors submit PRs for review, automatically assigning CodeOwners.
  5. Code Review: CodeOwners (architects) review code and provide feedback.
  6. Approval: CodeOwners approve PRs that meet quality standards.
  7. Merge to develop: Approved PRs are merged into develop (by Contributors or CodeOwners).
  8. Release: CodeOwners determine the release cadence.
  9. Release Team:: Create a release via a release branch and merges to main and develop.

Appendix