Use Version Control for Everything
Use Version Control for Everything
Just a brief and friendly reminder that version control shouldn't stop at code, but should extend to every part of your infrastructure.
Join the DZone community and get the full member experience.Join For Free
Version control is an important part of file management on every software development project I've ever worked on in the last two decades, regardless of the methodology. I've used Subversion and Git and several others in the process of building software.
I always find it a bit surprising that other industries don't use version control nearly as much as we do in the software industry. For example, I know several writers who know nothing about version control and they would benefit greatly from it. The same is true for several artists and graphics designers who I know. I find that version control it is extremely easy to work with and gives me some key benefits.
Most people recognize that one of the major benefits of version control is being able to go back in time before a feature was added or create branches that allow you to test and change different parts of the system without making those changes permanent. Another advantage that I find from version control is that it allows me to see the order in which a system was built and very often that tells me a lot about how it was designed so that I better understand how to work with it.
I find the check-in messages are further useful when working with version control because they give me an opportunity to say what I did when adding a feature.
I remember I was teaching a class for a client who has a very major web presence but they had difficulty because there was some kind of discrepancy between their test environment and their production environment. They would test a release candidate and it would work perfectly but when they went to release it, it didn't behave as it did during testing and they were really confused by this because it was causing their customers issues.
They had developed the release strategy where they had two data centers and they would put a release candidate on one of the data centers and give it just 1% of the traffic. If nobody had any complaints then they would bleed another percent off and then another until slowly, over the course of three weeks the release candidate data center had 100% of the traffic and they would put the next release candidate on the other data center and start the process all over again. This was extremely painful and time-consuming.
I was teaching a class to their lead engineers and I was talking about how it's important to version not just all of your code but everything involved in the build including stored procedures and configuration files and database schemas and everything else that the build depends on.
After I said this, three of the students in the class got up and walked out of the room. I was afraid that I offended someone and later when I saw one of them on a break I asked if I said something wrong.
"No," one of them said. He said that they had issues with the consistency of their build environment and they wanted to verify that all the things that the build depended on were included under version control. They looked into this and I got an email from him a few months later saying that they discovered that some of the files that their build depended on were not included in version control and when they fixed this they were able to get a consistent build environment, which made it far easier for them to put release candidates into the field.
Now that their test environment was the same as their production environment they were able to put their tested release candidates into production with confidence that it would run. So remember, version everything that your bill depends on and try to keep your version control practices as frictionless as possible.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, called "Seven Strategies for Seven Strategies for Agile Infrastructure."
Published at DZone with permission of David Bernstein , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.