This excerpt from Joakim Verona’s "Practical DevOps" covers code control, including repositories like GitHub.
Terence McKenna, an American author, once said that “everything is code.” This is certainly true in the world of DevOps. Just about everything we build can be expressed through code, including:
- The applications that we build
- The infrastructure that hosts our applications
- The documentation that documents our products
- Even the hardware that runs our applications
Given the importance of code, it is only natural that the location that we place code, the source code repository, is central to our organization. Nearly everything we produce travels through the code repository at some point in its lifecycle.
But when everything is code you need to be sure you can control – otherwise things could get chaotic. There’s plenty of options for this that you’re probably already aware of. From GitHub and BitBucket to cloud-based solutions such as AWS and Rackspace, where you host your code will always be specific to your organization.
Roles and code
From a DevOps point of view, it is important to properly use a source code management tool as a natural meeting point for different roles and teams in your organization. While it’s easy to do this for roles and teams that are more technically and software oriented, it’s more difficult for other roles such as project management. But it’s important that everyone is on board.
- Developers live and breathe source code management. It's their bread and butter.
- Operations personnel also favor managing the descriptions of infrastructure in the form of code, scripts, and other artifacts. Such infrastructural descriptors include network topology, versions of software that should be installed on particular servers, and so on.
- Quality assurance personnel can store their automated tests in codified form in the source code repository. This is true for software testing frameworks such as Selenium and Junit, among others.
However, documenting of the steps required to perform various tasks can be more of a challenge. It is more of a cultural problem than a purely technical one, but if it is not done properly it will have a negative impact on what happens with the actual code.
Many organizations employ a wiki solution. But this is not failsafe as often there will still be documentation floating around in Word documents on shared drives and in emails. This is regrettable from a DevOps point of view, but every effort should be made to make documentation as accessible to all who need it in a centralized place.
Choosing a branching strategy
When “everything is code,” having a shared vision of what you are trying to do and the best way to do it is essential to maintain focus and control. That is essentially what a strategy is. But this isn’t just about vague ideas about “team work;” it has a practical application for how you deploy code.
A branching strategy is a convention, or a set of rules, that describes when branches are created, how they are to be named, what use branches should have, and so on.
Branching strategies are important when working together with other people and are, to a degree, less important when you are working on your own, but they still have a purpose.
Most source code management systems do not prescribe a particular branching strategy and neither does Git. The SCM simply gives you the base mechanics to perform branching.
With Git and other distributed version control systems, it is usually pretty cheap to work locally with feature branches. 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.
There are many well-known branching strategies. Vincent Driessen formalized a branching strategy called Git flow, which has many good features. For some, Git flow is too complex, and in those cases, it can be scaled down. There are many such scaled-down models available. This is what Git flow looks like:
Git flow is a centralized pattern. It's reminiscent of the workflows used with Subversion, CVS, and so on. The main difference is that using Git has some technical and efficiency-related advantages.
Another strategy, called the forking pattern, where every developer has a central repository, is rarely used in practice within organizations, except when, for instance, external parties such as subcontractors are being employed.
This is a chapter excerpt from "Practical DevOps," written by Joakim Verona and published by Packt. Starting Dec. 15, 2016 through Jan. 9, 2017, Packt will offer every ebook on its website for just $5. As a Network Computing reader, you can get early access to this offer on the Packt website by using the codes below: