I would like to propose an enhancement to include a customizable revision and configuration history for scripts, software, and deployments. This feature could be configured to be required before any changes are accepted or disabled through a system-wide preference setting.
The proposed feature would allow administrators to define customizable comment templates. For instance, these templates could prepopulate a comment box with default text to guide users in documenting changes effectively.
Once the system-level setting is enabled, any creation, update, or modification of scripts, software, or deployments would require the user to input a comment explaining the reason for their actions.
To further enhance functionality, the system could retain a configurable number of recent revisions for each item, enabling users to restore previous states when necessary.
Additionally, a centralized global revision history could be made available for administrators, offering a comprehensive and searchable view of all changes for auditing by ImmyBot administrators.
Currently, the ImmyBot includes individual features like audit logs, comments for scripts, and deployment notes. However, these functionalities are fragmented. By unifying them into a cohesive revision history system, it would simplify workflows, improve traceability, and enhance compliance.
This is a really solid suggestion, and it aligns well with best practices in development like Agile and Scrum. Having a customizable revision and configuration history would improve traceability, which is essential in Agile environments for continuous improvement and transparency. By enforcing well-documented changes with comment templates, teams can stay aligned and maintain clear communication, which supports iterative progress and fast feedback loops. The ability to enable or disable this feature system-wide offers flexibility, while the option to revert to previous versions supports the “fail fast, fail cheap” mentality of Scrum. A centralized revision history for admins would simplify retrospectives, audits, and ensure that changes align with project goals. Overall, this would greatly streamline workflows, enhance traceability, and strengthen compliance, all of which are crucial for effective Agile practices.
I agree with the majority of what’s here, but the problem is that what you’re proposing requires treating the entire script library as a single codebase; there are hundreds of function scripts at this point, and making changes to those potentially alter the behavior of the other hundreds of scripts using them. You can’t just “accept” a change to a single script when the change to that script may have been the introduction (or re-use) of another function and then expect end users of ImmyBot to parse and understand and “accept” those things.
I think the fact that ImmyBot allows people to view the scripts being utilized leads to this thought process of “I want to know what’s changed and I want to be able to control it.” While I may agree with that in principle, do we as users of ImmyBot review and “accept” backend code changes ourselves (or any other MSP product)? Of course we don’t. Most MSPs do not have people with powershell or software development expertise, and will simply default to “accepting the changes” and then inevitably will lead to “why can’t we just auto-accept the changes because we don’t know what we’re looking at?”
The repository is part of the product, and is meant to be dynamic so that vendors changing their installers and APIs don’t require changes to the main codebase and new build–that is by design.
As far as changes made, there is an audit log of ALL script and item modifications that is and has been in place for almost 2 years now. Have you seen it?
You can also access it by hitting “View changes” in the script editor!
I’m a huge proponent of the git-ification of Immy, but for all the reasons Dimitri brought and more, it would likely be limited to a local implementation when/if it happens (with us possibly being able to suggest changes to global).