“I have been working in Software Configuration Management area for almost last 5 years. I have administrated some of the efficient Version Control Systems like “VSS, Dimensions, and TFS.” As a part my daily experience in this area, I have learned some best practices we should follow for a quality software development.
I have documented these best practices and sharing with you all. I hope you get something good out of it.”
Version Control Systems: A Version Control System secures your artifacts, tracks the changes to the artifacts and provides you many features for a quality deliverable. The Version Control System enables everyone in the team to work more efficiently in a collaborative way.
Version Control System is a common requirement in all modern software development projects. It not only provides a mechanism for checking in and out the source code from central repository but also it keeps track of which changes were made, who made those changes, when & why they were made. Modern Version Control Systems provide many more additional features like efficient branching & merging methods, builds features, testing & deployment features etc.
In order to be successful using a source code repository as part of the software development process, the development team must agree that they always refer Version Control Systems for using the artifacts. All developers must be in the habit of following all good practices when using a version control system.
Please refer the following best practices I have documented below:
Following are the best practices all developers should follow.
1.) All developers must use Version Control as their source code repository.
All development teams must have an efficient Version Control System for securing their work. And the first step should be to add the source code to Version Control systems at the earliest. No member should be allowed to work offline of Version Control systems. All members should reference the code for Version Controls systems and make sure that the project is online.
2.) Developers should not circumvent Version Control.
In order to modify any files, developers must check the files out from Version Control.
I have seen in practice that many developers avoid/skip using Version Control System for checking-out/checking-in the code. Many developers checkout the file but they don’t checkin the changes on regular basis, which is very bad approach. Consider an example, you checked out a file three days back and made lot of changes but you didn’t check the changes in and now unfortunately your machine gets crashed. What you will do? So get into the habit of always using Version Control for checking out the files and do the regular check-ins.
3.) Developers should not change the attributes of files on their file system.
Developers should avoid changing attributes of files on their file systems because when they will check-in the changes, these changes will also be saved in Version Control. Changed attributes may behave differently for other developers, when they will use these files.
4.) All code / executable should originate from Version Control and should be applied to development, test and production systems using automated methods. Developers should not modify any of these systems manually.
5.) Avoid checking-in the unsuccessful code.
Developers should not check in code that cannot be successfully compiled. Doing so would break the scheduled build process and delay the development cycle. This can create problem for other Team, working parallel on the project. The best practice is always do a local build/compile your application before checking in and if the application builds successfully, then only check-in the changes to code repository.
6.) Perform regular local & server builds.
Build is process of validating, compiling, testing & integrating your code as a complete solution. A build process makes sure your code is well integrated and working what you are aiming for. Builds must be done on a regular basis. It’s always a good idea to have a dedicated team for build and successful build should be a top priority for them.
Make sure you regularly perform server builds additional to local builds. Server builds make sure that your application doesn’t have any local machine specific dependencies on code.
Implement efficient build plans for your application which should include Continuous Integration Builds, Scheduled Build and Ad-hoc builds.
Use efficient build tools. Many of the advanced build tools automatically fire a server build whenever you commit the changes to code called CI builds. It helps you in identifying early warning of broken/incompatible code.
7.) Create a separate common folder for Dependencies.
If we are using any Third Party DLLs/Components, then we should have a common folder in Version Control (Ex. Dependencies or Library) and refer the components from there. I have seen many developers add shared components to all the projects and create different copies of same components, which is not at all a good practice. Instead, we can have a common folder for Shared/Third Party components and refer them.
8.) Avoid storing Binaries in Version Control.
It’s a good practice to avoid adding binaries (like code generated files like .dlls, .pdb etc.) to Version Control, these eats a lot of space. Also these are not a source code, these are just generated binaries by our code, which we can do anytime, we just need to build our source once and we will have these. So only add binaries, if it’s really needed for your project.
9.) Don’t create unnecessary branches.
Before creating branches, pay attention – every branch you create does have a cost so make sure you get some value from it. More the branches you will have, more time/cost you will need to spend on Merge conflicts and additional testing. So only create the branches necessary for your development efforts.
10.) Avoid changings source in Main line.
While creating directory structure in Version Control systems, make sure you have one main line/base line folder which stores your main code. You must avoid direct changes in this code. This main branch should be a stable snapshot of the product and it’s the latest working copy which can be shared with Customers, QA or external teams.
Always create needed branches, make the code changes are done in those branches and after the successful build merge the changes using proper Reverse & Forward Integration with Main line. In this way, we will make sure Main will always have a good/working code.
