Windows Administration and Trends in (PowerShell) Scripting

Here is a Run As Radio chat with Jeffery Snover.

Jeffery Snover is the person most responsible for PowerShell, which revolutionized my approach to database administration. He has a background in scripting going back to VMS (IIRC), which is how he came to create PowerShell. His Twitter bio lists "Microsoft Technical Fellow/ Lead Architect for Enterprise Cloud Group/ Azure Stack Architect/ PowerShell Architect / Science fan".

From my point of view, he directs strategy for Windows administration. I listen to him because the things he talks about are likely to influence my work life and they give insight into how the PowerShell team expect people to use their product.

The podcast covers a variety of things in a light way. The thing that grabbed my attention the most was that Snover seems to be saying that Windows will be implementing things similar to what linux does with root and sudo. (My linux experience is limited but my two takeaways are: You never log in as root and sudo controls what your 'day to day' login can do.) Imitation is the sincerest form of flattery, as they say.

Beyond that, it seems that I should be working towards two goals.

One of those goals should be to get my code into an open repository.

I have been using version control for many years, but I have always kept "my code" in a closed repository.

Initially, I used subversion. At first, I ran my own server (on an old Sun workstation) out of my home office. I moved to a cloud-based solution after experiencing a number of power outages. (I just logged into my old Subversion repository for the first time in well over a year. It has over 3,000 check ins.)

In spring of 2014, Subversion was seeming old-fashioned, so I tried Git for a while. That was during an extremely slow period for changes to my code, so I never got very far into it. I documented the start of that period with this blog posting. 

I've been using Microsoft's TFS Online for the last couple of years. This seemed a natural fit because I spend a lot of time in Visual Studio, it provides feature and bug tracking and it a cloud-based solution. Since then, Visual Studio has come to embrace Git.

TFS Online seemed like a pretty hot technology in 2014, but I feel like I've missed the boat with GitHub. The current trend seems to demand use of GitHub. The work required to move my code from TFS Online to GitHub is large. There are over 170 files of varying complexity, with a few being modules with many functions. I work very hard to keep client-specific things out of "my code", but I would need to vet everything again. 

I did do a pass with ScriptCop through much of that code in 2015. I fixed most of the things that ScriptCop spotted. Other than that, much of this code hasn't been looked at in years.

I don't want to split my code between different repositories. I like being able to install one set of tools and I don't want to get into situations where I'm looking for something that is in the other repository.

The other goal is to start testing operational environments like developers test their code.  In my case, I'd like to test my code like developers test their code. :-/

I fiddled around with PSUnit when that was the hot thing, but I never integrated it with my day-to-day work. The current hot technology for this is Pester, and I'd like to do more with it.

Implementing Pester (or any testing framework) "for real" would be a lot of work. My earliest code was written in the PowerShell 1.0 and 2.0 era. Other than Transact-SQL, my coding at that time was mainly in DOS batch and Windows Scripting Host's version of VBScript. PowerShell was a new thing and it was not obvious that it would be as successful as it has been. My PowerShell scripts were not written with testability in mind. The technical debt is enormous. Layers of code are based on that work. Testing nearly anything seems to require reworking layers of code. Changing that code breaks other code. Since there is no testing framework, those bugs aren't noticed until I happen to run them.

In short, it looks like I can't do anything without doing everything and there is no time budget for that. If I work on the testability of recent code the going seems slow, there isn't much impact, working on that code is not my "day job" and I can't keep the enthusiasm going.