Things I had to do to test dbatools, Part 1

I spent a good amount of time this week getting a system up so that I could actually maybe start contributing code/tests/something to the dbatools project. I've been wanting to do this for a while, but there is a large amount of "stuff" to get working before being able to do "real work" and getting it all done eluded me. 

Over the last year or so, I've spent a couple of hours getting up to speed, getting things installed and then run out of time just as I get to the point where I can start working with the code. (You know, the fun part.) 

A few months later, I'd give it another go, only to have to spend time fetching my remotes (since I fly solo so often, I'm a perennial newb at some things that I wish I weren't a newb at) and addressing other bit rot issues. By the time I got caught up again, I'd be out of time. Wash, repeat, et cetera and so forth.

I still support several SQL 2008 and SQL 2008 R2 instances. I've noticed a dbatools "behavior" that might need remedying. Now I have (much) more reason to get off my comfy couch and do something useful. The first thing is to get my work environment completely set up.

How I got my work environment tuned up to work with dbatools:

• I already had VS Code working on my development laptop, with git and a smattering of extensions. I have basic git knowledge. I have relied on a dozen or more online guides for getting all of that configured and working. I've got nothing to add to them, so I won't try here.
• The dbatools Pester tests seem to like to remove all of the user databases on an test instance when they run, so you need to give it an instance that doesn't have databases that you need to keep. Additionally, I needed a SQL Server 2008 R2 instance that I can work with. I have a smattering of development instances around my homelab. My main development laptop does not have anything as old as SQL Server 2008 R2 loaded onto it, and I don't want to have to worry about accidentally dropping databases on it. My development cluster only has SQL Server 2012, SQL Server 2014 and SQL Server 2016 configured and that won't help either. I have an old Windows 7 development VM that had fallen into disuse. It had SQL 2008 and 2008 R2 configured. That seemed ideal, so I spent time opening up the firewall so that I could run my fast development laptop against that VM. I had forgotten how much of a PITA this is, between port assignments and firewall rules. Worse, I realized belatedly that dbatools tests are written in a way that seems to force running locally to the instance. All of that work on the port assignments and firewall rules was wasted. So, Plan "A" was a failure.
• Plan "B" was to set up my entire development environment on that old VM. First, I had to do a few rounds of Windows Updates. Then, I had to install and configure VS Code and Git. There is an old SQL Server 2008 R2-era SSMS installed, which seems good enough for me to put off installing a modern version of SSMS for a while. I discovered that the VS Code Settings Sync extension I have configured doesn't seem to be working, or doesn't work the way I thought it did. That cost me some time as well.
• To save time, I just copied the source code files over my network from my main development laptop to my newly-tuned-up development VM. Git never missed a beat, though I suspect that doing this to a TFS installation would have driven it nuts.

At the end of the evening, I had all of that working OK. The next night, I focused on getting the tests to actually run. That will be my next blog entry.