Git Branching When Your Staging is Also Your Production.

There are lots of application environments used in software applications to help them isolate each development progress. Commonly, these 4 environments are used for software development.

1. Development / Local environment.
   The environment used for the development process by the programmer. It usually uses a local IDE debugger to develop the application. There’s also a possibility of running the development software on the other machine such as a development server if the software needs higher resources. Unit tests can be done in this environment as well.
2. Staging environment.
   This environment can be used by Tester to test the application. They can run the progression and/or regression tests in this environment. A staging environment can be a gatekeeper before the software is released.
3. Beta environment.
   Some application needs to make sure all of the functionalities are working well on the user side. This environment can be used as an application rollout stage before it’s 100% released to the user.
4. Production environment.
   Any application in this environment is identified as a stable version of the application.

Uncommon Scenario

Not every system has the same scenario to meet the business logic requirements. There is a scenario that which the Production environment logic depends on the Staging environment result. For example, you are a Data Engineer and have an application to automate the pipeline creation. The requirements require you to make sure the pipeline running well in the Staging environment before it can be created in the Production environment. In this case application in the Staging environment becomes as crucial as the Production environment.

Git Branching Strategy

With the given scenario, a common environment strategy can’t be used especially because of the Staging environment behavior. This uncommon environment will also change the Git Branching and the CI/CD flow. We will cover the CI/CD flow in the other articles by the way, so stay tuned!

The branching strategy needs to cover these points to make sure it can support the agile software development approach:

• Development can be done parallelly within the developers.
• Isolated testing environment for each feature in the development process.
• Independent branch stage to loosen the dependency for each development process for easier deployment.
• Easy to track the code for each environment.
• Support hotfix changes in case of a bad deployment.

The Trunk Based Development

Trunk Based Development (TBD) or Git Flow approach can be used to fulfill the requirements. But, we will use TBD this time.

In TBD we only use 1 protected branch called trunk (Not mandatory, you could use other names you like). Each feature will have its own branch to work with. It also uses Tags to maintain the release history. We will only use these 3 environments:

1. Testing Environment
   Used by QA or Tester to do the manual or progression test for each feature. There can be many Applications in this environment so the testing can be done parallelly.
2. Staging Environment
   Regression or end-to-end testing can be done in this environment. It also supports the Production environment business logic as we mentioned earlier.
3. Production Environment
   An application environment used by the end-user or UI team depends on the application type.

How you can track which code belongs to which environment?

• Production: You can use the latest Tag release to get the code.
• Staging: You can pull the code from the trunk branch.
• Testing: Refer to the relevant feature branch.

How it works?

Normal Flow

1. During the development, the developer will create a new branch from the trunk.
2. After development is done, the developer creates PR to trunk.
3. To deploy the feature to the Testing environment, a developer can deploy the code based on either the feature branch or PR to the server.
4. QA / Tester tests the functionality on the Testing environment.
5. The developer then can merge the PR to the trunk and pull the code from the trunk to deploy to the Staging environment.
6. Run automated regression or end-to-end testing if necessary in the Staging environment.
7. For the production deployment, the developer needs to define the commit hash and then deploy it to the Production environment.
8. Don’t forget to always create Tag and Release to maintain the release history. This Tag is necessary to keep track of which code is deployed to the Production environment.

Hotfix Flow

1. If the trunk branch refers to a Production application, we can proceed with the normal flow to do the hotfix.
2. If there are preceding changes in the trunk branch, we still need to create a hotfix branch from the trunk and fix the bugs from it. It means we need to do hotfix in Staging as well. It is safe to do that because based on the requirement Staging environment always passes the progression test and actually used as a Production flow.
3. For the rest, we can follow the normal flow.

CI/CD notes

• Use the feature/hotfix branch / PR code for the Testing deployment.
• Use the trunk branch for the Staging deployment.
• Use the latest commit-hash merged to the trunk for the Production deployment.

Conclusion

There is no silver bullet strategy that can be used for our Application development. We need to find the best strategy that suits our needs. Each approach has its own advantages and disadvantages, making it a matter of suitability rather than the wrong or right approach.

That is how the Git Branching strategy helps us to achieve the development requirements. Stay tuned for the CI/CD part! Thank you!