Tzvi Gregory KaidanovIntroduction
This document outlines the CI/CD process and branch management strategy for our development team. It includes guidelines for creating and managing branches, continuous integration and deployment practices, and the roles and responsibilities of team members.
CI/CD workflow Edit with code
Branching management process Edit with code
Infrastructure components branches
Question: Should we have different branches for each component?
Each component should have its own branch. This approach is beneficial because we are dealing with an infrastructure library. If we need to change a component in the future, we can easily locate the previous task associated with it, find the relevant branch, fetch the previous version branch, rewrite the logic, and then merge the changes back into the dev branch that everyone is working on. This method allows multiple programmers to work on different components in parallel, enhancing efficiency and collaboration.
Reasons for different branches
Component Isolation: By having each component in its own branch, changes are isolated, which minimizes the risk of conflicts and makes it easier to manage dependencies and track changes specific to each component.
Parallel Development: This strategy facilitates parallel development, enabling multiple developers to work on different components simultaneously without stepping on each other's toes.
Historical Reference: Maintaining separate branches for each component allows for easier reference and rollback. If a change needs to be revisited or reverted, having a dedicated branch simplifies the process.
Branch Management: Ensure that the branching strategy is well-documented and that developers follow the naming conventions and workflow steps consistently. This will help maintain clarity and order in the repository.
Branch Naming Conventions
Feature Branches
Naming Convention: feature--
Example: feature-1234-user-authentication
Purpose: Used for developing new features or stories.
Bugfix Branches
Naming Convention: bugfix--
Example: bugfix-5678-fix-login-error
Purpose: Used for addressing and fixing bugs identified during development or testing.
Hotfix Branches
Naming Convention: hotfix--
Example: hotfix-91011-critical-payment-issue
Purpose: Used for urgent fixes that need to be deployed to production immediately.
Release Branches
Naming Convention: release-
Example: release-1.2.0
Purpose: Used for preparing a new production release, allowing final bug fixes and feature adjustments.
Main Branches
Development Branch (dev)
Purpose: Main branch for ongoing development.
Test Branch (test)
Purpose: Main branch for testing purposes, where stable development changes are merged for thorough testing.
Production Branch (prod)
Purpose: Main branch for production releases, containing the code that is currently live.
Workflow
Sprint Planning & Prioritization
Project Manager (PM): Leads sprint planning, works with stakeholders to prioritize features from the roadmap, and creates Azure DevOps items (stories, tasks) with clear descriptions and acceptance criteria.
Feature Development
Developer (DEV):
Check out a new feature branch from dev.
Follow naming convention: feature--.
Example: feature-1234-user-authentication.
Implement the feature and commit frequently with meaningful messages linked to the Azure DevOps item ID (e.g., #123).
Continuous Integration (CI)
On every push to a feature branch:
CI builds the code.
Runs unit tests.
Lints the code (checks for style and potential errors).
Code Review & Merge (Pull Request)
Developer (DEV): Creates a Pull Request (PR) targeting the dev branch.
Scrum Master (SM)-Another Developer: Reviews the code, provides feedback, and approves the merge.
Developer (DEV): Merges the feature branch into dev after approval.
Dev Environment Deployment
CI/CD Pipeline (CI): Automatically deploys the merged code to the Dev environment.
Project Manager (PM): Validates the feature in the Dev environment.
Bugfix Development
Developer (DEV):
Check out a new bugfix branch from dev.
Follow naming convention: bugfix--.
Example: bugfix-5678-fix-login-error.
Implement the fix, commit frequently, and follow the CI and PR process.
Hotfix Development
Developer (DEV):
Check out a new hotfix branch from prod.
Follow naming convention: hotfix--.
Example: hotfix-91011-critical-payment-issue.
Implement the fix, merge into prod, and then back into dev to ensure the fix is included in ongoing development.
Release Preparation
Scrum Master (SM) or DevOps Expert: Create a new release branch from dev.
Follow naming convention: release-.
Example: release-1.2.0.
Testing
Scrum Master (SM): Merge dev into test for testing.
CI/CD Pipeline (CI): Automatically deploys the merged code to the Test environment.
QA Tester (QA): Executes automated and manual tests, logs bugs, and the cycle repeats (Developer fixes, PR, merge, deploy, QA test).
Production Release
QA Team (QA): Approves the version in Test.
Scrum Master (SM) or Admin: Merge test into the prod branch.
CI/CD Pipeline (CI): Automatically builds the code for the Prod environment.
Chief Technology Officer (CTO): Reviews and approves the release.
CI/CD Pipeline (CI): Deploys to Production. Multiple releases may be configured for different clients, following customized workflows defined in collaboration with their development teams.
Post-Release & Monitoring
DevOps Expert (DevOps): Monitors Production for errors and performance issues.
Team: Collects customer feedback and participates in retrospectives to identify areas for improvement.
Summary
Following these branch naming conventions and workflow steps ensures a structured approach to managing code changes, improving collaboration, maintaining a clean Git history, and ensuring traceability with Azure DevOps item IDs. This comprehensive process promotes efficiency, code quality, and continuous improvement in our development practices.
For further clarifications or refinements, please contact the respective project leads or team members.
