Development Workflow and Release Planning Guide
Branch Protection Rules
To ensure the integrity of our codebase and maintain high-quality standards, we have implemented the following branch protection rules:
- All Environment Branches (dev, uat, main) Protected: Build validation is enforced on all environment branches to ensure that only passing builds are merged.
- UAT and Main Branches Additional Rules:
- Comment resolution is opted-in to facilitate better code reviews.
- Minimum number of reviewers: 1.
Pull Request Guidelines
Pull Requests (PRs) play a crucial role in our development workflow. Here are some key guidelines:
- Feature or User Story PRs: PRs represent a Feature or User Story from Target Process (TP).
- PR to Dev: Should be made by the developer. The PR should contain a fully finished feature, ready for team presentation and end-to-end (E2E) testing. Unit tests should already be in place.
- Release PRs: Moving to UAT involves grouping features ready on DEV into a release PR from DEV to UAT.
Release Planning and Process Flow
Following the meeting on January 17, several key aspects of our release planning and process flow were discussed and defined:
- Release Planning: Aim for a release cycle of 1 month/2 sprints. This timeframe includes programming/code changes and creation.
- Process for Pushing Changes: A defined process is necessary for moving Devices/Products from DEV -> UAT -> PROD. This includes product mappings/materialized views in ADX, ensuring a "four eyes principle" is applied from DEV to PROD.
- Deployment Frequency to UAT: If releases to PROD occur monthly, we should aim for 3 weeks of development and 1 week of testing, deploying to UAT accordingly.
- Testing and Onboarding Location: Business testing should occur in the UAT environment. Onboarding of new devices/products should also be planned accordingly.
- Purpose of DEV and UAT Environments: DEV is for development and initial testing, UAT for business testing and final verifications before PROD.
States of the Tickets:
- In Progress: In DEV.
- In Review: In UAT.
- Done: In PROD.
Semantic Versioning (SemVer) Guide
| Code Status | Stage | Current Version | Updated Version |
|---|---|---|---|
| Releases | New product, new design, etc. | 0.1.0 | 1.0.0 |
| Fix bugs, small changes | Patch release | 1.0.0 | 1.0.1 |
| New features | Minor release | 1.0.1 | 1.1.0 |
- Patch releases (1.0.0 → 1.0.1): Introduce backwards-compatible bug fixes or small changes.
- Minor releases (1.0.1 → 1.1.0): Introduce new features that are backwards-compatible.
- Major releases (0.1.0 → 1.0.0): Introduce changes that may not be backwards-compatible, such as new products or a new design.
This table is a guideline for our teams to update versions systematically and transparently, ensuring clarity and predictability for both developers and users.
Versioning and Tagging
- Data Engine Versioning: Establish a versioning scheme (e.g., 1.0.1) for the Data Engine to track changes and updates systematically.
- Tagging Releases: When a release is finalized, add a tag on main (prod) branch, version number should be in Target Process (TP) with the release version. Ensure that Pull Requests (PRs) corresponding to the release in DevOps are tagged with the same version for consistency and traceability.
This focused approach to tagging helps maintain a clear relationship between our work items and their respective releases, which is essential for managing our release cycles and providing transparency throughout our
Discussion Points
The meeting also brought up several points for further discussion and decision-making, including the exact process for moving changes through environments, and the specific roles and responsibilities regarding testing and quality assurance.
Additional Considerations
- Task States: Evaluate the need for more task states to track which features are at which stage or environment (e.g., ready to deploy to UAT, deployed to UAT, ready to deploy to PROD, deployed to PROD).
The guidelines and processes outlined above are designed to streamline our development and release processes, ensuring that we deliver high-quality software efficiently and effectively. Let's continue to refine these points in our upcoming team meetings.