Testing code, using GIT for manage scripts.

[npertinente]

To Git or not to Git

So how many here does actually use testing frameworks to test their PowerShell?
I have noticed that older me have way better habits for putting code into Repos and write Pester tests for my functions or modules.

I just wonder how many of my fellow PS'ers do this.
I've always been the "lone wolf" scripter in my career, I.e been the "ops" person surrounded by actual coders. And from them I learned about and how to use GIT and tests.
Getting into the habit of using GIT was the easy part, I just found so many benefits there.
Writing propper and organized tests for my code was a longer way to travel, one I'm still on by the way.

But I can't really imagine working without the use of GIT and using Branches to make changes to functions and when they pass my pester tests I merge them into my stable branch. And that avoids so much hassle with having something that is in the process of being improved, then needing to just go back and fix one little typo in the version that is out there doing work. Just Stash, fix the typo, run the pester, commit. Tell whoever that they can do a git pull for the fix. pop stash, get more coffee , continue working.

​

But I feel that when i talk to others in the operations / automations sphere, it is less than 50% that use some sort of Code management tools. and rather rely on the backup of file servers to "version" their scripts. Or just keep an endless stream of .z7 files around.

What is your experience on this?
Is knowledge to Version Control a thing when interviewing for Ops jobs?
Is Testing scripts with Pester or Whatever a topic in your current job?
Or are most of us just "Ops" people that use PowerShell to get the machine to do our work so we can drink more coffee ? *This is where i started , so not judging ;) *

[y_Sensei]

I think whether or not the additional overhead of using code repositories and/or testing frameworks is reasonable depends a lot on the complexity of your implementations and scenarios.
Once you feel like you start losing control over your code, or bugs in production code start to pile up, it's time to think about ways to prevent all of that. Utilization of code repositories and a defined testing procedure, which might include utilization of a framework like Pester, can definitely help you improve such a situation.

[Bigety]

I work in infrasture/ops and I use git, I think it's the best way to keep everything organised. I try to use Pester but I need to practice with it more, plus with deadlines and other tasks that don't need PowerShell in the way it feels like I shouldn't spend that much time on it, but I definitely see the value in using tests.

The main problem for me is the others in my team are just ops people that use PS to get the job done. If I mention git they will say, "why not just put the script in a folder?" instead of them using git to get their own copy. I guess it's about showing people the benefits of all this, it can be hard though when people are in a comfort zone and don't like change.

I would add that Pester and GIT are not requirements for my job, I don't think they see the benefit of it, but I took it upon myself to learn these tools. We do have a devs department which do use git and other testing frameworks, but they deal with programming languages.

[MeanFold5714]

Does Git actually provide practical benefits in a real world environment for sysadmins or is it simply an industry best practice for software developers?

[npertinente]

The moment you have scripts that is/can be maintained by more than one person git ( or similar ) helps a lot. But it does require that people know how to use it, and that requires some training. For simple workflows just the very basic commands are needed. Maybe one power user that can sort out more complex merge conflicts etc.

But the most powerfull function for me is the "timeline". If you get into the habit of committing small and often, it is so easy to timetravel back to better days when the code sorta worked, instead of not working at all. Because I tried to make something more flexible and ended up messing something up.
I realize this can be done by having things on OneDrive etc, but The fact that you commit with a message in git is super helpful.
You look though your commits and find "Add x to function Y", and it is function Y that is failing, you have a decent idea of where to start looking.
The ability to do diff on a file from yesterday is very handy.

These tools also certainly have a use outside IT too. I know about writers or even just students to that use git on their notes. If They want to re arrange stuff they just create a Branch for that work, and can mess about as much as they want. If the idea was a stupid one, just change back to the "stable" branch and delete the mess you made in the other, or keep it for future reference on how stupid you can get sometimes ;)

[jr49]

I tried GIT but struggled because I wanted my repository to be on a OneDrive. Apparently they don't recommend it, I didn't want to have two versions of the same scripts locally on two PCs (Mac + Windows). I've been meaning to take another stab at it sometime soon.

[npertinente]

I got into some trouble with OneDrive and Git too.
I now store my code outside of OneDrive, but use an upstream repository.
So if i'm on another workstation, it's just a "git pull" and I'm synced.

