I would like to hear you opinion on how to solve the following problem.
When we are building a version, let us say 1.6, the build server builds release candidates called 1.6.0.X, where X is our build number.
At a certain point, we test a release candidate and find the quality good enough to promote this particular build to be the official released version 1.6 - this could for example be the build version 1.6.0.1234.
The problem is then, that Octopus potentially have a lot of release candidates which could still be deployed, and the developers are losing the overview of which is the real release (1.6.0.1234).
Is it possible to somehow mark an already built Octopus release to be special (an official release), so the developers can clearly se which one is the correct one to use - for example in production environments?
Or have you another solution, that suits for this purpose?
You could have a “Release Candidate” (RC) environment for this purpose. Lets say you have 4 environments: Dev, Stage, RC and Prod.
Any developer can deploy to Dev.
Any developer can promote a Dev release to Stage.
Some developers can promote a build from Stage to RC. Everyone in the team could have “View” access to RC (so everyone is aware which version is the current release candidate), but only some will have write/deploy access.
This way, when devs sees a release in RC, they know its an important one that was probably approved by the QA & Dev team leads, and for that reason is one step away from Production.
Even less people will be able to promote from RC to Prod. All builds that go to Prod Must pass through RC first.
Do you think that approach might work for your scenario?
I am afraid though, that our situation is a bit more complicated than having one production environment as an end target.
We have a lot of different products and having them installed in different versions at different customer production environments.
Sometimes we need to install a test environment or a demo environment with a certain configuration of product versions.
This is excactly where it would be nice to have the official versions highlighted in some way, so you do not have to find this information elsewhere when deciding what to install or checking whether the correct version is installed.
If you could just look quickly through the installed versions for a given environment and conclude whether it consists of official versions or not, a lot of time and misunderstandings would be saved.
For example you could potentially ruin a demo for a customer, if a developer accidentally installed the buggy non-official version 1.6.0.1233 instead of the official “bug free” version 1.6.0.1234.
I think it would be easy to implement some property on a release marking whether it is highlighted or not, and then highlight these in the GUI
Sorry for the delay here. I mentioned this ticket to a few teammates during a meeting, and we all agreed it would be useful to be able to just mark/tag releases like that, and perhaps add a filter on the Project dashboard to be able to see only the marked releases.
We are currently working on Octopus 3.4, which will have a feature called “Multi-tenancy”. Now, though this feature has nothing to do with your feature request, its worth nothing that with it ,it’ll be the first time we’ll introduce the concept of “tagging” and the ability to filter by tag (in this case for “tenants”). During our chat with the team we agreed that we totally see this tag concept being expanded to other things, such as releases.
For the time being we won’t be adding this feature, as we’d like to see the community reception on Tags in 3.4. If it has a good reception (which I’m very sure it will), we’ll most likely add this to releases as well.
Have you received some useful feedback on Tags by the community?
And are you still considering to implement this feature for releases to solve my problem?
