Version Control that Works at the Speed of Business
A few months ago I wrote about skills a developer must have beyond simple syntax. Effectively using Version Control is one of those skills. Recently I have been considering different techniques for utilizing Version Control systems to allow the maximum amount of shared source while maintaining necessary separation of parallel initiatives.
What I mean by that last statement is that many systems share central components. They may also have different features sets managed by a different team or lifecycle, all needing to be merged back together on some schedule. So, how to you allow multiple feature sets to work separately, while reducing duplication of effort across teams?
Some companies like Microsoft branch on product line. I watched a demonstration from the Windows team years ago about how they had a different branch for each version of windows, all which was brought together nightly into a central build. This allowed each team to work independently while sharing much of the code across different versions of windows.
Linux takes a different approach where individuals make changes they wish, and must communicate to those responsible for a subsystem in order for it to be included in the master Linux code. That subsystem lieutenant then submits the change to those holding the keys to the main branch. Basically, anyone can change anything. But, if the work isn’t done well, it won’t become a part of the core code base.
Other companies may take a release/feature approach. A main branch is maintained. Features are branched off for work. On some release schedule, completed features are merged back into the main branch, or as they are completed, and finally a release is performed.
Agile teams simply branch off features and merge them back into the main branch when they are completed.
Other companies may have a branch for development, QA and production. Migration of code from one stage to the next is performed through merging of code.
Certainly there is an art to the use of Version Control that goes beyond that of sharing source with multiple developers, or managing the change of code over time. There is also the skill of organization, branching, and merging that makes your code repository an effective tool for managing the release of your software as well.
Do you have a version control tip you’d like to share? How about an opinion on distributed version control vs. centralized version control systems? An guidance you have found that will be helpful to those building their version control skills? Share your thoughts by writing to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Troubleshooting problems with log shipping in SQL Server 2008 R2
This article describes the problems you can have with SQL Server 2008 R2 log shipping.
Featured White Paper(s)
Key Management in the Multi-Platform Environment
Written by Townsend Security
This White Paper discusses the challenges … (read more)