#4 Source Control - 10 Things You Need As An Enterprise Scripter
#4 Source Control
Are you naming files like MyAwesomeScript_old.ps1 or MyAwesomeScript_081207.ps1? You are an excellent candidate for some form of source control for your code. Once you get into the habit of using source control you will feel naked scripting without it. The many benefits of proper source control include a clear audit log on who modified a script, when they did and preciely what was changed and most source control solutions also have built in tooling for peer review and access control. Simply put, without proper source control it will be hard to be identified as a professional scripter. As I have said previously the biggest difference between enterprise level scripting and otherwise is professionalism.
Source Control Tips
Git I am partial to using GIT because of its maturity as a product and popularity in the industry. However, any source control solution is infinitely better than no source control solution. Git does not equal GitHub. Git is used to manage local code repositories whereas GitHub and other cloud source control providers (visualstudio.com, bitbucket.com) are used to host your existing repositories and provide additional services like access control and reporting. In order to do development work on a GitHub hosted repository, for example to clone a remotely hosted repository to your local box, you have to have a local git client installed on your development box.
(Thank you @ThePracticalDev)
For those getting started with GIT, I recommend reading “Learn Git in a Month of Lunches”. The first half of the book is outstanding for learning the tooling. The second half gets quite deep into the weeds of GIT. Git takes time and practice to achieve competency with especially if you have no experience with source control. But absolutely put the work in, it’s worth it. Before long it will feel weird if you ever do any development work without using a source control solution.
Branches
Branches are not absolutely necessary, but they sure are nice. If you are going to be working in several infrastructure environments (i.e. QA\UAT\PROD) or if multiple people will be working on the same codebase it will be useful to create several branches of code. When you utilize branches in your code repository you can do things like protect certain branches from being updated without an explicit pull request. A pull request is what happens when you want to take code you have completed and merge it into an existing upstream branch. Ideally any work for features and bugs should be done in their own branch of the repository and merged into a main branch upon completion and peer review..
High workflow example:
Get in the habit of using source control because there is no downside to doing so, only benefits.