New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve tenant-selection UI when deploying a release #4112

Closed
MJRichardson opened this Issue Dec 19, 2017 · 5 comments

Comments

Projects
None yet
5 participants
@MJRichardson

MJRichardson commented Dec 19, 2017

Summary

When deploying a release, we want to make the following scenarios easier:

  • Deploying to all applicable tenants for the environment
  • Skipping those tenants which already have the release as the current version for the environment

Related Issues

#4029 will interact with the proposed changes.
This issue supercedes #3951.

Proposal

We are proposing to add three new options to the Tenants section of the Deploy Release page.

1. For mixed-mode projects, we will add an explicit Untenanted\Tenanted radio select.

mixedmode-untenanted

2. Add an All Applicable Tenants option will remove the need to select individual tenants or tags.

tenanted-allapplicable-skip

3. Add a _Skip tenants where {{Version}} is the current version deployed to {{Environment}} option.

tenanted-tags-skip

Scenarios

Deploy a brand new release 1.2.5 to the Production environment for all Tenants

Assumes tenanted-deployments-only project

  1. Choose release 1.2.5
  2. Click Deploy to Production
  3. Click Deploy

Deploy 1.2.5 to the Production environment for all Tenants where 1.2.5 is not the current release on the dashboard (already deployed 1.2.5 to some Tenants)

  1. Choose release 1.2.5
  2. Click Deploy to Production
  3. Click Deploy

Skip tenants where 1.2.5 is the ... would be selected by default. Octopus will then only create deployments for the Tenants where 1.2.5 is not the current release on the dashboard

Deploy 2.0.0-beta.1 to the Beta environment for all Tenants who have opted in for the beta program (via channels)

  1. Choose release 2.0.0-beta.1
  2. Click Deploy to Beta
  3. Click Deploy

That Release will be assigned to the Beta channel, which will be associated with the appropriate tenant-tags. These tags will be selected by default on the deploy-release page.

Re-deploy 1.2.5 to the Production environment for all Tenants, regardless of their current version on the dashboard

  1. Choose release 1.2.5
  2. Click Deploy to Production
  3. Un-selected the Skip tenants where 1.2.5 is the ... option
  4. Click Deploy

Octopus would ignore the current state of the dashboard, and create a deployment for the Production environment for all tenants, effectively redeploying 1.2.5

Deploy 1.2.5 to the Production environment for Tenant-A and Tenant-B

  1. Choose release 1.2.5
  2. Click Deploy to Production
  3. Select Tenant-A and Tenant-B
  4. Click Deploy

Octopus would consider the fact that you've specifically selected Tenant-A and Tenant-B as fact: you want to deploy release 1.2.5 regardless of the state of the dashboard. The Skip tenants where option will not be displayed.

@MJRichardson

This comment has been minimized.

@mayuanyang mayuanyang closed this Jan 5, 2018

@octoreleasebot octoreleasebot added this to the 4.1.8 milestone Jan 5, 2018

@mayuanyang

This comment has been minimized.

mayuanyang commented Jan 5, 2018

Release Note: Make the following scenarios easier:

  • Deploying to all applicable tenants for the environment
  • Skipping those tenants which already have the release as the current version for the environment
@kneumei

This comment has been minimized.

kneumei commented Jan 16, 2018

In our workflow, we've found pre-filling the channel tag to lead to unintended deployments. The situation is like this:

  • We have a test and a prod tenant for our Acme customer that happen to be associated with the same environment (since they share the same physical machines).

  • The Test tenant is tagged with both "Release" and "Beta" channel tags.

  • The Prod tenant is tagged with only "Release".

  • We create a 1.2.5 release in the "Release" channel.

  • We deploy the 1.2.5 release. We choose an environment. Then on the deployment page (/projects/myproject/releases/1.2.5/deployments/create/to), we find that the "Release Channel" tag is pre-filled with "Release".

  • The person doing the deployment may not notice the tag is prefilled, and just selects the tenant name of the "Test" tenant. He expects that this release will be deployed to the "Test" tenant only. The preview for which tenants will actually be deployed to is at the bottom of the screen and you have to scroll down to see it. The deploy button is at the top of the screen, so it's easy to miss. He clicks deploy and now we've deployed to both Test AND Prod

I realize that one solution would be to create separate environments for our Test and Prod tenants...but our configuration is actually more complex than this...it's not uncommon for us to have multiple staging environments for a single customer, which we might need to have different versions at different times.

Another solution would be to just not use channel tags at all. We opted to use them to prevent accidental deploys of the wrong release to a tenant. (For example, don't want to deploy a "Beta" to prod).

We find tenants very useful for multiple reasons (tenant tags make it easy to search/sort and assign permissions....tenant variables/templates are very nice, etc), but we do not make heavy use of ability to deploying the same release to multiple tenants using tags.

I realize you need to support lots of use cases, and I appreciate you considering this one. I would be happy to hear that there is a better way of doing something or that I've misused a feature, if this is the case.

@NickJosevski

This comment has been minimized.

NickJosevski commented Apr 3, 2018

Hi @kneumei

We raised this other issue so we would have a tracking point for this particular case if more customers reported the same frustration. Over the last few months as more customers upgraded/installed the 2018 releases of Octopus Deploy it hasn't come up.

The pre-filling is there to help the common use case of customers deploying to many tenants. The summary we show on the screen is there to be clear how many tenants it will be deployed to. Your configuration of tenants and tags is valid, but to us it feels like the members of your team doing the deployments need some more guidance to review carefully before they hit deploy.

We're reluctant to overload this screen much more, and do not want to introduce more clicks (hurdles) in the deployment process. But after some thought this morning, maybe a small UI could help you out...

Would changing where we have Tenant Preview action to also mention how many tenants there are help? like this:
image

Or is it still below the area in which your deployment team is looking, if they looked that low they would already notice the pre-filled tag.

What if that Tenant Preview - 2 Matching Tenants text was at the top of the list of tenant and tag selection would that be help in your case? like this:
image

Can you think of any other simple changes we could make to cater for your case and prevent unintended deployments?

@kneumei

This comment has been minimized.

kneumei commented Apr 3, 2018

Nick,
Moving that up would definitely be helpful I believe.

I completely understand the use case your describing. To me it seems like the channel tag is kind of overloaded. The main thing I'm trying to do is restrict which tenants a particular "family" of releases can get to. It does that. But it also does this other thing to help streamline deployment to lots of tenants.

Maybe there's some other way I might be able to put a restriction in place as to which releases may be deployed to which tenants. other than creating lots of environments and using lifecycles?

If anything else comes to mind I'll let you know.

Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment