Unable to deploy a release when the environment has changed

Legacy Uncategorised
1

Hello, I’m evaluating v 1.0.13.1204.
Currently I’m stuck on what seems like a show-stopper bugs.
These are my repro steps:

  1. Create a new project and associate a machine
  2. Create a new release (ex. 1.0.0)
  3. Associate another machine to the same project / environment
  4. Deploy release 1.0.0
    —> release will be deployed only on the first machine!!

This seems due to the fact that, on RavenDB, the Release document is not updated when user changes environments / machines associated to the project.

2

Hi Manuel,

Thanks for getting in touch. This is actually ‘by design’, though I admit the design isn’t very obvious.

When you create a release, it takes a snapshot of your Steps and Variables - that way if you ever re-deploy an old release, you’ll have the same Step and Variables settings. So adding another machine requires a new release to be created.

This isn’t ideal, so I have a solution that I’ve been thinking about and will prototype this weekend. Instead of mapping Steps to Machines, you’ll assign a Machine a set of user-definable “roles” (e.g., ‘web-server’, ‘db’). Then when you define a step, instead of selecting machines, you’ll select roles.

This way you can add/remove machines, while the Release can continue to be a snapshot of the Steps and Variables as-at the time the release was created.

Let me know if you think that would work for you,

Paul

3

Hi Paul,
thank you for your quick response.
I’ve understand your point of view, but I think that the actual behavior is extremely risky: what happens if I MUST replace a machine because it’s broken / old / etc?

Your proposed solution seems to solve the issue, but please consider another (to be fair, much less common) scenario: what happens if I decide to add an environment to an existent project?
Actually there is no way to deploy an old release to the new environment…

4

Any news on this?
The proposed solution will be implemented? If so, when it will be released?

5

Hi Manuel,

I’m going ahead with this design (machines have ‘roles’, steps and variables are mapped to roles and not individual machines). I’ll attempt it after the next release.

I’m hesitant go much further and allow the variables of a release to be updated, because it makes it harder to track the promotion process properly. It seems wrong to present release 1.0 as being ‘promoted’ from Staging to Production when the variables were radically updated between staging and production.

Rather, the ‘right way’ (to me) is that you would create a new release (‘1.0-patch1’), select the same packages versions, and deploy that to production (or better, to staging again and then promote to production). Then it becomes clear that there’s a difference between the 1.0 deployed to staging and the one deployed to production. But I am open to being persuaded on this

Hope that makes sense,

Paul

6

We are having the exact same issue as Manuel is. Have you implemented this change request? Because this limitation will be a show stopper for us as well.

7

Hi Feliz,

Thanks for getting in touch. I’m actually going to be working on this over the next couple of days.

For now the temporary workaround is just to create a new release in Octopus (using semver tags, like 1.0.0.0-patch1) using the same set of package versions.

Paul

8

There more serious variant of this issue is that I am unable to deploy an existing release to a new environment. Instead I am forced to create a new release simply because this environment did not exist at the time the release was made. Adding a new environment and pushing an existing release out to that environment should be a handled scenario without the above mentioned work-around.

-h

9

Thanks for the feedback HBaz, I’ll make sure this scenario is supported when the feature is implemented.

Paul