Mark III Systems Blog

As a systems admin, with years of experience writing code, here are some of my thoughts on Source Control Management.

Using a scratch and defined repository

Throughout the years, I have written many a quick-and-dirty script or function to augment a process, standardize input or normalize data. These usually get tossed around the enterprise on a scheduled task server or just lay around on a share somewhere. The source gets distributed, persons may take this code and copy it to their own run location and there it lives. I expect that for the most part this is how many of the Sysadmins still operate today. I am guilty of the old… script1 becomes script1-somedate or script1.bkp and the new script replaces the old. I suppose I don’t have to explain how this can create major support challenges.

As Microsoft has made Powershell essentially the requirement for daily activities it is even more important to keep these tools around and share them throughout the enterprise and or the community. To also make sure that the development process is documented and controlled. That people can go to a repository for the code and assure that they are receiving the latest version. That they can also fork the code and adjust while also being able to reference back to the upstream source.

Insert Source Control Management – An essential toolkit for today’s Sysadmins.

Source control management has been around for a long time and was once simply a tool for developers. Today admins write scripts that are just as important to the enterprise as full blown homegrown applications. Building a relatively simple process for Sysadmins to use for source control brings a major value to the enterprise.

I personally use GitHub but there are many more available. These tools have one thing in common. They store and track source code for developers.

I keep a scratch repo on GitHub where I usually begin development. This repo has all kinds of things and all kinds of languages. It’s mostly an incubator where I begin to write Q&Ds and get something off the ground. The IDE isn’t very important but one that can integrate with your SCM is super helpful. I use VSCode. You will also need to install Git.

Here is my basic process…

1. Obtain a GitHub account
2. Create a new repository

Be creative with the name if you would like. I go with Scratch

• Clone the repo local - I keep a folder in My Documents directory called REPOS

• Change directory into the REPOS folder and clone your repo to the local folder
• Use the link of the “Clone or download” button from the GitHub repo

• From the command line, as REPOS as your working directory issue

git clone <url copied from new repo>

This will create a folder in REPOS called scratch (assuming you named your repo scratch)

At this point you have a local copy of the repo and you can start moving your “scripts” into this folder.

Files in the repo will need to be marked for tracking.

• Add your files to the repo

git add <filename> or git add .

The period will add all files in the folder for tracking whereas the filename is more specific to track only the files defined.

For now stick with “git add .” if you like, especially for scratch.

• Commit the changes made to the files in scratch and make a comment on the commit (i.e. Initial Commit).

git commit

• Push the changes to the repo.

git push

Now you have a scratch repo where you can work on your Q&D scripts and track changes. As you add new files you would simple add the new file for tracking, commit and push. In scratch it isn’t to important for me to be strict on the commit verbiage as I move them out pretty quickly once I know this is something that is going to “stick”.

As your “scripts” mature or if you want to share them. You would go through a similar process to create a new Repo designated for the “scripts”. This repo should be named appropriately to help identify the purpose and contents.

Move your intended scripts to the new repo and “git add”, “git commit”, “git push”.

You can then either make this repo public or add collaborators.

Other advanced SCM topics are beyond the scope of this write up.

I always keep Scratch private and I do not add collaborators

Conclusion:

Today it is essential that all Sysadmins use a SCM to store their code. This code should be kept in repositories that are available for tracking changes, issues and requests for enhancements. There are many other techniques and processes for using SCM. I wanted to keep this super simple and give a quick rundown of how Sysadmins could adopt SCM into their current development processes.

Look for a future post on VSCode and how I use it with github and git bash.

Warning:

SCMs will track every change to your code. If you hard code a password or any credentials your development process they may be written permanently to your SCM. This is bad. Avoid placing valid credentials in your code.

Here is some help if you happen to accidentally write sensitive information into your SCM if it is GitHub.

https://help.github.com/en/articles/removing-sensitive-data-from-a-repository

originally posted: http://bryan-ops.com/2019/10/getting-started-with-source-control-management-for-the-sysadmin/