3 Git Workflows to Showcase Unfinished Work

When developing software, you eventually need to show your work to the world. But before that happens, there’s usually a review process in which someone (e.g. a tester, product owner, or stakeholder) wants to review what you built. Based on their feedback, you can improve your work until you reach a point where everyone is pleased and accepts the changes.

But how do you get to that point where people can view your work and deliver feedback? Let’s look at three different approaches that help you to showcase unfinished work.

The Solo Workflow

Working by yourself on a software product makes things easy. You have a good overview of your work, you can pick up user stories one by one, and when the time comes to have your work reviewed, you can release the changes to a central development environment. Ideally, you make use of a CI/CD setup that helps you build, test, and release a new version without manual intervention.

After you have deployed the new version, you can verify the functionality and ask for feedback. In the meantime, you can start working on another user story, from a new feature branch, while the review is pending.

When the review is done and there’s feedback to resolve, you can implement the requested changes, initiate a new release from your feature branch, and deploy a new version to the development environment. After a final verification by you and the reviewer indicating that everything is working fine, you can finalize the changes by merging the feature branch to your main branch.

But what happens when feedback on the first feature that you implemented hasn’t come and the next user story you picked up is ready to be tested and shown to the product owner and stakeholders? You can, of course, deploy from your new feature branch, but that will overwrite the changes that are currently deployed on the central development environment from the other branch.

One solution is to create separate environments for every individual change. This is what the Multi-Environment Review Workflow is about, and I will describe it in a moment. But there’s also a simpler solution called the Integration Branch Workflow.

The Integration Branch Workflow

When a team has multiple developers, it is often the case that multiple user stories are being worked on simultaneously. Also, the review processes of individual user stories can take more time due to external delays. Therefore, there is a need to have multiple pending changes deployed to the development environment at the same time so reviews can be performed simultaneously.

The concept of an integration branch can help with this. The idea is that all your pending work that is ready to be reviewed is merged into an integration branch. This branch is then automatically deployed to a central development environment based on a trigger configured in your CI/CD pipeline.

This integration branch will never be merged into another branch. Only content from feature branches or your main branch should be merged into the integration branch. Sometimes there will be content merged into the integration branch that will not be accepted, is outdated, or is not relevant anymore. Therefore, a good approach is to delete the integration branch regularly (e.g. at the start of every sprint) and create a new integration branch based on the main branch. Any work that’s still pending can then manually be merged into the integration branch so the team can start the sprint with a clean slate.

The Multi-Environment Review Workflow

When there is a requirement to test individual user stories in isolation, independent of any other pending work, you can use the Multi-Environment Review Workflow. This workflow is very similar to the Solo Workflow. The main difference is that it uses automation to create temporary environments and deploy changes from individual branches to those environments. Changes can then be reviewed in isolation. After a change is accepted and merged to the main branch, the temporary environment for that particular change can be destroyed.

When you have a relatively simple setup, such as a static website, there are off-the-shelf solutions that facilitate this workflow. Netlify, for instance, has a feature to automatically build and deploy branches to a temporary preview domain using a uniquely generated URL. To make sure that search engine crawlers don’t index this preview site, Netlify adds a custom header to every response: x-robots-tag: noindex.

When you have a more complex setup, the approach Netlify offers is not sufficient. You might need to deploy more than one application, initialize dependent services, and provision your data store with test data. Tools such as Docker, CI/CD, and APIs of cloud hosting platforms such as AWS and Azure can assist with spinning up on-demand environments for your application. As this approach can quickly become very complex, it is not suited for every team and organization. Before going down this path, you should clearly define bottlenecks and challenges within your architecture and decide if the advantages outweigh the investment to implement and maintain such a multi-environment solution.

Conclusion

Based on my experience, the Integration Branch Workflow will be a safe bet for most teams, as it combines the advantages of simultaneous reviews without the complexity of deploying and maintaining multiple environments.

Regardless of the workflow that you implement, you should strive for a review workflow that aligns with your processes and organization. This will improve your team’s effectiveness and help with delivering quality software.