A system for better collaboration
When I started working at SLTWTR, all development work was done on the main branch, with two deployment profiles: one for production and another for staging. Both deployments originated from the main branch, which caused stress when work-in-progress commits existed on the main branch, and clients wanted to deploy specific features.
To address this, we introduced the concept of three distinct testing environments, each corresponding to a different branch:
- Production Branch: The main shared branch, reserved for production-ready code.
- Staging Branch: A separate branch dedicated to staging, where completed features are tested before being deployed to production.
- Development Branch: A branch that combines all separate feature branches for internal and external QA, without merging them into other branches. This branch provides a single testing theme while maintaining the flexibility of keeping features separate.
Learning curve
Switching up the workflow was a difficult process at first but once the development team, account manager, product owners, and clients got used to it we saw the benefits fairly quickly. The main benefit was a better QA experience that led to fewer bugs in production environments.
Example flows
Below are some git branch diagrams that I put together for our team and any technical stakeholders with a client.
This branching model allows us to combine all features into one testing theme for efficient QA, while retaining the flexibility to merge and deploy individual features as needed based on client priorities. This approach has improved the overall development process, reducing stress and ensuring timely deployment of features as per the clients' requirements.