One of the great benefits of object oriented programming was supposed to be easy code re-use. In the past, I’ve always found it somewhat less easy in practice. I have been using Subversion for a few years and that led me to a choice of two methods of code re-use:
- For third party code, get the binaries and commit them to version control in a \Lib or \Dependencies folder. This was necessary to get continuous integration builds to work without having to install myriad third party stuff on every build agent.
- For in-house code, use SVN Externals and re-use code at the source level. Care has to be taken to use either a tagged version or to specify the version explicitly in the Externals property, so that checking out old versions works as expected.
This worked but had some practical issues. For example, it becomes hard to keep track of the third party projects being used and to keep on top of updates to both internal and external code. When using SVN Externals, I found that I tended to edit code in the SVN Externals projects and then lose those changes the next time I did a clean checkout. Also, committing binaries into my source control really goes against the grain and I never liked doing that.
Image may be NSFW.
Clik here to view.
Over the last couple of years, interesting things have been happening and I’ve evolved new ways of doing things. It is really an exciting time to be a software engineer! First, a couple of years ago NuGet appeared on the scene and it was quickly obvious to me that it was something worth looking at. Soon, I was consuming all my 3rd party code via NuGet. We use TeamCity (from JetBrains) for our CI builds and when JetBrains added direct NuGet support to TeamCity, there was really no going back.
Then, about a year ago, I started using Git for version control instead of Subversion. I had delayed using Git for a long time because I just didn’t like the command line tools. Perhaps I’m unusual in that respect by my mind works visually and if I can see-and-click I always find that better than remember-and-type. The tectonic shift here was when Atlassian released Stash, a behind-the-firewall Git server with easy web-based administration, and SourceTree (a free GUI-based Git and Mercurial client). With decent professionally supported tools on both server and client, I committed (as it were) to Git as my VCS of choice.
Using Git soon led me to realize that I needed a different approach to code re-use, since I no longer had the facility of SVN Externals. I know Git has the ability to use Submodules, but I was never all that happy re-using code that way. I started to realize that NuGet would provide a solution here – that I could use it to consume my own in-house code, not just third party libraries. Once I had made that leap of reasoning, then I quickly had all my internal projects split out into their own repositories in Stash, each with its own build configuration in TeamCity, and using TeamCity’s built-in NuGet server to publish successful builds as NuGet packages, which I could then re-use in my other projects. I now do all of my code reuse using NuGet, mostly at the binary level. I can easily keep track of updates (NuGet tells me) and I never have to commit any of those binaries into version control.
It has taken a slow but constant evolution over the course of about two to three years, but now I have a better way of working that meets all of my needs. It seems obvious now looking back, but much of the technology I use today wasn’t available as little as two years ago!
Related post: how we do CI Build with Team City, Git and the GitFlow workflow
