One of the hardest things in software development is naming things. When designing your architecture, creating a method or adding a new variable: naming it correctly is half the work. This is why design patterns that create a shared vocabulary is so important.
But naming doesn’t only apply to our code and designs. We use all kinds of tools,. techniques and practices that need to have a name and some are around for quite a while.
However, that doesn’t mean there isn’t any confusion on naming those things.
Version control or source control?
One particular area of naming problems is around source or version control. If you think about it for a moment, what term are the people around you using? What do you use? And can you describe the differences between those two terms?
For example, I was privileged to hear the following discussion at a customer:
Developer: we would like a way to bring the environment configuration under source control so we can version and test them
Ops: You don’t have to test our environment configuration. That’s our job. Our configuration scripts are not code so we don’t want to store them in source control.
Is it true that your source control can only be used for actual source code? Is that the reason we started using source control? Or do you use it for all your artifacts like documentation and configuration, build and deployment scripts?
When moving to a DevOps culture, discussions like these are not uncommon. Making sure that you have a shared vocabulary with all stakeholders really helps in getting your communication running smoothly.
Switching from source control to version control is a small and simple step in that direction.