This last month I put together a presentation on version control. As far as I’m aware, everyone I work with uses some form of version control. My purpose with the presentation was many fold. I and a lot of thins that had been prrcelating that I wanted to think about and express. This as an excellent opportunity for that.

Git vs SVN

One thing I know is a sore point for some developers is the idea that git is taking over. There are a lot of people espousing the idea that git is better than svn in every way. This has created a conflict culture because there are a lot of developers making good use of svn and most have heard the primary arguments in favor of git and found the arguments are not compelling enough to motivate a switch.

This is okay.

There is no war on centralized version control, and if there is, the only people pushing it are dumbasses. (This coming from someone who was one such dumbass a couple years ago.)

It’s anti-agile to prescribe something like that. Each team works differently and needs to determine for themselves if the benefits outweigh the costs.

Continuous Delivery

Recently I read a book called continuous delivery. It is a comprehensive blowhard description of how devops “needs” to be. It covers testing strategies, and branching strategies. While a lopsided view of the world, it offered potential solutions that I have found fascinating.

Trunk Based Development vs Feature Branching

This offers not just a workflow that allows for potentially faster delivery, but also a realistic way to use SVN. An alternative to the branching hoopla around distributed systems.

DevOps

It also gave me an opportunity to talk about DevOps in a reasonably safe environment. It’s a political word at the moment and while I don’t want to get involved in that, I do want to talk about the DevOps movement.

This movement is about working together. Communicating on a level that hasn’t classically been done. It’s there because a lot of the problems we face are due to the fact that in our workflow, we develop a product and throw it over a virtual wall to operations to “handle”. They don’t understand what we need done and we don’t understand what they need done. It’s a matter of sharing knowledge and searching for a deeper understanding of what we’re doing. It’s hard because we don’t want to spread ourselves thin, but in order to deliver a quality product, you have to be more than just a cog in the machine. You don’t have to know exactly “how” to do everything, but you have to have a basic understanding of “what” is happening.

But I digress, I was able to tie this in to version control by talking about how DevOps is also concerned with automation. Creating scripts to do all parts of the deployments. These scripts, this automation needs to be in version control as well. They “can” be in the same repository, or they can be in a separate repository. But managing dependencies, flipping all the right switches, needs to be maintained in much the same way code is controlled. Because it is code.

Database Version Control

And of course, you can’t talk about Version Control without talking about database version control… but this one requires its own article.