Currently we are using Octopus Deploy version 3.4.12 and we have a lot of projects with Tenants. We tried to upgrade to newer version and we notice, that most of our tenants are not available for deployment. We started to investigate the issue and we found following change (2792 - Ensure a release goes through the correct Lifecycle phases for a tenant, even if the release has progressed past a phase for another tenant). Which in our opinion is breaking change, because it changing entire logic of the Lifecycles and tenants.
Currently our design is if release is deployed on Dev environment for one tenant it can be deployed to Test Environment of all Tenants in the Project, and it is working perfectly fine with version 3.4.12. Now we have to redesign our entire deployment process in order to be able to upgrade to the new version, which in my opinion is not acceptable.
Can you please advise how to solve this issue, because we would like to keep existing Lifecycle logic?
Thanks in advance,
Best regards,
Vladislav Atanasov
Hi Vladislav,
We certainly sympathize. This was a tough decision for us.
We had customers who believed the previous behavior was incorrect; and we agreed. There’s no easy solution; either leave it incorrect or potentially impact existing customers.
As a possible work-around, you could consider creating a special “Dev Tenant”, that only existed in your Dev environment, and remove the Dev environment for all other Tenants.
This should allow you to deploy to only the “Dev” tenant in the Dev environment, and then progress to the “Test” environment for all other tenants.
Could this work for you?
Regards,
Michael
Hi Michael,
We believe the new behavior does not work for us and the suggestion is not useful as well. And we are existing customers, too.
Having tenants working the way they do in 3.4.12 was a major part of our decision to choose Octopus Deploy instead of other solutions. So we are utterly disappointed in the way we had to deal with this breaking change. We upgraded and had production issues which lead to revert of the upgrade. All this cost our company precious resources at critical moment. Our management did not appreciate the fact that this happened and we may have a hard time to convince them to extend our Octopus license if needed. Related to that - there could be labels in front of each change in Octopus release history so that it can be easily seen if there are any breaking changes. You can check that we have contributed to support discussions which would be much less likely if we do not upgrade our Octopus instance.
More to the point though, I strongly believe the right solution is not to break existing customers functionality with some radical changes. The behavior - whether all tenants need to go through the lifecycle, could be an option of the project. This would allow customization which matches the existing standard in Octopus and could make everyone happy. The more customers one has, the better. What do you think?
Hi Ceco,
We truly apologize for any disruption. The last thing we ever want to do is inconvenience our users.
I have passed your feedback to the rest of the team. Speaking to the developers responsible for this, they said they only ever saw this change as correcting a defect. Apparently it was always the intention to enforce that tenants were deployed for each lifecycle phase, it was just implemented incorrectly.
We are interested to know more about your scenario. Would you be willing to explain why you wish to deploy a release to a tenant when that tenant has not been deployed in a previous phase?
Vladislav, we would also be interested to hear your scenario if you are willing to share?
Regards,
Michael
Hey Michael,
Of course I will explain. We wish to deploy a release to a tenant when the tenant has not been deployed in a previous release for a number of reasons. Your solution with <Environment TenantName> works in theory but in practice we will be overwhelmed. I am listing all of our reasons below:
- When we deploy one key product of ours we do not have enough accounts for a third party dependency. This dependency is needed in order for the product to deploy. So deployment would fail for a given tenant if another instance of it uses the same account in another environment. It is very inconvenient to stop a service with an account on a second-phase environment just to make a deployment to a first-phase one succeed and then restart the first service. This dependency has different variations with the same protocol. For one of it accounts are sufficient so we use that tenant in order for the release to go through the deployment phases. Unfortunately sometimes we do not have a choice but to to switch the accounts for the first-phase environment though in order to deploy the product for all our tenants. We’re in a bad position and struggling with this. And we’re striving to get more accounts but it’s not always easy and that’s where we are at the moment.
- We have 7 projects with very little tenants - 2 or 3. But 3 projects have more - 10-15 tenants. We have about 60 tenants in total. If we need to multiply some of them we will go beyond 100. Even with the tag-sets and filters that is far too much to view in the tenants tab and leads to inconvenience.
- When we open project overview there is a tenant/environment rectangle showing the release. For the projects containing 10-15 tenants we do want to see the rectangle as tight as possible (which is within one or two screens at the moment). If we multiply the tenants we will see at least 3-4 screens which is tough for us.
- Most of our tenants contain variables that have little or no impact on the behavior of the application. So we do not need to test each different tenant to make sure deployment is successful.
- We definitely want to be able to see the variables for a given tenant and different environments in the same screen. If we have multiple tenants that would not be possible.
You can see we make a heavy use of tenants and it would be great for us if Octopus makes this usage as smooth as possible. We liked the usage and obtained a license. I understand that the initial implementation was a defect. But we saw it and still see it (for the reasons above) as a huge benefit. And if there is a project option to customize the tenant-environment release progress it would be great for all customers. Also, we can upgrade our instance, use the latest features and provide you guys with feedback for them.
BTW Vladislav and I are Devops engineers in the same company.
Hi Ceco,
Thank-you for detailing your scenario.
I hope I can address some of you points:
When we deploy one key product of ours we do not have enough accounts…
I have to admit we didn’t fully understand your scenario here. Is it possible for this project you could simply create a Lifecycle that represented what you want to do (even possibly one with only a single phase)? For example, if you put your Dev and Test environments in the same phase then you can deploy to either whenever you want. Or, can you remove some of the tenants (even all but one) from the Dev environment?
Most of our tenants contain variables that have little or no impact on the behavior of the application
In this case, I feel like creating a “Test” tenant might work (or designating one of your tenants as a test tenant) and having only this tenant linked to the Dev environment.
Even with the tag-sets and filters that is far too much to view in the tenants tab and leads to inconvenience
We definitely want to be able to see the variables for a given tenant and different environments in the same screen
A number of your points seem to be UI-related, and not specifically about the Lifecycle issue. We are certainly open to any requests to make the UI function better for you. Some of our customers have ~1000 tenants, so we do certainly try and make the UI cater to large numbers of tenants.
The truth is, we still feel the current behavior is correct. We certainly regret the fact that we have changed the behaviour after you have established your processes. For this we sincerely apologize.
In case it helps, this blog post details the way we imagined it working.
Regards,
Michael
Hey Michael,
- We could workaround a lot of things, but we want to have a strict workflow because of the integration between different teams. We want to make sure no one makes a mistake. In Octopus this is achieved via lifecycles. We’re screwed that their behavior has changed so dramatically right after we’ve invested a lot of effort into this. I’ve personally advertised Octopus flexibility and I am disappointed this has backfired.
- We cannot make just a single tenant because we do need to deploy the same project for different tenants even on the Dev and Test environments. That’s what the development team has told our team. We explicitly requested the same thing that you want.
- I am happy that you want to make UI better. But the truth is that at the moment if we have to use your workaround using Octopus as it is may become a nightmare for us if we decide to continue using it and upgrade.
- We still think everyone can be happy if this is a project option. We accept the apologies but management, as usual, is interested in resource utilization.
Regards,
Ceco
I have created a UserVoice suggestion to make this behaviour configurable.
I would encourage you to add your votes or comments.