Good evening everyone. First, let me start off by stating that we are a publicly traded company that falls under SOX controls & audit requirements.
For code branching strategies, we generally have followed the GitFlow strategy since our environments match up to the GitFlow branches (feature, develop, release, & main).
Our branches and how it maps to our environments
feature branch – developer's local instance for unit testing
develop branch is deployed to our DEV env.
the release branch is deployed to our QA env
main = PROD env.
Here is our typical workflow:
- Developers create a feature branch off the "develop" branch and make their code changes. They will then perform unit testing of their changes.
- The developer then requests a PR to the "develop" branch, which is then reviewed and approved by a lead dev. The code is now in the "develop" branch after approval. When all the features for all developers are in the "develop" branch, there may be end-to-end integration testing the team might perform if there are a lot of features that need to be tested together.
- When the dev team is ready for formal QA testing by the QA individual/team, a release branch is cut from the develop branch, and the build is deployed to the QA environment. QA will validate the features in this QA environment, and an automated regression suite is run against the entire build. If a bug is found by QA, the feature is sent back to the develop to repeat the first bullet and onwards again. When we are audited, this is the environment that is noted in each backlog ticket for each feature.
- When the release has passed all testing, the deployment in QA is released into the next environment – PROD.
We have a consulting group who prefers to change it up so that:
- Developer's unit testing and formal QA by the QA team/individual are performed off the feature branch before the developer makes a PR request to get the code changes merged changes into the "develop" branch. They said this avoids them having to do a ton of PR merge requests for each break-fix cycle for a feature.
- In this workflow, all the code, by the time it makes it to the QA environment, has been fully tested already. There is nothing more to test in QA besides maybe running the automated regression suite against that new set of changes.
I wanted to support a more efficient workflow for getting code into production, but also need to address SOX change control and stay within best practices at the same time. I am curious to hear if others are following the above process by our internal team or do you agree with the consulting group on having formal QA performed before the feature branch is merged into the "develop" branch.
Thank you ahead of time.
from Software Development – methodologies, techniques, and tools. Covering Agile, RUP, Waterfall + more! https://ift.tt/c1SCkar