There have been a number of cases where Global softwares or scripts get changed (usually, because parameters are added or removed) and break existing deployments.
Basic versioning of Global softwares with the ability to link a deployment to a specific version of the Immy Software or Maintenance Task (not the actual software version) would be a good first step. Even better, would be if Globals were tied to a repository so we have the full set of git tools to control what is pulled down to our tenant.
After the disruption caused by the recent TimeZone script bug I would love to see this too.
My idea is pretty much aligned to yours. We could set our environment into “auto import” mode where all changes just flow through automatically (as they do now), “scheduled” mode where changes are pulled in during a maintenance window, or “approval” mode where we have to pull each change in. If the Software and Task definitions are just a JSON document then they would lend themselves to change management too.
Additionally we could easily roll back a troublesome change.
I don’t know how this bit would look, but it would good also to do a deployment that targets different revisions, eg by default you get your current branch, but you could target a deployment against at pilot branch of your source tree, and then pack a PC full of every deployment you use and use that as a unit test rig (and maybe even use that to automatically trigger the import of changes if successful)
And finally, be able to put your own updates into global scripts, eg I could easily have fixed the bug in the TimeZone script, but it’s a global script which means I need to create a new task, clone the scripts, update deployments, and then remember to put it all back again once the global script is fixed. Instead i’d just override the global script with my change, and then submit the change for review (eg the thing that git has been doing for years!)
@DimitriRodis I didn’t know they existed until just now. The timing is a bit tricky though. That’s 7am Friday AEDT at the moment which I can probably actually achieve due to taxi-dad committments on a Friday morning seeing me in the office before 7am, but in another week when our DST ends that meeting is going to be 6am AEST…
I have been “for” script versioning for years now. That said, there are some signifcant improvements coming to the script editor in 0.56 which will pave the road for such a thing (so that you can see diffs, for example).