ALM - Source Control
Source control, or revision control, is part of almost every developers daily activities. Some days, it is their only activity. Especially those still using Visual Source Safe. :) Yet it seems that many of us have an extremely hard time with this vital software development tool. I believe this is because of two reasons: 1) it is hard! 2) we are never really taught source control in school.
My first experience with source control was when I started my internship during freshman winter break. Never once in the next 6 years of schooling was source control taught. We had a few classes which used source control, but it was assumed that everyone knew how to use it. In my experience, developers typically are shown how to use source control during their first day or two on the job by another developer, after that it's "don't break the build".
So why is source control so hard? Well you have a lot going on. Ask any developer who has ever worked on a project with an occasionally connected system and they will tell you that the master to master synchronization between the two data sources was the most complicated aspect of the system. What was meant to change? How do I handle conflict? Was this deleted from one system or created in another? To manage this the developer usually tries to accomplish a small set of synchronization rules, but leaves the rest to the user to decide what the intention of the synchronization was. This means that the users need to be taught how to use the tool. In our case, as developers, there are very few rules and the onus is on us to correct anything the system can't figure out.
In addition to source control being hard, we have made it harder by implementing it two different ways, exclusive check-out/in and version merging repositories.
Visual Source Safe is an exclusive source control system which means that the system only allows one person to check-out a file; all other users can read the file but not write to it. Once the user is done they check-in their change set. This is the 'safest' form of source control to prevent against unwanted sides effects within a single file. Most developers on the Microsoft platform are used to this version.
Team Foundation Server (by default) and Subversion are version merging repositories. This means that everyone has the ability to write to their local files. When the developer is done with their changes they merge them with the current version within the repository. Because you do not exclusively check out files you aren't ensured that the file hasn't changed since you started working with it. The developer, that's you, must carefully merge the two files together. The source control merge tool checks for conflicts at the line level. This means that if a given line is changed in either the local or server copy the source control will accept the change automatically. If both lines have changed, a merge conflict is logged and the user will be prompted to correct the issue. I will be going into more detail on how to handle merge conflicts in a later post.
One of my roles within Catalyst as an architect and our TFS admin has been to define a source control process for projects moving forward. I will also be working to educate our developers on that process and to depend their knowledge of source control usage. This is going to be done through my blog and several presentations given during Lunch & Learns. These presentations are also available to our clients, if they would like to attend.
When I first create a project in Team Foundation Server, I immediately create the following folders under the root of that source control repository:
The trunk is where you build and deploy from, no development is done in the trunk. Developers when assigned a task create a branch under branches, sometimes called dev, for their development. This is where they begin to code. This allows them to check code into the server before they have completed their tasks and it will not impact other developers or the build. This also gives architects or team leads to ability to review code before it is merged into the trunk.
After a developer is done with a task, they merge their branch back into the trunk. During this time they check to ensure that the code they are checking in doesn’t reference any code that has changed, due to other developers merging into the trunk. Building and running automated unit tests are the easiest ways to due a quick gut check. In larger projects, someone or even a team is responsible merging into the trunk.
When the deployment team goes to make a release build they branch the trunk to releases. QA and support begin working with the release branches so not to impact new development. Subsequent patches when released are then branched using a major\minor\revision hierarchy. If a bug is identified to affect the trunk, the code which resolved the bug is also merged with the trunk.
From a testing point of view, unit testing is performed at the branch level before merges can be performed. Complete unit testing and functional testing is done on the trunk nightly. The trunk is also where most of the reporting is performed such as static code analysis, code churn, etc…