SDLC – Understanding the Git Flow: A Software Development Workflow

Creating a development workflow with PROD (Production) and DEV (Development) environments using branches in a version control system like Git can be achieved through various strategies. However, one of the popular approaches is the Gitflow Workflow, which fits well within the Software Development Life Cycle (SDLC).

Git Flow is more than just a branching strategy; it’s a framework for managing the complexities of software development. Below, we unpack the intricacies of each branch type, detailing their specific roles, lifecycles, and real-world examples.

Please refer to Vincent Driessen’s original blog post on this topic for a comprehensive understanding. While I aim to summarize what he proposed and what I’ve observed in practice, it’s worth noting that I’m not a developer. However, I frequently participate in meetings where this topic arises. Additionally, I’ve been in many environments where this workflow, or something very close to it, was implemented. It serves as a solid foundation and starting point. Being well-rounded is essential when contributing to network infrastructure decisions.

1. Master/Production Branch

Purpose:

Represents the production-ready state. Everything here is stable, tested, and live.

Lifecycle:

• Always exists.
• Only receives merges from release or hotfix branches.

Example:

Let’s say your web application is running v1.2 live. This version is reflected in the master branch. Any direct commit here would mean a new version is live.

2. Development Branch

Purpose:

A reflection of the latest, stable development changes meant for the next release.

Lifecycle:

• Branched from master.
• Merges regularly from feature branches and occasionally from release and hotfix branches.

Example:

Your team plans to add new features for v1.3. These incremental developments happen here, away from the stable master, ensuring they don’t disrupt the live application.

3. Feature Branches

Purpose:

Develop new features or functionalities without affecting the main branches.

Lifecycle:

• Branched from development.
• Merged back into development once the feature is complete.

Example:

You want to add a user messaging system. You’d create a branch named `feature/user-messaging`. Once development and initial tests are done, it merges back into the development branch.

4. Release Branch

Purpose:

To prepare for a new release, consolidating features and ensuring the code is production-ready.

Lifecycle:

• Branched from development when it’s near release time.
• Merged into master (and tagged with a version number) and development post-release.

Example:

You’re ready to launch v1.3. The release branch, `release/v1.3`, is created. Here, final tests, documentation updates, and last-minute bug fixes occur. Once complete, it’s merged to master, tagged as `v1.3`, and also merged back to development to ensure any tweaks are retained.

5. Hotfix Branches

Purpose:

Quickly address production crises without disrupting ongoing development.

Lifecycle:

• Branched directly from master in case of unforeseen production issues.
• Merged back into both master (updating live code) and development.

Example:

A severe security flaw is found in v1.2. A branch named `hotfix/security-fix` is created off master. Once the issue is resolved, it’s merged back into master (perhaps resulting in v1.2.1) and the development branch.

Visualizing Transitions with a Simple Scenario:

Imagine you have the master branch at v1.2. You plan three new features for v1.3.

1. You and your team create three feature branches from development: `feature/A`, `feature/B`, and `feature/C`.

2. As each feature completes, they merge back into development.

3. When ready for release, you branch `release/v1.3` from development.

4. After final testing and tweaks in the release branch, you merge it into master, tagging it as v1.3. It’s also merged back to development.

5. Suddenly, a bug is found in v1.3 live. You branch `hotfix/bug-fix` from master, fix it, and then merge back to master (resulting in v1.3.1) and development.

Summary

1. Master Branch: The master branch mirrors the production environment. The code in the master branch is deployable and is currently in production.
2. Development Branch: You also have a development branch reflecting the DEV environment. This is where integration happens, and all developers merge their changes here.
3. Feature Branches: A new branch is created from development when a new feature is to be developed. This is called a feature branch. Developers work and test their features in this branch without disturbing the main code.
4. Merge Back to Develop: Once the feature is tested and ready, the feature branch is merged back into the develop branch. Using Pull Requests for these merges is good practice, which allows for code reviews.
5. Release Branches: When the develop branch has reached a stable point and is ready to release to production, a release branch is created. Any minor fixes can be made on this branch while allowing the develop branch to continue forward with new features.
6. Merge to Master and Develop: When the release is deemed stable, it’s merged into master and tagged with a version number. It should also be merged back into development, which may have progressed since the release was initiated.
7. Hotfix Branches: If a critical issue is found in production, a hotfix branch can be created from the master. Once the hotfix is complete, it is merged to master and develop (or the current release branch).

One last thing, who’s involved with setting something like this up?

In the context of an organization, implementing and adhering to such a workflow often involves collaboration among multiple IT roles and teams. Here’s a breakdown:

1. Developers (Software Engineers, Frontend/Backend Developers):

• Role: They are primarily responsible for coding. In Git Flow, they would typically handle the creation of feature branches, coding the required feature, and merging it back into the development branch upon completion. They might also be involved in bug fixes and hotfix branches.

2. Quality Assurance (QA) Engineers/Testers:

• Role: Their primary focus is to ensure that the software product meets quality standards before it’s released. They would work closely with the release branch, testing the features merged from the development branch, identifying bugs, and communicating them to the developers for fixes.

3. Release Managers or DevOps Engineers:

• Role: They manage and oversee the process of releasing new software versions to production. In the Git Flow model, they might handle the creation of release branches, coordinate final testing phases, and oversee the merging of release branches into master. They also ensure that any changes in the release branch get merged back into the development branch.

4. System Administrators or Operations (Ops) Team:

• Role: This team is often responsible for maintaining the production environment. While they might not directly interact with the branching strategies, they’re crucial when a hotfix is needed, as they can provide valuable insights into production issues. Additionally, they often work closely with DevOps engineers to ensure smooth deployments.

5. IT Managers or Team Leads:

• Role: While they might not be directly involved in the day-to-day coding or testing tasks, they play a pivotal role in decision-making. They often set the direction and ensure that the team is adhering to the established workflows, including Git Flow.

6. Product Managers or Product Owners:

• Role: They define the features and direction of the product. While not directly involved in the Git Flow, their decisions impact which features get developed and when.

Conclusion

Git Flow, while seemingly complex, offers a structured approach that streamlines development, especially for teams. Its compartmentalized nature means that tasks like feature development, releases, and emergency fixes can happen simultaneously without conflict, leading to more efficient workflows and a robust codebase.

While developers play a central role in the Git Flow workflow, its successful implementation requires collaboration among various IT teams. Everyone, from coders to testers to managers, has a part to play in ensuring that the development process is smooth, efficient and results in a high-quality software product.