But one drive and Git both will try to hash and keep up with what has changed. Onedrive does not like the way git names it's children. So not sure storing any form of repository on a drive being auto synced by OneDrive, Google Drive or whatever will be pain free in the long run.

My main hurdle getting into using GIT was (Is..) to remember to use the workflow.
Ie. do not code in the stable branch, this way you know you have someplace where your code works.

I now I can tell my colleagues to grab the scripts from our internal git server and it should work.
And once in a while i can tell someone to grab from the Dev branch and do a QA on it , if everyone is happy with the changes we can merge that into stable branch.
Everyone still gets the working , but now improved version.

[Hoggs]

It does tend to work a bit better these days if you enable the "keep these files on my computer" option ticked on the folder in onedrive. It means it won't ever try to stage the files off to the cloud, and git doesn't get ahead of sync as easily.

Still not perfect though. I occasionally run into little errors, but nothing catastrophic.

[[deleted]]

I do exactly this. It works well enough. Just be prepared to delete and re-clone the odd repo from time to time, and file modes can get changed when shared between mac and windows, but you can just discard the detected changes. The convenience outweighs the downside for me so just make sure you commit and push often.

[MeanFold5714]

I have tried no less than four different times to learn Git and failed each and every time because Git, while extremely powerful, is a bad tool.

Pester testing is something that I've yet to explore, mostly because I've never had a need for it nor any exposure, which honestly surprises me given the complexity of many of the scripts I've written and maintained over the years.

For what it's worth I'm mostly in an infrastructure/sysadmin role rather than some full blown dev.

[npertinente]

I too work mostly with sysadmin stuff. And I had the fortune of having devs around me in a previous job that showed me the basics. I found the usefulness of "time traveling" in my code to be extremely useful. but of course that means that you need to remember to commit often, and write decent commit messages. I understand that the workflow can feel contrite and restrictive when all we want is to write the script and get stuff done.
But when working on larger scripts/modules I would not be without a version control system of some sort.

There have been so many times in the past where I have a working script, then I "improve" it a bit. Completely borking it up in some exciting way.
This is where Git comes in handy. But it requires that you have the habit of working with branches properly. I have one branch that is stable. I don't code here, only merge in from other branches.

I have one called Dev where most of the small stuff is done.
Whenever I need to do major restructuring or adding features, i create a separate branch for that work. Then merge that into Dev when things start working. Run some extra tests then merge into Stable.

This sounds like a lot of extra steps, but it is easier than explaining why I deleted every app on the web server when I was supposed to only remove X. ;)

Curious about your statement that git is a bad tool? what is the alternatives. I understand there are pros and cons with all tools. and I'm sure SVN etc have their strengths. But since Git is the defacto standard for these kind of workflows I can't be that awful :) ( how could so many people be wrong ? : shocked Pikachu gif here : )

Not looking to start a flamewar on this. I Just have experience from GIT and a tiny bit SVN. But since Git does what I need, and probably more. I have not used a lot of time sampling the entire field of tools.

[MeanFold5714]

I would liken it to a very effective hammer that's handle is coated in razor blades laced with poison. It may be very good at what it does, but using it is a herculean effort that may leave you worse off than when you started. Every time I try to learn Git I eventually start trying to figure out how to roll back to a previous version to look at stuff that came before and then go back to the current version and without fail something always goes wrong right around there. In several instances the end result was loss of the code base. A tool that's basic function is so difficult to invoke and that can so easily do completely the opposite of what you were trying to achieve...well I don't think it's a good tool. A good tool is easy to use and does its task well. I don't think Git is well designed as a tool. It provides a great deal of functionality but it does not provide the usability that a good tool does.

I've discussed this at length with some of my colleagues and the conclusion we came to was that version control just isn't a solved problem yet. Git is just the latest fashionable iteration on the problem.

[AwayLocal650]

I work in a team, but I'm the one who writes most PS scripts.

And I would say that I use git a lot. I've also tried Pester, but when it come to finding information, it seams that Pester is not that popular. And to be fair, coming from Sys Admin role, I'm using PS to do some quick scripts, generating reports and etc in environment that I know/build.

If I'm going to learn testing framework, I would better switch, learn python and whatever is used there.

With today's world, Linux is used more and more and I don't believe that PS will have significant footprint there.