I help manage deployments for a software team that is working on moving from bi-weekly releases to continuous delivery. In order to transition smoothly, we have decided to have four environments in our pipeline: Dev > Alpha > Beta > Production. This allows us to continuously deliver internally from Dev (automatically deployed to from build server) to Alpha (snapshot of all projects promoted to Beta bi-weekly for staging).

What I would like to have the ability to do is make all deployments to Dev synchronous in that they wait if there is a current deployment to Dev and stay pending if that deployment fails. I do not want this to happen on any other environments.

I will be using the Run a Script step template and the Octopus API to do this with proper scoping in each project’s process in the meantime, but a built in feature would save a lot of maintenance. I would also expect that this is a common requirement for continuous delivery in order to accurately freeze your pipeline.

We have nearly a dozen client/WPF projects that primarily consist of backing up a directory and then overwriting it with an updated package (size ranging from 20-350MB). Each of these projects push their packages to 20 remote servers, but the servers cannot host tentacles due to our security policies, so we run the steps from one of our Octopus hosts (via tentacle installed alongside the manager service). This is slow and expensive on the Octopus host, especially when there are many other deploys underway. Worst of all, it forces steps to deploy in serial versus parallel because all steps are running through a single agent.

After reading a bit on workers and worker pools, I thought they might provide a solution for our bottleneck by offloading the work from our Octo servers and enabling parallel deployments. However, after building a pool, I realized worker-enabled steps are seemingly limited to cloud and scripts. If I was pushing these packages to an S3 bucket, I’d be good to go, but I cannot choose a worker pool as the execution location for the ‘Deploy a Package’ steps we are using. I’ve also considered using PS scripts to push these packages around, but we enjoy using built in configuration features to uniquely configure each remote locations files.

Can worker pool support be enabled for the ‘Deploy a Package’ step so I can use workers to push packages to remote Windows servers?

With Octopus Cloud 2012.5.9 we can’t assign our own CNAME to the server instance due to the Let’s Encrypt module being missing.

It is ok for internal use, but if we want Tenants to have access to see what we’ve deployed for them, then we would want to use octopus.mycompany.com not mycompany123.octopus.app.

It might seem minor, but does Octopus use octopus123@yahoo.com as your public email address for customers? Nope, and we don’t want to either :-)

Please add back the excellent Let’s Encrypt module in Octopus Cloud and route port 80 or just .well-known/acme-challenge/ to the relevant instance. Octopus Cloud customers can create their own CNAME record, and we are back in our happy place / domain.

Specifying Policy for a machine in a new Tentacle through the Azure Extension Agent would be valuable.

In our scenario we use ARM templates for new infra structure as code for "cattle". The extension allows for dynamic creation of short-lived environments in Development.

However, we want to utilize the Octo automatic de-registration of agents as dev infra is removed via Machine Policy. (Machines in Octo disappear when automatically after a developer is done with a VM.)

Having the "Policy" as a parameter to the extension would allow this to be setup easily one time instead of a post-build step manually or an extra CustomScriptExtensinon in the ARM template.

Been setting up multiple pipelines for Azure Data Factory (ADF) resources, defined by a series of Json files and would like to to use the Json Configuration Variables for configuring these. In ADF you typically have a series of linked services json files, specifying e.g. connection strings, credentials, input type etc - all with the same hierarchy - E.g. the connection string would be specified as 'properties:typeProperties:connectionString' in all the linked service files - hence the problem, since all json files are applied with the same OD variables.

I proprose an extension to the existing Json Configuration Variables feature, where you can specify which file to scope the OD variable for - e.g. to scope the variable to the file ls_blob_storageaccount.json:
'ls_blob_storageaccount.json) -> configuration:typeConfiguration:connectionString'