FredBainbridge

#4 Source Control - 10 Things You Need As An Enterprise Scripter

by fred in  powershell, automation

#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

  • Don’t be afraid! The biggest benefit of using source control is it’s code safety benefits. It is pretty challenging to delete committed work in such a way that is not retreviable unless you are really trying to do so.
  • Every time you do something of note during development make sure to commit your changes. There is no need to worry about over committing your work You can never have too many commits in my opinion.
  • If you have binary / compiled files, try to keep them out of the repository. You don’t see compiled stuff on GitHub right? For bonus points, compile the code at the deploy time if needed. There will be a future post on continuous integration.
  • Keep your scratch work, test scripts and code doodles in a source safe. Why not? That stuff comes in handy some times.
  • Source control is still a must even if you are working alone. You don’t need a team of scripters to benefit from source control.
  • Learn the command line tooling. I am pretty nuch specifically talking about GIT here. If you are going to use GIT, which I think you should, I highly recommend becomming proficient with the git command line. This will pay almost certainly pay off in the long tun.
  • Keep your tooling current. GIT for example has regular releases. Make sure you are never too far behind.

    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.

    Using GIT (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:

  • Identify a needed feature.
  • Create a branch in the source control repository.
  • Commit your code to the new branch as you are developing and push it your source control provider (i.e. GitHub).
  • Upon completion of the work create a pull request to merge your changes from your feature or bug branch into the QA branch.
  • After a thorough peer review your pull request will be approved and your code merged into the QA branch.
  • When ready do a pull request from QA to UAT and then after proper change control or whatever do a pull request from UAT to PROD.

    Get in the habit of using source control because there is no downside to doing so, only benefits.

    Share