I previously thought of source code control as just another piece of software--an application that you use that manages the versions of your code. SourceSafe, SVN, Git, Team Foundation Server, there are many options for software or services that will take care of source code control / version control for you. As long as you "use" one of those solutions, you're all set.
But today I learned a pretty significant lesson. It is probably obvious for many people, but it was a bit of a wake up call for me.
"Source code control" is not Git or Team Foundation Server or VisualSVN. Those are just tools that are just one piece of a larger process. And regardless of which tool you use or how great that tool is, if you don't have a solid, resilient process surrounding that tool, you will likely experience breakdowns.
Last week I sent out a new version of a Dynamics GP customization. The new version only had a few minor changes to enhance error handling--I added several try/catch blocks to try and track down an intermittent error that the user was seeing.
The customer tried the new version today, but they quickly noticed that a feature that was added over 3 months ago was gone. Uh oh.
While making the latest error handling changes, I noticed some oddities. The last release was version 1.30, but the projects in Visual Studio were still set as version 1.21. I checked the version 1.30 files that were released, and they were versioned properly, so something happened that caused the Visual Studio projects to revert to version 1.21. I wouldn't have done that manually.
I then checked my Documentation.cs file that I maintain on all of my projects. The last note I had was for version 1.21. No notes on version 1.30. That's not like me, as that's usually my first step when updating a project.
I then checked the Git branch of the project. Visual Studio was using branch 1.31, but it was only a local branch and hadn't been published to BitBucket. 1.30 was published, but it didn't have any notes on version 1.30 in my local repository or on BitBucket.
I checked the Commit log on BitBucket, and that left me even more puzzled. I didn't seem to have any commits acknowledging the version 1.30 release.
I see check ins for v1.2 and v1.21, and the new v1.31 release, but nothing for v1.30.
Somehow I had produced a version 1.30, with correct version numbers in Visual Studio, which produced properly versioned DLLs, which got released to the customer, but I have the following problems:
1. I either didn't update my Documentation.cs file, or it somehow got reverted to a prior release, causing my changes to be wiped
2. Somehow my Visual Studio project version numbers got reverted from 1.30 to 1.21
3. I can't find any record in the code for the version 1.30 changes
4. Despite having v1.30 and v1.31 branches in Git, I didn't see any changes when comparing them to each other, or to v1.21.
5. I can't find any evidence of a version 1.30 release in BitBucket
The only evidence I have of a version 1.30 release is the separate release folder I maintain on my workstation, where I did document it in the release notes.
And I see that the DLLs were definitely version 1.30, so I'm not completely imagining things.
So somehow, I managed to make the following mistakes:
1. Potentially reverted my code to a prior release and lost some changes
2. Didn't clearly perform a v1.30 check in, or if I did, my commit comments did not indicate the version number like I usually (almost always) do
3. Created a v1.31 branch for an unknown reason that I didn't publish and didn't document.
4. Somehow made what is likely a series of several small mistakes that resulted in the versioning problem that I'm trying to fix today.
The most frustrating part is that it isn't obvious to me how such a roll back could have happened.
And all of this despite the fact that I'm using an excellent IDE (Visual Studio), an amazing version control system (Git), and a fantastic online source code management service (BitBucket).
My problems today have nothing to do with the tools I'm using. They clearly stem from one or more breakdowns in my process. And this was just me working on a small project. Imagine the complexities and the mistakes and the issues that come up when there are 15 people working on a complex development project?
So today I learned that I have a process issue. Maybe I was tired, maybe I was distracted, but clearly I forgot to complete multiple steps in my process, or somehow managed to revert my code and wipe out the work that I did.
I now see that I need to invest in my process. I need to automate, reduce the number of steps, reduce the number of manual mistakes I can make, and make it easier for me to use the great tools that I have.
I don't know how to do that yet, but I'm pretty sure that much smarter people than I have had this same issue and come up with some good solutions.
Steve Endow is a Microsoft MVP
for Dynamics GP and a Dynamics GP Certified IT Professional in Los Angeles.
He is the owner of Precipio Services, which provides Dynamics GP
integrations, customizations, and automation solutions.
No comments:
Post a Comment