Git Branching Strategy: A Practical Guide for Teams

As a project grows, having everyone push code without a defined workflow quickly becomes chaotic. Features collide, bugs slip into production, and deployments become stressful.

A well-defined Git branching strategy solves these problems by introducing clear responsibilities, predictable releases, and a smooth development lifecycle.

This article explains a streamlined workflow, better collaboration, and consistency in code deployment.

Press enter or click to view image in full size

Branch Definitions

master:

• Represents the live production environment.
• Code merged here is ready for deployment and should be thoroughly tested.

stage:

• Represents the staging environment.
• Used for final QA testing before code is released to production.
• Code merged here should be tested and approved by QA.

develop:

• Represents the active development environment.
• Used for integrating new features, bug fixes, and ongoing development work.
• Code merged here should be reviewed and approved by peers.

Workflow Rules

Master Branch

• Purpose: Live, stable code.
• Merge Criteria:

1. All PRs should pass CI/CD checks.
2. PRs must be approved by the QA team.
3. Code must first be merged into stage and tested.

• Release Process: Merging a PR into master automatically triggers deployment to production.

Stage Branch

• Purpose: Staging and QA testing.
• Merge Criteria:

1. All PRs should pass CI/CD checks.
2. Code must first be merged into develop and tested.
3. PRs must be approved by the QA team.

• Release Process: Merging a PR into stage triggers deployment to the staging environment for final QA.

Develop Branch

• Purpose: Active development.
• Merge Criteria:

1. All PRs should pass CI/CD checks.
2. PRs must be approved by at least one peer developer.
3. Code should include unit tests where applicable.

• Release Process: Merging a PR into develop allows for integration with other features and prepares for QA.

Workflow Guidelines

1. Creating a Feature Branch

Branch from develop using the following naming convention:

feature/<feature-name>
bugfix/<issue-name>
hotfix/<issue-name>

Example: feature/add-login, bugfix/fix-crash, hotfix/urgent-fix

2. Pull Request to Develop

• Open a PR to merge the feature branch into develop.
• Assign at least one peer for code review.
• Ensure all automated tests and checks pass before requesting a merge.

3. Pull Request to Stage

• After merging into develop, open a PR to merge into stage.
• Notify the QA team for testing.
• Resolve any issues or bugs identified during QA testing.

4. Pull Request to Master

• Once QA approves the changes in stage, open a PR to merge into master.
• Ensure no additional issues are identified before merging.

Branch Permissions

Press enter or click to view image in full size

Key Points for Developers

1. Always branch from develop.

• Use the naming conventions for clarity and consistency.

2. Ensure quality checks.

• Write unit tests.
• Run local tests before creating a PR.
• Follow coding standards.

3. Respect the PR process.

• Always assign reviewers and request approvals.
• Address feedback promptly.
• Notify the team when a PR is ready for QA or deployment.

4. Keep branches clean.

• Delete feature branches after they are merged.
• Regularly sync your local branches with the remote repository.

CI/CD Integration

• Automated checks (build, test, lint) are required for all branches.
• Deployment:
• Master: Automatically deploys to production.
• Stage: Automatically deploys to the staging environment.
• Develop: No deployment, for active development and integration.

Ref: https://medium.com/@piashcse/git-branching-strategy-a-practical-guide-for-teams-976cbe7150a5

Read More

CI/CD for Android: A Comprehensive Guide

Continuous Integration and Continuous Delivery (CI/CD) has become essential in Android development, helping developers automate building, testing, and deploying applications. In this article, we’ll create a straightforward CI/CD pipeline for Android using GitHub Actions, focusing on building, testing, and artifact management.

Step 1: Initialize a Workflow File
GitHub Actions workflows are configured in YAML files stored in .github/workflows. In your project, create a file named android-ci.yml with the following content.

name: Android CI/CD

on:
  push:
    branches:
      - master  # Run the workflow on pushes to the main branch
      - main    # Run the workflow on pushes to the main branch
  pull_request:
    branches:
      - master # Run the workflow on pushes to the master branch
      - main.  # Run the workflow on pushes to the main branch

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Set up JDK
        uses: actions/setup-java@v2
        with:
          distribution: 'zulu'
          java-version: '17' # Change to the version you need for your project

      - name: Cache Gradle files
        uses: actions/cache@v2
        with:
          path: |
            ~/.gradle/caches
            ~/.gradle/wrapper
          key: gradle-${{ runner.os }}-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
          restore-keys: |
            gradle-${{ runner.os }}

      - name: Build and test
        run: ./gradlew build --no-daemon

      - name: Run unit tests
        run: ./gradlew test --no-daemon

      # Upload debug APK as an artifact
      - name: Build debug APK
        run: ./gradlew assembleDebug --no-daemon

      - name: Upload APK
        uses: actions/upload-artifact@v3
        with:
          name: movie-world-apk
          path: app/build/outputs/apk/develop/debug/app-develop-debug.apk # Path to your APK

Workflow Explanation

1. Triggers: This workflow runs on pushes and pull requests to main and master branches.

2. Checkout Code: Uses actions/checkout@v2 to retrieve your code.

3. Set Up JDK: Installs the required Java Development Kit (JDK) with actions/setup-java@v2.

4. Cache Gradle Dependencies: Speeds up builds by caching Gradle files, saving dependencies between builds.

5. Build and Test: Runs ./gradlew build to build the project and ./gradlew test to execute unit tests.

6. Assemble Debug APK: Builds a debug APK with assembleDebug.

7. Upload Artifact: Stores the generated APK as an artifact for download and further review.

GitHub link: https://github.com/piashcse/Hilt-MVVM-Compose-Movie/tree/master/.github/workflows

Medium: https://piashcse.medium.com/cd-cd-for-android-a-comprehensive-guide-9c8129387ca8

Read More