While it may seem like having a Source Code Management strategy in this day in age would be a given, the reality is that many organizations have given little to no thought into their strategy. With the DevOps movement, having an SCM strategy has become even more important. Instead of trying to technically explain how the various SCM tools work and which is better, we will instead discuss some basics of why you need an SCM strategy in DevOps.
Looking at the SCM strategy from a DevOps point of view, we need to realize that our source code management tool is a natural meeting point for different roles and teams inside the organization. It tends to be a little easier for more technical and software oriented roles and teams, it’s more difficult for other roles such as business analyst and project managers. In order for the SCM strategy to be successful though, we must make sure everyone is on board.
While it may seem like getting developers on board with the SCM strategy would be fairly straight forward since they live and breathe source code, don’t be fooled into thinking you won’t have to work to get them on board. The reality is that traditional methods such as using long lived feature branches is ingrained in the way that developers have grown accustomed to working and getting them to use new SCM tools such as GIT which is a distributed version control system, and is designed to work locally with feature branches will take work. A feature, or topic, branch is a branch that is used to keep track of ongoing development regarding a particular feature, bug, and so on. This way, all changes in the code regarding the feature can be handled together. Most organizations are finding that GIT has generally become the go to SCM for DevOps, while the Git flow is a centralized pattern and is reminiscent workflows used with Subversion, CVS, and so on. The main difference is that using Git has some technical and efficiency-related advantages.
One of the big differences in a DevOps SCM strategy occurs in Operations. The new infrastructure code that is developed as part of the DevOps pipeline must be treated exactly the same as application code. This means that in addition to the infrastructure code being stored in an SCM, it must also be versioned and baselined just like application code. The reason we version and baseline the code is to try and drive out the possibility of Drift in our infrastructure. Drift is basically when we attempt to manage infrastructural descriptors, which include network topology, versions of software that should be installed on particular servers, and so on so that we do not get instance where our environments are not the exact same. When our environments do not match up and we have introduced significant Drift, then this becomes our main source of delivery costs and waste.
It would seem natural that as we move towards code based automated testing we would store this could alongside our application code and also version it, but the truth is very different. A critical issue of storing automated testing code in an SCM has to do with an issue we have previously discussed, Quality assurance. Few Quality Assurance in most organizations have any practical experience working with SCM’s and to make matters worse most organizations simply throw an SCM at Quality Assurance with no formal training. The results are generally pretty obvious when Quality Assurance starts working with an SCM, continuous merge conflicts and lots of frustration. If Quality Assurance is going to be brought on board with using an SCM then they need to be properly trained and mentored, this is even more pronounced when Specification by Example tools are introduced into the equation.
One of the largest hurdles in an SCM strategy revolves around how to document all of the steps required to perform various tasks. Organizations need to understand that this part of the SCM strategy needs to emphasize tackling cultural issues and is not purely technical one, but if it is not done properly it will have a negative impact on what happens with the actual code.
The majority of organizations have attempted to employ solutions such as Wikis and other team based documentation tooling. The problem is that in most organizations this is not a failsafe as often there will still be documentation floating around in documents on shared drives and in emails. This is completely wrong from a DevOps point of view, instead the documentation should be stored in the organization’s central SCM where it is accessible to all who need it.