At its simplest, source control is a system that records changes to a set of files over time and lets you see older versions.
Let’s see how this would work with two network engineers sending scripts back and forth.
Kevin needs help from senior network engineer Matt. Matt has an old copy of a script that configures a router, and asks Kevin to send over what he changed. Kevin zips up his changes and emails them over. Matt unzips those changes and copies the changes into his working directory.
Matt is a bit surprised at what he sees! This Kevin guy has some potential, but Matt finds a setting that needs to be changed. Matt zips up his changes and sends them back over to Kevin. The script is run with both Kevin and Matt’s changes on a set of test boxes. The change script worked, and it’s now included into a set of scripts that will be run on the next maintenance cycle.
What if we automated this process? Instead of manually zipping up a set of files that Kevin and Matt changed, we automate taking the differences and compress them into small packages that can be pushed and pulled from different locations. If updated scripts need to be run, or a third engineer needs to catch up on the most recent changes, all the small packages can be pulled down and decompressed to a local directory.
Git is a free and open source Version Control System, and this is exactly what Git does. Once you start using Git in a directory, you will see a “.git” folder. That folder contains some setting files, but it also contains all the compressed differences between commits.
After installing Git, you can initialize a directory with “git init”. This will turn the directory into a Git repository by adding the .git folder. You can start tracking a file or a set of changes to a file with “git add”. This is typically called staging.
Then you can compress your changes, add them to a package (or more commonly called a snapshot) and save them into the .git directory with “git commit”. If you get stuck or don’t know what to do, you can get current info with “git status”, and get more help with “git help”.
To send and receive from remote locations, you can start by initializing a directory and copying remote files to your local device by running “git clone”. You can use push your local changes to the remote directory with “git push” and pull remote files with “git pull”.
Branching is just having two different working sets of code. As scary as it might seem at first, this is pretty common. Having multiple copies and merging branches together allows you to work on things in parallel. Let’s go over a pretty typical workflow.
The first time you initialize a git repository, you’ll only have one branch called “master”. Make a branch with “git branch” and call it “development”, or “dev” for short. Make your changes in dev. Once you feel like those changes have been thoroughly tested and are ready to be applied to the production environment, you can and merge them into master with “git merge”.
You can create branches off of dev and merge them back into dev. If you can, try to only merge changes into the branch that you merged from. So, dev merges into master, and projects branched from dev get merged back into dev before going to master.
Adding all your configuration change scripts into git allows multiple people to edit those files, allows collaborators to work on multiple projects in parallel, and keeps track of version history and changes. This is a great start, but let’s think a bit out of the box.
Is one switch working while another is not? Try dumping the two configs and doing a diff between the two with “git diff".
Try creating a daily cron job to dump network config settings to a git repository on your machine. Did something break in the past week? You can use “git diff” between the tracked versions and find what changed.
Using source control to share and maintain network configuration settings is one of the building blocks of network automation. If you’re interested in applying this to your own processes, there are multiple platforms to choose from for source control. GitHub and Bitbucket are two of the most popular, but there are many alternatives such as Beanstalk, Codebase, Gitlab, and more.
Here’s a few getting started guides you might find helpful: