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.
