In February 2012, I installed VisualSVN for source code control.
For years I had just been zipping up my entire projects with date and time and version file names, and archiving those copies. It was simple, low tech, and actually worked well. The only downside is that I would end up with dozens and dozens of zip files over time and I would have to back up those archives. By 2012, I finally gave in and decided to implement some type of source code control.
I had looked into Source Safe, but it was ancient, so I looked into its replacement, Team Foundation Server. While I have heard some good things about TFS, it seemed like total overkill for me. I didn't need lifecycle management--only source code control, so I kept looking.
While looking into open source options, I found VisualSVN for Windows, which looked like a great fit. It integrates seamlessly with Visual Studio and utilizes TortoiseSVN to work with Subversion for Windows, so it's perfect for managing my .NET projects. I've been using it for over two years now, and it has been fantastic. It's extremely simple, very light weight, and does exactly what I need. I can submit code, retrieve code, view and compare prior versions, and have a centralized location where all of my code is backed up. It has worked flawlessly.
Today was probably the first time that I REALLY had to use VisualSVN. I had poked around some of the previous versions of certain projects or files, but I don't think I've ever had to actually revert to a prior version. Until today.
A customer noticed an issue with a very complex HR + Payroll integration that I developed. They believed that the issue started some time in March, but they only noticed the symptoms today. I've been working on the project for the last week making numerous changes that haven't yet been fully tested, so I no longer had the old code, and couldn't make a quick fix to release to production.
But, I was able to open the VisualSVN repository browser and see when I had checked in changes and see when I had created different versions of my project.
I saw that the last release was in January, but didn't recall if it was ever released or when it might have been released to production.
Using VisualSVN I was able to look at each of the changes made in January and compare them to the prior code and my current code. I then pulled down a separate copy of my code from the January 10th release, found the bug, fixed it, recompiled, and sent the client a version 1.24. It only took about a few minutes once I figured out what I needed to do. The one challenge is that I so rarely look at my old versions that I had to figure out how to retrieve the old code from VisualSVN. But it was a simple process and let me quickly fix the problem.
If you aren't using source code control for all of your Dynamics GP customizations, I strongly recommend that you implement a solution. Having worked with clients and partners that could not provide a copy of old source code, I'm going to venture to guess that most Dynamics GP partners do not use any type of source code control. And I would even guess that if a developer quit or was unavailable, most partners would be unable to find and retrieve source code. I've seen it several times, and it doesn't have to be that way. It isn't difficult to implement source code control.
Update: I don't currently do Dexterity development, but it appears that there is a Team Foundation Server (TFS) provider for Dexterity. If you do both Dex and .NET development, TFS may be a better choice than VisualSVN, as it would be a single repository for both.
http://blogs.msdn.com/b/gp/archive/2011/03/10/feature-of-the-day-tfs-source-control-provider.aspx
Steve Endow is a Dynamics GP Certified Trainer and Dynamics
GP Certified IT Professional in Los Angeles. He is also the owner of
Precipio Services, which provides Dynamics GP integrations, customizations, and
automation solutions.
No comments:
Post a Comment