Scheduled re-deployments break lifecycle processes

Legacy Uncategorised
#1

I’ve got a life-cycle set up as follows (using Azure deployment slots):

  • Development (One of)
  • Dev Staging
  • Dev Production
  • QA Staging
  • QA Production
  • UAT (One of)
  • UAT Staging
  • UAT Production
  • Production Staging
  • Production Staging
  • Production Production
  • Production Production

Every environment below Production staging is considered transient and often gets torn down on a schedule.

The issue I have is that if I schedule a re-deployment to an environment (say QA Production), I’m unable to deploy to a later environment (i.e. UAT Production), even if I’ve already previously deployed QA until the scheduled deployment has completed successfully - cancelling the deployment doesn’t help.

Steps to reproduce:

  • Create lifecycle with at least two steps
  • Deploy a Release to an environment in the first step of the lifecycle
  • Check that the Release can be Promoted to an environment in the second step of the lifecycle
  • Schedule a re-deployment of the Release to an environment in first step of the lifecyle
  • Attempt to Promote the release to an environment in the second step - this is no longer possible

If there have been no changes to the release, I should always be able to promote it to a later step if it has been successfully deployed to meet the requirements of the earlier step.

Currently running 3.2.6

#2

Hi Ben,

Thanks for reporting this! I have submitted an issue into GitHub for investigation and a fix: https://github.com/OctopusDeploy/Issues/issues/2248
Feel free to track the issue. It probably won’t be looked at until after the new year, and I can’t think of a workaround apart from a successful deployment into those past phases. Maybe add a very simple skippable step to force a successful deployment if you have a failed one in those phases.

Cheers!
Vanessa

#3

Cool, many thanks - no worries about the lack of work-around for now, it was only because I was trying to be organised and set up the scheduled deployment well before I needed it.

#4