17 votesChris Camburn shared this idea ·
Any chance of an update? We have a few hundred projects, with only a few project types, and it's becoming cumbersome to manage even trying to script out the API changes to projects.
One additional request: We use a number of standard settings for IIS, and the current built-in IIS deployment step is perfect, so that we don't have to script everything ourselves. We'd like to use that as a step template, so that any changes to how we deploy IIS sites can apply to all projects at once. Unfortunately, to do that we have to use a variable for the package name, which breaks the retention policy. Unlike most steps where we can reference a previous package step name, the IIS step requires the package be in the step.
Is it possible to have a new template parameter type for a Package Name, that still uses the autocomplete that most package deployment steps have? Or possibly a way to pass in the package name to a template while having Octopus retention policies run correctly?
Any updates on this? While the new 4.X UI is nice, this RFC is 6 months old and would be incredibly useful.
+1 to the ability to have this function like TeamCity. It would be nice when you have multiple projects all based on a template to update in one place and have that change propagate.
We are going to implement this soon. To track progress subscribe to https://github.com/OctopusDeploy/Issues/issues/4159
The Workers (https://github.com/OctopusDeploy/Issues/issues/4158) feature is related and covers some of the use cases described in the comments.
My specific use case is to not just run something once, but to have it run on one tentacle from a pool of tentacles. We have a handful of server-intensive processes that can be run from any server, but must only be run once. What we'd like to do is have a handful of tentacles with the same role, and each deployment would select one tentacle with that role and run the steps. That allows us to do something similar to TeamCity build agents, and offload the work on the first available tentacle.
I believe this would be best implemented by just allowing nested / hierarchical Project Groups. You could then have different priority groups within a single Project Group that would grant custom reordering, while also granting things like security.
We have started this under https://github.com/OctopusDeploy/Issues/issues/4159 (subscribe to that for updated). Workers is also related to this (https://github.com/OctopusDeploy/Issues/issues/4158)
Out of curiosity, in what way does the existing 'Skip any package step that is already installed' not cover your scenario? In use it correctly skips package steps we have.
Thanks everyone who voted on this. We’ve spent a lot of time thinking about how best to version control Octopus configuration, and came to an approach that is a little different to what was imagined in this blog post. I just published an RFC post with our plans – I’d really appreciate if you could take a look and leave a comment!
Even with octo.exe export for deployment processes, that doesn't provide the ability to recreate the entire server. TeamCity has direct source control integration, so that in the event that something should happen to my server, I can link a new install to source control and recover every bit of configuration.
The other two (smaller) advantages of this are the ability to edit configuration outside of the UI by making changes directly in source control, and the ability to accurately track all changes made. The audit log in Octopus is difficult to use when tracking small changes to a deployment process. Source control integration would make this simple.
Our use case:
We have two groups that must approve a release before going to Production, GroupA and GroupB. We would like to maintain the current approval steps when doing a 'Deploy now' deployment, as we need both groups to approve. However, when we want to schedule a deployment for off-hours, it would be nice to have both groups approve ahead of time.
We are unable to use the workaround of having an 'approval environment' to gate the release prior to going to Production, as we need the approval to happen per deployment, not per release.
Currently we are looking into writing a custom app that will allow a user to query all scheduled deployments in Octopus, select one for pre-approval, and submit with a comment. This will create a scheduled task to run that will approve the deployment at the specified time. Though not something we'd like to do, it's also better than setting up the VPN and logging in at 2am to approve.
I envision this enhancement would function similar to how scripts can be run prior to package download. Select an option to "run prior to scheduled deployment." If selected, it will leave the 'deploy now' functionality as-is, but will change the 'deploy later' to allow approval anytime before or during the scheduled deployment.