Whenever there is a change in the variable after the creation of the release, we used to get warning saying "Release Snapshot has been changed". But we do have only one option to update the entire release without knowing what has been changed. It would be great if you have any way to find/highlight the variables and their values that will be updated when I click "Update Variables" in the release Snapshot section. It will minimize the risk when it's comes to updating the snapshots for production deployment and it will give a transparent view of what changes are done in the variables post release creation.

We're using various steps for deployment ('Deploy a package', 'Deploy to IIS') which both have variable substitution options to substitute variables in Web.config/App.config.

During deployment, i've noticed that these substitutions are logged. However, sometimes i see that our sensitive variables are being logged here at 'verbose' level. Other sensitive (and also non-sensitive) variables are obfuscated.

It seems that the deployment process decides by itself based on the name of the variable. In my opinion, the sensitive option of the variabel should be considered here as well.

An example of what we've got currently:
We've got an appsetting in our app.config, lets call it ConfigSetting
In octopus i've defined two variables, ConfigSetting (non-sensitive) and ConfigSettingSecret (sensitive). The secret is retrieved as output of a previous step.

Values are:
ConfigSetting = {Setting1:Value1,Setting2:Value2,Secret:#{ConfigSettingSecret}}
ConfigSettingSecret = #{Octopus.Action[GetSecret].Output}

Now, i've noticed that the ConfigSetting along with the actual secret is logged on variable substitution. Obviously, this should not be logged.

My feature request is therefore to prevent these sensitive variables from being logged.

Amazon's ECR (Elastic Container Registry) is a docker-compatible registry that you can configure as a first-class package feed in Octopus. Part of the ECR product (in AWS) is to set up lifecycle policies so it can automatically delete old images (since it takes up space for each image). This is a similar feature that Octopus offers on its own built-in package registry, but the ECR is obviously an external registry so the purging has to managed by AWS (and no Octopus). But ECR has no way of knowing which images are used (so they won't get deleted), except if you specify a new tag on the used images (like deploy-Stage for example), then you can exclude those.
Currently I can do that with a custom step, but it would be nice (since ECR is a 1st class feed now) to have a checkbox that would do this automatically in Octopus so it would be easier for users to enable this.

The label of this checkbox is slightly confusing - it led me to believe there was a manual process for applying transforms too. Given that when this box is ticked, a default set of transforms are applied, and when it is not ticked, those default transforms don't run (but transforms listed in the additional box DO run) and the process is always automatic, a label like "Apply the default set of transforms built into octopus" might be better. Alternatively, consider removing the checkbox entirely and just putting the pre-programmed defaults (Web.Release.config => Web.Config, Web.#{Octopus.Environment.Name}.config =>Web.Config) into the box as a default. There is then no need for this checkbox or the explanatory note below it

TLDR: the tickbox is not for deciding between automated or manual application, it's for choosing whether to run a pre-programmed set of transforms. The label should clearly reflect this, or the checkbox be removed and the default transforms put in the "advanced" box instead

Firstly, thanks for working on and improving upon an already great product. Now to the feedback at hand, I am currently investigating making use of the .NET Octopus.Client within a project to manage the octopus deploy server. As part of that investigation I was trying to gain a better grasp of the compatibility of the various Octopus Deploy (OD) server versions and the related components. That led me to the current page, https://octopus.com/docs/api-and-integration/compatibility which though useful at first glance, it was not clearly defined upon further investigation. Since I'm looking to use the Octopus.Client component let's example some questions for reference:

1. If we look at the column it shows three rows with 3.3 -> Latest corresponding to multiple different server versions within the "Octopus Server" column. My question here becomes, is 3.3 only compatible with server 3.3 or 3.4 or 3.5 -> 2018.2.




2. Also, it is not clearly defined as to what those compatibility limitations are at first glance. E.g Is the backwards compatibility cut-off due to the introduction of breaking changes? Are forward facing changes in the API always a super-set of previous API versions, I guess this would be more easily interpreted/digested if octopus was following semantic versioning but that isn't the case since the introduction of "Year.X" based versioning scheme in 2018.

This is especially relevant when one considers versoin "4.30.7 ➜ latest" of the Octopus.Client which corresponds of the "2018.2 ➜ 2018.12" of Octopus Server. Should one then interpret this to mean that 4.30.7 would only be compatible with "2018.2 ➜ 2018.12" or would that also include previous server versions such as 3.4 since the "latest" designation on "3.3 ➜ latest" would naturally include 4.30.7.

1. Given above ppint, exactly what does the "latest" designation mean within the following "3.3 -> latest", for instance, does it mean that the latest version will always support any version of octopus server beginning form 3.2 all the way up to 2019.1 (current version)? I ask simply because it is present on all of the version ranges for all the "related components".

The addition of the "* Partial forwards compatibility" section was very helpful and would suggest that maybe some additional sections similar to that would go a long way in answering some of the above questions I've expressed. I'm fairly that I am not the first person to ask for clarification on the compatibility table and it's unintentional confusion.

Lastly, it would be beneficial if this feedback feature also incorporated the capability to upload images, this would go a long to supplementing the questions/feedback provided and providing additional context to the topic at hand.

We have an service environment right now that consists of two data centers that each contains 3 servers that host the services. These services hosts host 100+ services each and each server is hosting exactly one instance of each service; so they are in effect mirrored.

When we deploy to these servers, we do it one data center at a time. Since there are so many services per server, we can’t just remove the server from the load balancer. Also since we do round robin load balancing and want to have zero downtime and keep consistency in our responses during deployments we create a rule in the load balancer to redirect traffic to the service to the opposing data center.

Our problem is that to define this behavior, we’ve had to effectively define two environments for each actual environment. One for DC-1 and another for DC-2.

If we were able to tag the machines with a role which corresponded to their respective data center and could do a rolling deployment per role, that would really help with the clutter in our Octopus deploy dashboard.