I have been using source control programs for a very long time. I believe the first one was Visual Source Safe (don’t laugh, it was a painful experience). Early in my career and throughout I have learned many good practices that I still use to this day. I will share them with you now.
If you are a .NET developer, before you check-in code, you should follow my workflow that is discussed in detail in this article. Developers that use other languages should still follow these rules, just the tools might be different.
Code in Source Control Is Golden
Do you like breaking the build or upsetting others in your team? I recently contracted with a company in which the not-so-experienced developers would break the build almost daily, sometimes for many hours. This caused many, many hours of lost work and delays in production releases. With this golden rule, never check-in code that that:
- Isn’t completed and ready for QA testing
- Doesn’t build
- Doesn’t pass all unit tests
I know that this should make sense to most developers, but I need to mention it since many do not. Thankfully, most modern-day repositories allow you to shelve changes (Team Foundation Server) or commit changes without pushing them to the repository (git) until it passes the rules above. There is even an extension for Visual Studio that will auto-shelve your code into a TFS repository every x minutes. Cool!
Don’t Check-In Binaries That Can Be Built
Some companies have a policy to put commonly used assemblies (DLL’s) into source control. If you own the source code, this should never be done. These assemblies should be built during the build process. There are several reasons why this policy can be an issue:
- Versioning can be the biggest issue. Project references always work better, especially for code that is changing often during the feature or bug that is being worked on.
- Is the common assembly folder in source control locked down so that only assemblies that have gone through the official QA and release process? I’ve never seen this done at companies. Usually it’s wide open to anyone who can check-in source. So, if someone makes a change, puts the assembly in the common folder it could break the code that others are working on.
The only DLL’s that could be checked into source control are from third-party companies like GrapeCity, DevExpress etc. I’m not a huge fan of this either since these DLL’s can be installed on the developers’ machines and the build machine. If the third-party DLL’s feature NuGet packages, then there is no reason to check them into source control.
If you want to share assemblies with other teams at your company, the best way would be to make NuGet packages and then host them on NuGet. Don’t want to put them in the “cloud”, no problem, a NuGet server can be hosted locally at your company. Creating NuGet packages with Visual Studio and .NET Core is super easy (just one check-box click). I hope that this feature is added for .NET Framework assemblies too in an upcoming release.
Don’t Check-In User, Temp or Other Files Not Used for Building
There are many files that should never be checked into source control. These are mostly user based files, temp files and more. What are they? The easiest way to find out is to look at the git ignore file for Visual Studio. Some of the common files to not check-in are:
- *.suo
- *.user
- *.vscc
- *.userprefs
- bin or obj folders
Some source control programs are good at this like Team Foundation Server or git and some are very bad at it like Perforce and PVCS.
Backup, Backup and Backup Some More
Far too many source control problems like Perforce and PVCS like to “clobber” your changes (wipe them out). I don’t know how many hundreds of hours over the years I’ve seen wasted by this. So, to help with this issue, I created a backup app that auto detects where all the sources are on your machine and quickly backs it up. The latest version even has a “turbo” mode that only backs up changed files.
I always run my backup program before I get the latest from source control. I also do it at the end of the day. I hate losing work and this app has helped me recover any code that might have been clobbered.
After You Check-In Major Code Changes
If you have not pushed any changes to the source control server in a while or have made a major change, make sure everything builds properly by following these steps. This needs to be done since “everything works on my machine”!
- Rename your root source folder on your machine. For example, I change my “src” folder to “src.bak”. Make sure Visual Studio is closed.
- If any projects use NuGet packages, remove the packages folder. This is usually right under your root source folder. I use a PowerShell script to make this easy.
- Go to your source control program or add-in and force a get of all sources.
- Fire up the solution you were working on and build. If there are errors, fix them, and then start this process over.
If you follow these 5 simple steps, your fellow team members will thank you! At one company where I worked, if someone broke the build, they would have to display a troll doll on their desk until the next person broke the build. In the past on the Microsoft Office team, if a developer broke the build they would have to stay late to babysit the nightly build process!
I guarantee this will help your team just like it does the teams I work for. If you are a .NET developer, please be sure to pick up a copy of my coding standards book. Please share comments you might have below.