It seems that there are so many different ways to accomplish version control for your code these days. There are countless version control systems (VCS) out there today, and they all seem to deliver what you need in different ways. Some of the solutions are built-in to other software, some allow you to install your own server for source control, and some allow you to use the product through the browser, and with various pricing models, how are you supposed to choose the BEST solution?
The client I currently work with is going through a major shift in their processes. They want to tidy up their deployment methods by establishing a code baseline, and, most importantly, they want to limit mistakes, especially when moving code to production. Who doesn’t want this?!?! Shouldn’t this be a necessity in the modern digital world of business where more code is being developed and more data is being stored and analyzed than ever before? Organization and a process-driven approach has to be front and center for companies to scale in this digitized age.
So my client tasked my team to come up with various options that could work for them in their environment. As long as the solution could establish a baseline of code where developers could pull from a repository (or preferably a branch of the repository) it would satisfy the need. So I set out on a journey to analyze the client’s current environment, explore the products they already use, and present viable additional options.
Because my client already had an implementation of Apache Subversion (SVN), I started there (I later found out they also had an implementation of Microsoft’s Team Foundation Server (TFS)). Up to this point, I had good experience working with Git repositories, usually hosted on GitHub, so SVN was not a huge leap for me to get used to other than the fact that SVN is a centralized VCS and Git is a distributed VCS. Regardless, SVN employs a similar model as Git where they have a branching system and a trunk for the code baseline. I thought, “Great, if my client already pays for this, let’s pull the trigger.” In typical fashion, the process was not that easy though. The client wanted more options than just SVN, so I naturally began to compare GitHub to SVN to add some variety since I had worked with Git on GitHub in the past and I saw a large part of the IT industry moving towards Git repositories as the standard.
I began a comparison and proof of concept of both VCS solutions. But somewhere around this point is when I found out the client also had an implementation of TFS. So to really get the full spectrum of options, I analyzed, compared, and created a proof of concept of TFS to go along with GitHub and SVN so I could understand all 3 products. Finally, I had heard of another up-and-coming product that could work for the client called CrossVista. CrossVista originally made a name for itself by creating solutions for people in the integration space like webMethods, but they had expanded to connect with countless more software solutions since then, and I had heard great things about the product from peers in the industry so I wanted to consider them.
The main difference with CrossVista is that CrossVista provides an entire packaged solution not just for version control, but for process driven environments, automated deployments, automated testing, dependency checking, and the list goes on. If CrossVista was implemented in my environment, it would not only solve the immediate need of the client, it would go so far beyond to address pains they didn’t even know they had and would help bring them out of the stone ages of maintaining spreadsheets, manual testing, and manual deployments. Continuous Integration (CI) was another major industry push, and CrossVista provided a great CI solution by connecting to all instances in all environments, performing dependency checking, running tests, and deploying code; all of this done upon request or performed automatically and packaged up in one beautiful solution that could do it all. Not to mention, CrossVista is the only product (at least that I know of) that does not just store files in a repository, it recognizes the files for what they are. For example, CrossVista could tell that a plain old XML file was really a flow service in webMethods, which makes the entire solution that much better for running dependency checking, checking differences between revisions, etc. I definitely wanted to include CrossVista as an option, but was aware that it could intimidate the client because they wanted to walk with a VCS solution before they could run with the entire solution they truly needed.
Finally, I had 4 solutions that I was juggling, each of which could work great for my client’s needs. How would I ever choose the “right” VCS for the client? After creating a proof of concept with each solution so I could understand the technology, I proceeded to create a breakdown of each solution to lay it out for myself and for the client. I wanted to incorporate features, benefits, pros, cons, and of course cost in the breakdown. I came up with something like the following in a table format (this does not represent the real breakdown and does not reflect cost of the product in any way).
What led me to this breakdown and my recommendations to the client came in these steps:
In my story, I was heavily leaning towards implementing GitHub and CrossVista. I say “GitHub and CrossVista” because CrossVista can connect to external repositories such as GitHub. Since I had worked extensively with GitHub and really liked the product, my idea was that the client could first address their glaring problem by integrating with GitHub and establishing a code baseline right out of the gate. Once they were comfortable with that, CrossVista could be brought in, hooked into the GitHub repository, and then implemented in a phased approach where users could still use the GitHub repository until the entire solution with CrossVista was operational.
There were a couple of reasons why I was leaning away from TFS and SVN and towards GitHub and CrossVista. TFS seemed very useful, and I liked the idea of it, but in my client’s environment, they wouldn’t get the full use out of it because they were not employing any particular development methodologies such as agile development where they were creating scrum boards and assigning stories to developers. TFS seemed like it would go to waste if implemented in the environment at the time. Then, for pure VCS solutions, it came down to SVN vs. GitHub, and this was pretty simple for me. Since I had worked so extensively with GitHub and knew the product well, I could easily guide the client on the implementation and use of the product. Not to mention, I did not like that SVN was a centralized VCS, and that a large part of the IT industry was moving towards Git. So while GitHub, SVN, and TFS could all do the same thing basically, I enjoyed the experience of GitHub better. Finally, since I liked GitHub and CrossVista so much for all of the reasons I state throughout this post and more, this is the way I was leaning towards with the client, and since I was biased a bit, I could see them picking up on my excitement for the products I was excited about.
As a consultant, I typically cannot tell the client what to do unless they ask me to because they ultimately have to live with those decisions once the consultants are gone. All said and done, this story is still in progress so I don’t have an ending for you… yet. I am currently at step #8 above where I have presented the breakdown of each option to the client and they are talking internally. Stay tuned for updates to this post about my findings in the future.
This all begs the question: can you choose the WRONG version control system? I truly believe that any of the above options, and many more, could work great for my client, and for most companies/organizations/people. However, are there better options than others? Are there VCS solutions that offer more features and benefits than others? Does the cost justify the benefits? Of course there are better solutions than others! However, these questions all have to be answered on a case by case basis and depend on a variety of factors such as budget.
Regardless, I believe every company in the modern digital world absolutely needs some form of a VCS and a process-driven environment to stay competitive. Good luck finding the right solution for YOU!
If you have a pressing business challenge, we would love to hear from you. Our team of process technology experts is eager to transform your needs and ideas into a streamlined solution.
1624 Market Street, Suite 202
Denver, Colorado 80202