Like many Quality Analysts, the first form of source control I was exposed to would have been something like SVN or CVS or the like. They were simple tools to work with. You check code out, you check code in. Many of these tools however had problematic aspects associated with them with regards to merging and collaborating in a busy development environment.
The company I work for has been using Bitbucket for a while now for the development aspect of our product. To briefly describe this process...
Our base product is in the master repository in git (this would be equivelant to 'trunk' in other Source Control systems)
When we have a new feature that needs developed in Jira - we are able to assign that task to a developer and he would then create a 'feature branch' of the master repository.
This effectively clones the base product into an identical repository, but this repository is dedicated to the development of that one feature that he is assigned to. As time goes on and he completes his feature, he is then ready to try and merge it back into the master branch. Now this process should have unit tests or some sort of quality check in place to ensure that nothing dodgy is merged into master. We use a mix of unit tests and peer reviews. This merge process is called the 'Pull Request'. We are effectively requesting 'master' to pull our changes into itself.
In a tool such as BitBucket, the pull request system is very configurable. You can configure your pull requests to require 1 or more reviewers and approvals, it could also require that the code successfully builds.
Generally speaking when 2 or more developers are developing in a system, they would try to stay away from class files that each would be interacting with. This is just a courtesy to avoid messing with code that the other developer might need to work on.
Short of telepathy or the invention of a hive mind for developers, there is no way to resolve situations where two developers do end up working on the same code.
This is where 'merge' issues may arise. Tools such as BitBucket and Git provide features to mitigate the pain caused by merges. Git will provide you with options to perform intelligent merging etc. That being said, Git is just a tool and will never be able to tell if the merged code is up to standard. The typical way for handling merges, is for the developer who is about to do his pull request, to initiate what is called a Git 'rebase'. This tells GIT to re-update the repo from the master branch, to include any new changes in master in their own modified code. The onus is on the developer doing the pull request to ensure that the code is properly merged and no conflicts arise.
So what has this got to do with Quality Assurance or Automation.
As I said above, this is the process that many development organizations are working to. We are now trialing it in Automation and Quality Assurance in general internally.
I had mentioned previously that I have a framework of my own design that I use for Automation within the company I work for.
A dependency diagram of it is shown below...
Your probably thinking - Holy Crap!!
That's a lot of modules.
Your right... it is.
The framework was developed to be modular, decoupled and highly cohesive. However, the larger it grew, suddenly there become issues with maintenance and how to manage the future development of the framework. This is when the collaborative development process above comes into play with coding standards and other processes for managing code quality.
Full disclosure, when I first developed this framework, I was the only author of it and it kinda grew organically and it was all done in GIT master branch. No branches for features....
Now that other people within the organization are contributing to the framework, we need a quality control mechanism to ensure that bad code cannot be committed to master.
Borrowing from the above process that our developers use, we introduces the Feature Branching strategy along with peer review approval process for pull requests.
In addition, we are in the process of adding unit test projects for each feature. These then get built and executed by TeamCity which will either pass or fail. Failed builds / executions will not get deployed to our Artifactory server and will not get consumed by the users of the automation framework via NuGet. (Each feature is a separate NuGet package).
Using examples for this process, it might be like this...
The framework exists, but we want to add Appium functionality, we also want to add functionality to allow for database communication with a Redis database.
Sally is free to work on one of the features, so she clones the whole framework to an Appium branch - she will build the Appium integration feature.
James is going to work on the Redis functionality, he clones to a Redis branch.
They both work on their respective features, getting the functionality working, ensuring that everything builds, existing unit tests are run to ensure no regression and they create new tests to ensure their feature never breaks either. James is finished, he performs a rebase to pull down any changes that have made it into master while he was working on his branch. No changes are detected, so he commits to his branch.
He goes into BitBucket and raises a Pull Request from his branch, into master - Sally and John are listed as reviewers.
Sally is busy finishing her Appium functionality, but she has enough time to perform a quick review of the pull request, she examines the code and approves it, John performs a review also. The pull request is approved and makes it into the master branch.
Sally now wants to commit her work to master, she performs a rebase and finds that James modified one of the classes she was working with. She reviews it and merges it manually to ensure there are no compatibility issues. She runs the unit tests to ensure everything passes. It seems fine. She commits to her branch and starts a pull request.
John and James now review her work, approve it and merge it into master.
TeamCity would then build their respective features and deploy them to Artifactory as NuGet packages. These are then available to anyone in the organization from the private NuGet repository URL.
This way features can be developed collaboratively, tested and deployed and consumed by people in the organization.
Once the code is merged into Master, the theory is that you should be able to close out the Jira task that the feature belonged to, the feature branch should be able to be deleted and cleaned up. As it is no longer relevant - since its code now exists in master.