This is part of a series called
Using PowerShell in testingin which I intend to showcase lots of different ways that PowerShell can used for all sorts of testing. A prior example would be Building A Lab using Hyper-V and Lability - The End to End Example.
First things first, if you are writing code then you will have built up a series of preferences over the years in how you have your machine configure, or actually for many of us that is actually not just one machine but a collection of physical and virtual machines. That in itself is not only another blog post, but is also content that could be a presentation, and could easily be something just as a topic along could end up becoming a whole new conference in itself. Not saying that I would look run a conference, at least not right now, however, the idea for MachineConfig Conf, is there for whoever wants to run with it, I just ask that if it happens that I get asked if I want to present at it.
As part of some of the way that I build, run and test things, I have a certain setup process that I mostly find works. It very likely may be different to how you have things set up. Especially as I know that all of us that do anything with computers, especially us that develop any software, will have a whole series of small personal preferences, and some of these can be hard to keep codified & prevent configuration drifts, but mostly this is something that is slowly getting better with time, though it is still at least a days effort to get a machine configured from new or a re-install, and for that I do have a Setup Process depending on what kind of device it is and what the device is doing.
There are new things that I would like to test out, which include Dev Home, Dev Drive, WinGet though I’m currently a Chocolatey person myself & used to ensure I had a good supply throughout my day, as well as WSL - Windows Subsystem for Linux. I also have some additional settings that are applied as part of the way I personalise each device.
This setup currently has this little section from the first time Ichimaru meets Ichigo in Bleach (which is my favourite Anime & will be writing about how much it means to me soon) as my background, which always makes me laugh a little.
also helps me when testing things for the PowerShell Interactive UX Working Group as well as when people bring things up in the PowerShell community Slack / Discord or just when I get a
Ooooohhhh, What if I try this out moment.
Therefore, I do find that my setup is a quite efficient way of working when it comes to utilising PowerShell for any task & gives me the ability to confirm that it will work across differing versions very easily right now. That said, there are things that could in future be added to make this even more useful, like Add options for running with no profile to jumplist & explorer.
Most importantly, the way I have it ensures that some of the things I rely on can be used & still work across multiple different & older Windows OSes, or perhaps in those more locked down environments. It also means that I can take things and lift them, shift them, and importantly reuse them as I go forward in my career, as can others that find it useful to them.
Whilst I enjoy being on the
Bleeding edge as it can be fun, it can also be a huge world of pain too!
Specifically, I have been testing the following, which due to me forgetting the below testing matrix had me thinking (for a short while) that I was getting unexpected results on my primary machine, though this wasn’t the case, just me being forgetful at the time, which happens to the best of us, now and then.
- MSI installs that are Updated via Microsoft Update
- MSIX installs from the Microsoft Store
- Daily Builds by using this install-powershell.ps1 script in the PowerShell Repo
- Manual installs of different versions using an update to that script which I have a PR which updates it with more options - For some additional ways of using the updated script please look in the Gist Links at the bottom of this post for some inspiration.
This gave me the side by side versions as shown in this example of how I have had my taskbar (on Windows) for a while now.
Yes this is quite a few options & whilst that image shows some older versions, each were updated automatically via different means. Whilst it’s been somewhat fun seeing how the different update cycles work, I think I am however going to on a new machine build move away from both store and Microsoft update mechanisms for install & further test the updated install-powershell.ps1 script in the coming months.
This is because with the amendments I’ve added you can now have the below as a really easy set up which makes it really easy for testing for issues in the PowerShell Repo really easily & quickly against a matrix of versions with very little effort. I would like to improve this process & make it easier for in the issues in the PowerShell repos to show that they are affecting or not.
Note: This uses the zip install method to achieve this (could use MSI but it’s not really needed)
Note: this allows me much simpler testing going forward, particularly as you can see above with this install script you can have it install a newer version of say Stable/LTS and the current version will be moved to .old folder as was highlighted with 7.4.0-preview.4 and is visible with the daily version too.
Why this way?
This comes down to the following key points
Also it’s just another interesting way to have things set up.
What about using Windows Terminal?
As was asked by Przemysław Kłys
"Why would you do this instead of utilizing Terminal for all of those? Those have profiles, can those can have their own specialized settings. Why would you clutter it like that?" in this tweet
Why would you do this instead of utilizing Terminal for all of those? Those have profiles, can those can have their own specialized settings. Why would you clutter it like that? pic.twitter.com/KHjLECM6lJ— Przemysław Kłys (@PrzemyslawKlys) July 5, 2023
The big reason why I have this (as well as Terminal) is because of older versions of Windows (mostly Server) where Windows Terminal just ain’t ever going to work. This is still likely a large amount of organisations environments. Plus as Terminal is Windows only (& the ), it makes sense to have multiple ways that could be & definitely is the case too when it comes to Linux or MacOS environments. So whilst I could start making significant amount of use of Windows Terminal, I default back to what I can easily bundle together, just in case in future I have to roll together a package for a security team to sign off on.
This isn’t to say that I don’t use Terminal, however I don’t use it as much as others do & whilst I also have this all set up, there are as per some of the comments I made in this issue Add options for running with no profile to jumplist & explorer I do still feel that for admins that aren’t (or can’t use Terminal) there is a need for some of the abilities that Terminal or a custom Start-PwshProcess function may give, like starting a new process as admin with either no profile or a minimal profile. I won’t rehash that issue bar saying clicks is often significantly quicker than typing!
Terminal also has got loads of great features but for ease of jumping around different machines it isn’t a tooling dependency that I am utilising heavily right now. That of course can and likely will change, but the way that I have things is set up allows me in such a way as to complete my tasks as easily & quickly as I can.
What about spinning up dedicated VM’s?
This is something that with Lability I had been looking at rolling out a module that contains some example environments for use with it, for some time now & even have had started discussing this via this issue that I raised in 2016, Lab configuration Sharing - Thoughts & Discussion. I then read this article, Define Once, Deploy Everywhere (Sort of…) from Rik Hepworth @ Black Marble around the time it was released (March 2017) and this was a big precursor to me approaching him at Future Decoded that year about the possibility of a role at Black Marble, which as you know ended up happening from this post New-Job -Role Consultant -Company ‘Black Marble’ -Start September.
However, I asked Rik as I wanted chance to,
- work with tech listed in that post.
- work on the challenges that they had as an organisation that works closely with many interesting areas, like Policing.
- Learn from others across the business that I already knew there.
In future, I may write more about my time there, I may not, however up till the Pandemic, I was really enjoying working there.
I did in my time there get chance to work on things directly related to Rik’s post, including work that was related to both the Lability post linked at the beginning & the issue above, however, I did not manage to get that work open sourced, even though I did ask about the possibility of it happening, which I am still hopeful that it might in future, especially as the work that they have done would be of great use to the community & would instead of me attempting to add similar features either into Lability or a wrapper of my own.
This is something that I started to comeback and then plan some work around in 2020, as part of the planning for working on AzureDevOpsDSC for what was going to be a session at PSConfEU 2022 on Building a High Quality Resource Module (HQRM). This was going to be built as a class based module and have that as a foundation presentation to help with the DSCCommunity. I am thankful for the work done so far on that module and is something that I want to get back to sometime in the future, when other significantly more important & pressing tasks have been completed.
Though that said one of those tasks is to determine what it is that I actually am gonna do workwise. I have plenty of work that I want to do, however unless it’s paid work, which finding paid work is a job in itself.
What about in Windows Sandbox??
This is one the list of additional areas for me to look into but generally for what I need to quickly test against, this just slows me down when it is software that I have already used & trusted and then verified too.
However I definitely have made use of this in testing as at one point I have spun up Sandbox running an Azure DevOps Agent on it in the past.
What about using containers??
So spinning up a series of containers for each version could be a future enhancement in this workflow, however, as opposed to either locally, in Sandbox or on dedicated VM’s, though I think this is something that I’d like to have both happen as plenty are still using VM’s and I think that won’t change for some tim, if ever.
It is one of the areas where I need to spend more time in future, and adapt all of this for use in different containers. However that said if you either want to do it, have already done this, or know people that have, could you point me in the right direction so that I can link to the work!
I hope this has been an interesting blog post & lets you understand a little bit of all the different ways that you can side by side install PowerShell for testing things out
Please use the below as a way of potentially using the updated install-powershell.ps1 script.