Continuous Integration and Isolated Feature Testing

Question

I've been given the task at work to move everyone from using TFS Source Control to Git as the Development Team has been lead to believe that Git may well be the silver bullet that will fix alot of the teams issues. I carried out the migration a month back and fortunately Git has fixed one thing for the team - code reviews are now alot more structured as pull requests in Git give the developer and reviewers a auditible platform to merge code into the master branch. There is however an issue of merge conflicts still, some of which taking up to 2 or 3 hours to resolve. The team are questioning if the tool (Git) is to blame whereas under analysis, I believe there are many other fundamental processes and pratices at fault within the team. To name but a few that don't sit well with me:

• All products (Visual Studio Projects) maintained by the company sit under one Visual Studio Solution. This is around 40+ VS Projects ranging from Class Librarys, Services and Database tiers. If an update needs to be made to Production for one product, the whole Solution (along with the other products) needs to be released.
• There a 4 Scrum Teams working on the same VS Solution looking after their own Products. The Sprints all start on different days in a two-week cycle and therefore at any point in time, each team's Sprint is at a different state. Due to the issue raised in the first bullet point however, complexity ensues when it comes to the monthly release to Production as code for each product can be at separate stages.

Anyway, that paints part of the scene to help pose my question. We're now using Git using the following structure:

• Feature branch - Used for each User Story being worked upon in a Sprint
• Develop branch - All Feature branches are merged into here once the Pull Request has been approved and the change tested in isolation on a test server
• Master branch - Successfully tested features are cherry-picked into the Master branch

My question is, how does DevOps / CI handle testing newly coded features in isolation? I've never worked in a place where we've tested new changes in total isolation therefore I can't get my head around why it's so important to my new Dev Team. In my opinion, the sooner we can test new changes with the rest of the codebase, the better.

Answer 1

First of all, git is certainly not to blame for merges taking a long time. Clean merging is the hallmark of git, unless it is used in some broken way. So I encourage you to look at what exactly seems to be the underlying problem. If your devs regularly make sweeping changes to the same files, then it's likely more a problem of cohesion/coupling than of the underlying merge tool.

Second; I like to do isolated feature-testing, if by that you mean that your test suite is ran against the feature branch (with only the branch changes) in a clean environment. In fact, I like to test all branches in this way. How could the develop or master branch become green if one of the features going into it are not? It goes without saying that develop / master need to be tested as well.

You could even go so far as to do a pre-merge test by doing a merge of feature into temp_develop_with_feature (or whatever you may call it), that is, simulate the merging of a branch into develop (under a different name) and test that.

Obviously, all of this assumes that sufficient testing ressources (VMs etc.) are available and fast enough, and that everything is 100% automated, both of which should be rather easy to achieve with something like Jenkins, Gitlab or whatever tool you use (if not, then it's maybe time to look at another one...).

Answer 2

There is however an issue of merge conflicts still, some of which taking up to 2 or 3 hours to resolve. The team are questioning if the tool (Git) is to blame whereas under analysis.

What is causing the merge hassle?

• Why does it take up to two or three hours to resolve merge conflicts?
• What workflow do the developers use?

In summary, what is the cause of this merging conflict hassle?

Is git causing the issue?

This has nothing to do with git, but looks like a workflow issue.

My favorite flow is the GitHub flow. When a feature has to be created, a new branch will be created from the master, when development has been completed, a PR will be created, when the review is completed the branch could be merged into master.

There are other flows, but what I do not like about gitflow is that I have seen in multiple companies that developers were applying a kind of "through it over the wall" approach as they merge multiple features to the develop branch without releasing. When after a couple of months software has to be released from the master then a lot of issues could occur. I personally like the following quote from this answer.

don't use git-flow. It looks nice in that diagram because of the lovely coloured dots and nicely laid out lines, but in reality it looks like an insane messy web of coloured lines and dots.

Release software more often

When the github flow will be applied then less merge conflicts will occur as when one creates a new feature then one has to create a branch from the master. As features are merged into the master, there is a bigger change that the commits in the feature branch will be behind master.

Discipline

Although workflows could be applied, the most important thing is discipline. Developers should ensure that if they create a Pull Request that their commits that reside in a feature branch are ahead of the master. Other developers should enforce that features will not be too big as these will be harder to merge and are harder to review.