PowerShell Tools for MSPs – Getting Started with Source Control Part 1

This post is part of a series. Skip to part 2

Hello everyone! Last week we hosted a webinar session that centered around very cool and useful things MSPs can do with automation and DevOps to make their day-to-day operations smoother. Part of that conversation was a VERY brief intro to source control using GitHub. We had some questions relating to that issue after the webinar ended so to build on that, I wanted to put together a post that provides a bit more comprehensive look at GitHub along with its underlying core tool, GIT.

Finally, to round out the post, there is the link to the webinar recording, along with the Q&A from the webinar below. Enjoy!

Introduction to Source Control

When I first started writing PowerShell scripts, I never thought that I would need to have my own Source Control platform. I figured that was for developers and saving my scripts to a folder would be enough for my needs. Well, a few years went by and as I began developing more and more PowerShell scripts, the management of my scripts became a mess. I ended up with a script folder structure like this:

Each time I wanted to test a new change I would put a “v#” at the end of the script, or rename it as “test”. I quickly found that I would lose track of what my script does or what each revision is for. Imagine this scenario but with a whole team of people creating and saving their own PowerShell scripts for their company. Therefore, having some sort of source control platform in place for your MSP is imperative to having a successful environment for developing automation.

There is a good chance that you have at least heard or seen a reference to Github within the past few years. Github is a popular web-hosted version control service that uses GIT. GIT is a source control system that was created by Linus Torvalds (the creator of Linux) who used it as his own version control for developing the Linux Kernel.

The greatest feature of GitHub is the community. Anyone is able to put open source code out on the web and have multiple people contributing and make it better. It really is an amazing concept and works incredibly well.

Getting Started with GIT

For me, the best way to learn is to get my hands on it, so let’s get started with a tutorial on using Git with GitHub. Install GIT here (if you need instructions for installing GIT look here). Create a free GitHub Account here, for this demo we will create a public repo which is free, if you want to start creating private repos then you can upgrade your account to a paid plan.

First, we want to create a new project. In GitHub that is called a “repo” or repository. In this demo, we will take one of our PowerShell scripts and save it to a local directory and then make it into a GIT repo. Below I made a directory in C:\repo\deploywindowsupdates and placed one of my PowerShell scripts that I’d like to upload to GitHub into the repo folder:

Now, open an administrative PowerShell console and we browse to the directory with the following command:

Cd c:\repo\deploywindowsupdates

Then, we run the following command to “initialize” or turn our directory into a git repository:

Git init

Now if we look into the directory, we have a .git folder with all our git files. These files contain all the information about our repository:

 

Now we can run the following command to see which files that Git knows are there. The notice at the bottom basically states that the file is there but nothing will be done with it unless we run a “git add”:

Git status

One of the hardest concepts to grasp when starting to use Git with your PowerShell scripts is the staging environment. A commit is like a “snapshot” of the files you have changed since the previous commit. It allows you to revert to previous points in time. But, remember this is a staging environment, so the process is to add the file to the staging environment and then commit the file.  So first we run the following syntax to add the file using “git add”:

git add C:\repo\DeployWindowsUpdates\install-windowsupdates.ps1

Now when we run git status we can see the script is added onto the staging environment:

Before we can commit our changes, we need to set up an identity so that Git can track who did what. So, we use the following syntax:

git config –global user.name “Luke Orellana”

Now it’s time to commit the script file to our Repo. We run the following command using the -m parameter to specify a message about our commit. Make sure your commit message is something meaningful and relates to what the commit change is for. This is a part of documenting your code so make sure it’s good:

Git commit -m “This is the first commit for the Windows Update script”

Uploading our Repo to GitHub

You can keep track of your code locally this way and leave it at that. Or you can benefit from GitHub by uploading your newly created repository on GitHub. So, let’s login to GitHub with our account and go to the home page. On the right-hand side there will be a button to create a new repository:

Now, we will name our repo. For this demo I created the repo DeployWindowsUpdates (as shown below), so that I have a place to upload my script. Click Create Repository when you’re done:

Now we are prompted with some options for setting up the newly created repo. Since we’ve already created the repo locally on our workstations, we will follow the steps for the option to push an existing repo. So, we make sure we are consoled into the directory we created locally, and we will run the commands to push this local repo up to the one we created in GitHub. You will be prompted for your GitHub login credentials. Input them and select Login:

git remote add origin https://github.com/allanore/DeployWindowsUpdates.git

git push -u origin master

Now, when we go back into our repo in GitHub we can see our newly uploaded script is there!

Congratulations, you’ve now uploaded your PowerShell script into a GitHub repo! Be sure to check out part 2 where I will go over some more functions we can do with Git such as branching, merging, and pull requests:

PowerShell Tools for MSPs – Getting Started with Source Control Part 2 – a deeper look at GithHub: how to do branching, merging, and pull requests

Watch the Webinar

Watch our on-demand webinar 4 Ways to Improve your MSP by Embracing Automation and DevOps hosted by Microsoft Cloud and Datacenter Management MVPs Andy Syrewicze and Adam “The Automator” Bertram. The webinar covers:

• Simple ways to get started with automation
• How PowerShell can help save time and money when used for lengthy tasks
• How treating your scripts like code can prevent mistakes and costly problems
• How Leveraging REST APIs can enable further automation and operational efficiencies

Webinar Q & A

Q: While it’s easy to quantify the benefits of automation from a time perspective, how do you help an owner or C-Level manager see the benefits from a fiscal perspective.

A: It’s often best in this situation to assign a dollar amount to your hourly work. How long does it take you to do that manual task? Take that, assign your dollar amount and compare it to the hours that it would take once automated. Often the results will speak for themselves.

Q: What are some good resources for learning how to use GitHub?

A: The GitHub documentation is well written and provides all the detail you could ever want in a use-guide. Highly recommend you check it out.

Q: As MSPs where does our RMM toolset enter the automation discussion?

A: An RMM system is a great utility. While there are ways of distributing your scripts to endpoints without it, the task is made MUCH easier if you have an RMM platform. Essentially when we’re talking about scripts, an RMM tool is used as the delivery mechanism, to get those scripts to the endpoints for execution.

Q: Why PowerShell Specifically? Can I use other scripting Languages?

A: Absolutely! We see PowerShell most frequently due to its integration with all facets of the Microsoft Server Stack. However, all other scripting languages have their own benefits and use cases as well!

That wraps up things for us today! If there was a question you didn’t get a chance to ask, or have one you just thought of, be sure to let us know in the comments section below!

Thanks for reading!