Create central script library, just like the variable library
The variable library feature is one of the single most useful new features in Octopus, allowing us to observe the DRY principle and only define cross-project configuration values once. We use it heavily in our organization.
It would be great if we had the same functionality for scripts. Just one example out of many instances: I have a script that creates a local user for use in basic authentication, and I have to duplicate that script over and over again for every web project I deploy. If I want to change a detail in that script, I have to change it in numerous places.
I've worked around this by creating a nuget package that contains all my scripts as a Powershell module and then deploying to the target environment as the first step in any deployment. Then I can just do an Import-Module on it and call one of the functions therein. But if Octopus had a central script library, I wouldn't need to do all that work anymore.
Check out the step templates feature in 2.4/2.5, and the library which is full of templates:
This will be great, especially if this is easy to use from the Script Console. We've found ourselves running adhoc scripts quite often throughout the day because it's so easy.
This will also make it possible to define modules that are available for use in all your scripts.
Wayne Brantley commented
I think if you would support the concept of 'plugins' that would solve this issue. Just allow us to drop plug-ins into a folder on OD server. Those plug ins become steps that are run just like any other step.
These plug-ins could be simple powershell scripts. This set of plug-ins would become the library. You could then easily edit/create plug-ins from the UI since they are simply scripts.
With powershell scripts, you could hit any endpoint or do any sort of notification you wanted, with all the features of any step.
Optionally, you could support .net plug-ins that implement some interface in case users wanted to write it like that.
Erik A. Brandstadmoen commented
I would really recommend storing the scripts in your VCS (git, tfs, whatever) instead, to avoid lock-in to one deployment solution (Octopus Deploy in this case). The deployment tool should not be responsible for the inner workings of your deployment. This should go in your Deploy.ps1 script. And you can always link in common powershell scripts from your VCS in you Deploy.ps1 scripts, which should obviously be source controlled as well. IMO.
I would extend it further to other artifacts like email templates as well.