What To Do / Not to Do in PowerShell: Part 8

One of the biggest problems I see organizations struggling with, when it comes to PowerShell, is the concept of administrators being "hackers" or "script jockeys." Generally speaking, it boils down to this: "We don't want these scripts becoming a mission-critical part of our organization, because they're not real code."

Well, obviously they are real code... the underlying concern here is generally along the lines of administrators not treating their scripts like real code. Many of the best practices I've outlined in this "What To Do / Not to Do" series can help your code get taken more seriously. You can also get more respect by showing more respect. That is, treat your scripts to some source control goodness.

Source control is essentially a database of your scripts, including past versions of scripts. Many organizations will already have some source control in-house, perhaps something like CVS or Visual Studio's Team Foundation Server. These source control repositories are generally backed up, making them a good place to keep mission-critical scripts. SharePoint also offers version-controlled document storage, although it isn't specifically for code. Third parties like SAPIEN Technologies offer simpler, standalone source control software (ChangeVue) that's intended for easy setup and maintenance. 

With a good commercial script editor, you can check scripts in and out of source control right within the editor, making it as transparent as just using your local file system. 

Treat your scripts like the code they are: Check them into a source control repository. Make sure it's backed up. That way, you can retrieve previous versions, make your code accessible to the company (in case you get hit by a truck), and get a little more respect.