3.4.0-alpha0002 "Normal Deployment / Tenant Deployment"

Legacy Uncategorised
1

Hi

I’ve just been taking a look at the latest EAP. The only area that concerns me is the Normal Deployment / Tenant Deployment choice when creating a release. Could a normal deployment just be a tenant deployment without any tenants selected (currently this does nothing)?

I’m not actually sure what a “normal deployment” is meant to do. In the sample it looks like deploying without a tenant would cause problems as the tenant variables would not be set. http://octopus34alpha2.southeastasia.cloudapp.azure.com/app#/projects/chromatopathic/releases/0.0.1/deployments/Deployments-1 task logs shows Database Connection String: Server=db.chromatopathic.com;Database=#{DatabaseName}

2

Hi George,

Thanks for taking a look and getting back to us with your feedback! We have been wrestling with this concept as well, considering a few options. At this point we have changed the wording to be more like this:

What do you think about it?

We considered a couple of concepts during the design:

  1. All-or-nothing: If your Project is “multi-tenant” you are always required to have a tenant for every deployment. We don’t think this provides a very nice upgrade path. You would be blocked until every tenant was converted.
  2. Be flexible: You can perform good-old-untenanted deployments just like Octopus does today (where the tenant is essentially null and excluded from all varaibles/scoping/logic), or you can start to introduce tenants over time and begin deploying to them. We think this provides a much smoother upgrade path.

I think one of the nice things about the flexible approach is that you can still create tenants for every deployment into all your environments if that’s what you want to do. And if you don’t want to create tenants for your Dev environment, that’s fine too.

Unfortunately we hadn’t completed the variables work for Alpha 2, which is misleading in this instance, but it is working in our develop branch now. In the example project, we have a Project Variable that acts as a default in the case where there is no tenant, and that value will be overridden by the value provided by the Tenant.

If you always deploy to tenants in all environments, you don’t need a Project variable, just use the Tenant values all the time.

Let me know what you think!
Mike

3

Hi Mike

The new wording is better - it makes tenant deployments feel more normal :slight_smile:

What should happen if on a tenant deployment an environment is selected but nothing else? I think this would apply to our UAT env - we’d want to promote to all tenant UAT environments without any particular criteria.

One idea might be to be able to mark an environment as been Tenant Specific - meaning you can only deploy to the environment in the context of a tenant - so it wouldn’t appear in the deploy to one or more environments. Using this flag together with lifecycles would mean you could optimise the promotion UI. If we have Dev and QA. Where QA is Tenant Specific, and the release is deployed to Dev. The lifecycle states the next phase is QA. As QA is tenant specific there is no plain-environment that can be promoted to so only a tenant deployment can be performed.

4

Hi George,

Thanks for getting back to me. I’m glad that wording is better from your perspective.

Tenant-specific environments is an interesting idea - I’ll float the concept with the team.

Thanks again for the feedback!
Mike

5

Hi Mike,

I also agree with the suggestion from George in regards to marking environments as tenant-specific. For us, we would most likely have all environments except DEV (or LABS) marked as requiring one or more tenants to be selected.

In our environment we will have many hundreds of tenants and many thousands of deployment targets. I would only want to allow release engineers/managers to release to specific tenant environments. Rolling out a release to every production environment would usually not be allowed but it could be required for a specific project in special cases. I would rather the engineer went through and selected all the individual tenants (even if it is all of them) rather than blindly deploying to all. We may even have “internal” tenants to cover non-customer facing groups of servers and environments.

In addition to this, will environments be able to be grouped/viewed by tenant on the environment screen and could I set that as a default view? As soon as a new target/tentacle comes online I would want to be able to assign it to a particular tenants enviornment and then see that in the appropriate place on the environments screen.

Cheers,
Blair.

6

Hi George and Blair,

Thanks for continuing the conversation! Here are some of our thoughts.

Requiring tenants for deployments

I can definitely see the safety measure being important here. I don’t want to leak the Tenant concept into Environments if we can avoid it. As an alternative I think it makes sense for each Project to configure this behavior, like this example:

XC8QO2d.png930×655

What I like about this is:

  1. Environments don’t need to know anything about multi-tenancy
  2. You can “upgrade” project-by-project, and the upgrade path is nice and smooth
  3. It is “all environments or none” - but that would be pretty easy to overcome by creating a single tenant for your earlier environment(s) like Dev.
    a. What I like about this is that you don’t end up with a handful of the same variable values defined both on the project and the tenant.

Controlled deployments to environments

Blair you mentioned: I would rather the engineer went through and selected all the individual tenants (even if it is all of them) rather than blindly deploying to all. We may even have “internal” tenants to cover non-customer facing groups of servers and environments.

I think we already cater for this kind of scenario nicely in that when you perform a deployment to tenants, you need to select them individually, or by tag. There is not an out-of-the-box way to deploy to every tenant in an environment.

Environment screen improvements

We’ve got a couple of plans here (nothing locked in stone right now). Firstly we do want to make the standard environments screen scale much better for lots of deployment targets.

YL4FUIV.png1114×425

In this example you can quickly get a sense of what is happening across your server farms. We envisage you could also filter/search for tenant-related machines.

Similarly we are considering how to best handle the concept of “dedicated” versus “shared” hosting. Take this screen for example:

118KQzs.png885×660

I’m starting to lean towards having sense of ownership:

  1. Create a deployment target from the tenant screen = target is owned by the Tenant

    a. You cannot scope other tenants to that deployment target - much safer for the “dedicated” scenario

    b. Deleting the tenant would have a different impact on the target

  2. Create a deployment target in the environment screen = target is not owned​

    a. You can scope the deployment target to one or more tenants

    b. Deleting a tenant simply removes them from any target scoping, even if that would make the target empty

Some of these are just my initial thoughts based on the progress we’ve made on Alpha 2. What do you think?

Mike

7

The flag on the project will work fine for me. Cheers.