At Cinchcast Tech, we've been spending a lot of time discussing a proper branching strategy for our codebase.
There exist dev, qa, and staging branches. All development starts locally and then gets merged into the dev branch. After testing, QA team can merge it into qa branch. Finally, when the code is ready to be released it gets merged into the staging branch:
When we work on new releases, we follow one of two approaches:
1. Release branches. A separate branch is created for each release.
For example, FOO_3_1_2 branch would be created for all work done on release 3.1.2 of the FOO project.
2. Feature branches. A separate branch is created for each large component. Typically these components require isolated testing, and are merged into the main branch only at the end. The naming convention is AY_MODULE where AY is initials of a developer and MODULE is the name of the component.
All new branches are created off a staging branch, which should mimic the code that's running in production.
Any urgent hotfixes are typically made directly on a staging branch, and then backported into other branches.
Any load testing or security analysis is typically done during QA stage when the code has been merged into qa branch. We have a variety of scanners running 24x7 against our qa and production environments, such as Mcafee Secure scanning for dynamic security vulnerabilities and NewRelic continuously checking the performance of the application. If any issues are found, then the code is rolled back and cannot go into Production.
Note: We are always looking to hire great software engineers. So if you are one, and are looking for an exciting environment to work at, email us at firstname.lastname@example.org