DEV Community

Cover image for CI/CD and Branch Management
Tzvi Gregory Kaidanov
Tzvi Gregory Kaidanov

Posted on

CI/CD and Branch Management

Introduction

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

Image description

Image description

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.

Top comments (0)