There are three strategies for structuring a branching workflow.
1. Centralized workflow
This is a basic workflow, according to Rao, which makes it most useful for teams transitioning from a version control system like SVN (subversion). It provides a single point of entry for all code changes, which is good in that it’s less complicated than others. But its disadvantages are that the main branch can become unstable and it’s difficult to maintain releases.
“If the developers are checking in 10 times a day and each time they do you run a scan, it’s very hard even for the developers to understand which version of all the files the scanning tool will get,” Rao said.
2. Feature branch workflow
Also known as GitHub flow, this strategy divides all the functionalities a team wants into different feature branches, and multiple developers can work simultaneously on a branch.
“The developers branch out and call it whatever name they want, like August branch or September branch,” Rao said. “Once they do that, multiple developers start working on it. Maybe there are some features that they want in the UI, some that they want in the back end, some that they want in the database. So they create three or four different feature branches with different developers assigned to them.”
“Once they decide their sprint is complete, all of them will commit to the main branch. And this merging happens through a pull request, which can be done in GitHub, GitLab, or in Bitbucket,” she said.
At which point, teams can configure their version control to decide what needs to be done—code review, static analysis, SCA, threat modeling, or other tests.
“Someone can actually manually review that, and only when they approve it and say it is a good feature with no glaring vulnerabilities or risk in the code, then it can merge to the main branch,” Rao said.
The disadvantage of the feature branch workflow, according to Rao, is that since there are so many features in a merge, “you need to have solid automated tests to make sure that when you merge, feature one won’t break the changes that feature two is adding.”
3. GitFlow workflow
This is the strategy used by teams with the most maturity in DevSecOps. It includes feature, development, and main branches, with the development branch serving as the integration branch for features, and the main branch storing the release history.
Rao notes that release history is important for organizations that need to comply with auditing requirements. “It will answer questions like, ‘What went into this feature that went into production? What changes did you make? Did you run static analysis?’” she said. It also means teams working on feature branches will do a pull request to merge with the development branch, not the main branch.
The GitFlow workflow also includes a dedicated release branch. Once the development teams have enough features for a release, the release branch is forked, which allows one team to finalize the current release and another team to continue working on more features. And once the release branch is tested, it is then merged to the main branch.
It can get complicated, Rao said, with so many branches. “But one of the key things is to see how easy it is for us to help clients run our testing tools when they are either merging from the develop branch to the main branch, or from the feature branch to the develop branch or the main branch.”
It’s easy, she said, because Synopsys has a new tool to help decide on the significance of code changes and the risk level of potential vulnerabilities.