"Project Template Variable Sets" (3.4 Beta feedback)

Legacy Uncategorised
1

Our product is likely to have a large number of tenants, who generally have two different environments, consisting of multiple web applications and multiple databases.

This gives me a long list of variables (DB connect strings, IIS config, WCF service endpoints etc) for each tenant/environment combination.

Whilst this is now catered for using project variable templates, these do not have the structure that is given by the Library Variable Sets, and has resulted in a long, poorly organised list of settings in the Tenant Project variables page, shown in the order I added the variable templates.

I know that this may make a difference to whether our operations team will be willing to work with this as a deployment solution, but being able to group these settings into logically related sections (such as is possible with the Library variable sets) and maybe even restrict the scope of each set would really tidy this up nicely, and make it much more appealing to use when configuring a tenant/environment with a long list of settings.

Everything else about the 3.4 release looks fantastic to me - I think this one particular aspect is a bit less comfortable to use than the rest of your product. Have you any plans to do anything in this area before the full release?

Thanks,

Mark

2

Hi Mark,

Thanks for trying Octopus 3.4 and getting in touch with us!

We are planning to let you order the variable templates so you can control the display order on the tenant page, rather than be stuck with the database order. It sounds like this will help somewhat in your situation.

I would really like to see an example of what your resulting Tenant variables pages look like - could you send through a screenshot with sensitive details scrubbed? This would help add a lot of context for us. (Alternatively you could make this conversation private, or start a new private conversation to post the image)

I’m also interested to better understand what you mean by “being able to group these settings into logically related sections” - we currently group them by Project and Environment which seems to make sense in the scenarios we’ve been testing. Perhaps you could send through a mockup of the best possible layout for your scenario so we can contrast it to what we do today?

These two things would really help understand what would be the most useful layout for you.

One thing I’ll point out quickly is that we’ve deliberately designed the tenant variables API in a way that’s easy to build a custom form in your own application if you want ultimate control. We see this being really useful for crafting self-service sign up processes. To see an example visit the demo server and sign in as a guest, then look at the JSON returned by this API.

Hope that helps!
Mike

3

Hi Michael,

Thanks very much for getting back to me so quickly.

I’ve attached a screenshot (MT_Settings.jpg), as requested, which shows the settings for a tenant in tenants/Tenants-1/variables/projects.

It shows settings for a project consisting of two IIS applications, to be installed on different web servers and three different ReadyRoll database targets, potentially on different servers. Each of our customers will have their own UAT and Production environment, so I’m maintaining all of these settings for both environments. Using conventions to minimise the variation in the settings is not an option as many of our customers are either University or local-government run, and they will dictate their own conventions. In any case, these environments exist already before we will begin deploying this product, which is why a tool such as this is going to be so useful to us. But it results in a long list of settings per tenant for our operations team to keep on top of, and their buy-in to this will be key to its success.

I accept that there is some rationalisation that I can do on the settings that I have included (if I have the DB connection details individually, I don’t need the connect string as a separate setting, for example) but it’s a list that is actually going to grow, not shrink.

Being able to order this list would certainly help, but I still think it is quite overwhelming, and more difficult than it should be to locate a particular setting.

By ‘grouping the settings into logically related sections’, I mean logically-related in relation to our own product and environment to which the settings will apply. I do agree that they make sense logically within Octopus, but using the library variable template sets I would be able to group the settings into database settings for each of my three databases and IIS settings for each of my IIS applications. Web.config transforms for each of my IIS apps I could even split across several functionally-related groupings (in the context of our product).

To show what I mean, I just created a few library variable template sets (with a much-abbreviated list of settings) to show the UI that is rendered for those at /tenants/Tenants-1/variables/library (ExampleUsingVariableTemplates.jpg) which is about perfect. If only I could maintain these settings by environment for each tenant, it would be.

The side-by-side view of the environments’ settings in /variables/projects is functionally perfect, but just the addition of the headed panels in the UI of the /variables/library list transforms the usability and would really make the difference.

Please let me know if I can clarify this any further.

I must be honest, it hadn’t occurred to me to take the API approach to maintenance of settings, and I guess it would work, but adding more development to our own backlog to use this tool is obviously something I would be very keen to avoid, as I’m sure you’d understand!

Thanks again for all your work on this,

Mark

MT_Settings.jpg
MT_Settings.jpg812×2279 247 KB

ExampleUsingVariableTemplates.jpg
ExampleUsingVariableTemplates.jpg779×1171 86.4 KB

4

Hi Mark,

Thanks for getting back to us with those details. Taking the effort to produce the mockups really made a huge difference to how we understand the situation, and the best possible chance to implementing something suitable - thanks!

We’re discussing the impact of this concept at the moment, and considering designs to make this kind of scenario easier to work with. What makes this tricky is ensuring our design caters to the widest possible audience.

I’ll get back to you when I have more information!
Mike

5

Thanks, Mike.

I’ll look forward to seeing what you come back with.

Mark

6

Hi Mark,

We talked about the idea of allowing you to group and sort your project variable templates, and overall we think it’s a good idea. As an estimate, we are trying to get sorting done by 3.4.0 release, but I can’t guarantee we will get grouping done in that timeframe.

In the meantime, with sorting support, you should be able to artificially group your variables together, and add groups when we ship support for them.

Hope that helps!
Mike

7

Thanks, Mike.

That’s great. As you say, ordering the variables will give an instant benefit and knowing that the grouping is coming is really reassuring.

Thanks for your help.

Mark

8

Hi Mark,

Thanks for getting back to me to confirm that. Make sure to keep in touch if you have any other thoughts about your experience with Octopus 3.4. :slight_smile:

Happy Deployments!
Mike

9

Hi Mark,

I’ve logged a GitHub Issue you can track for this feature: https://github.com/OctopusDeploy/Issues/issues/2733

Hope that helps!
Mike

10

Hi Michael,

That’s great – thank you for that.

Mark

11

Notice:

This issue has been closed due to inactivity. If you encounter the same or a similar issue and require help, please open a new discussion (if we asked for logs or extra details in this thread, consider including them in the new thread). If you are the creator of this thread and believe it should not be closed let us know via our support email.

13