This was an issue for us in version 3.16 that was mitigated in 3.17 with a workaround but is now back in 4.x. We have a lot of project variables. Our approach was to take all the app settings in our web applications and Windows service applications and expose them as Tenant Variables. We have lots of deployables across different projects and for many tenants. The end result is 1000s of tenant variables that have to get set. The current Tenant Project Variables Editor page doesn’t work very well in this scenario. Ideally, I think this page should have many of the same features the project variable editor page has. If filtering were done on the server side, we could granularly filter a number of variables that are easy to review, compare and edit.
The current problem is that each keystroke takes about 1-2 seconds and choosing from a drop down takes about 15 seconds for us. In Version 3.17 we got a change that mitigated the problems by prefiltering the projects so that the page was smaller. I’m not sure if this is a regression, or the new UI framework is even less efficient.
Is this something you could look into improving? I agree having so many variables is probably not a good practice, but it is easier to expose all of them than finding out we need to change something and have to make a new build before it can be deployed.
Hi,
I am looking into the performance issues you described and will let you know if we can find any way to improve the performance of this page. I have a couple of questions though.
You mentioned the project filtering that is available on this screen in the 3.17 build. From what I can see a project filter is currently available on the 4.0 UI as shown in the attached screenshot. IS this not showing up for you or not working? Does this not help somewhat?
Secondly so that I can get a closer representation to what you are seeing could you explain how many Projects/Variables/Environments that you have?
Thanks for the extra information. Unfortunately these tenant variables screens are trying to model a slightly different shaped data to that on the standard project variables screen so although its not a perfect fit, we are interested in finding ways to improve its usability.
Finally what does your typical editing scenario look like? Would It help if you could edit some of these values from within the project, i.e, from the project variables template page perhaps you can see a view of this information “pivoted” by tenant rather than just on the tenant page pivoted y project? Perhaps the solution is more about making the information more contextually accessible rather than trying to squeeze performance out of a page that for some scenarios gives too much information. How do you use this screen and what are your thoughts?
Thank you for the quick reply. My Project Tenant Variables page is as shown in your screenshot and I do have to filter by project. Unfortunately, the experience I described was having already filtered by project and I think the slowdown occurs when I expand the project (I haven’t tried expanding all the projects without filtering).
We have 13 projects, 6 environments, 3 tenants and 4501 rows in the TenantVariable table. I’m not sure if this is an accurate depiction, but grouping by OwnerId shows our largest project has 2034 tenant variables and the second largest has 500. The project that has 500 variables is still sluggish, but still usable.
Our current usage scenario is as follows: Developers create the variable templates from the Projects page as they check in code that requires new config settings (app or web config). They also determine if the variable should have a default value. Then, they go into the Tenant Variables page to set the values for their Dev environment. The QA team does the same for their QA environment. These two environments get deployed to throughout the 2 week sprint. At the end of the sprint, the variables are documented and the Operations team deploys the release into their Ops environment. The Ops team also maintains the variables for the integration and production environments so they are the ones who spend the most time on the page setting values.
One unfortunate side-effect of the new design is it is harder to compare two environments because the variables are in a list starting at the top of the page whereas the previous design you could at least see two environments at the same time. The Ops team would find it useful to compare their values with the values set by Devs and QA. They need to ensure values are consistent across environments, tenants and sometimes even projects (some projects have similar settings, like logging locations).
Another scenario is when we create a new environment or a new tenant. In these scenarios, the Ops team has to go through and define all the variables from scratch. It would be really helpful if when they are setting up a new tenant, they could see the values from other tenants. Or if they were setting up a new environment, they could see what the value is in another environment.
I haven’t explored the new Project Variables page yet, but I did read the blog posts about the redesign and it sounded like it might provide the pivot capabilities that would really help out the Ops team to ensure each one of the 1000s of variables have the desired values. I also think it wouldn’t seem out of place if you could define tenant variables on the Project page. In fact, it was a little unintuitive for me initially to have to set values on the Tenant page of the website, far away from the project we’re wanting to deploy.
I created a (very rough) mockup of what I was envisioning.
I’m also following a conversation about empty or null values. When you define a variable template, currently there isn’t a way for you to specify if the variable is allowed to be empty. And you’re always warned if a variable doesn’t contain a value during deployment and it is called out on the current Tenant Variables page.
I think this concept could be incorporated on this page somewhere. First, add a Boolean value “Allow empty values” to the Project Variable Template form. Then, add a filter option “Show variables that are missing values”. Variables that are allowed to be empty aren’t displayed in the list
Hi again,
After a little bit of digging around I have found and fixed a potential source of performance problems on the tenant page. This fix should be included in the next release of Octopus (4.9.1 - corresponding GitHub ticket https://github.com/OctopusDeploy/Issues/issues/4161). Whenever you enter a key on this screen, all the input fields were being re-rendered. Give this update a go as soon as its available in the next week or so and let me know if it improves things somewhat.
Cheers,
Rob
