Best approach for deploying related and unrelated projects

Many thanks for the detailed response Bob. I’ve set things up how I think they should be, and it’s mostly working. However, some of the projects aren’t deploying the latest version from Dev, but is deploying the highest version from any of the other environments (staging, temporary test environments, other customer environments etc) - e.g. Dev is at 1.10.0.21, QA is at 1.10.0.20 and a customer-specific Staging is at 1.10.10 - and the customer-specific staging version is the one that gets deployed.
Does Octopus pick the latest from any environment? Is there a way to specify which version or which environment should be promoted?
Thanks
Richard

Via a trigger there isn’t a good way, you’d be required to create channel rules which add to the complexity.

It is interesting it is picking 1.10.10, but you mentioned that is customer specific. Is this a multi-tenant project, and if do dev and QA being deployed untenanted or?

Thanks Bob. That’s not good news. We’re not using tenants, this is the same code deployed to different servers for each ‘client’. So we have our generic product which has - Generic QA, Generic Staging and Generic Live. Then we have a client product, built from the same code, Client1 QA, Client1 Staging and Client1 Live.
We also have a number of other environments falling (generally) in the Dev environment - Dev.Laptops, Generic Staging, Client1 Staging (mmm, that could be my problem).
Is there a way to perform an overnight deploy that promotes the current version on Dev to QA?

Thanks
Richard

What is tripping me up is why it didn’t pick 1.10.0.21 for the child projects. Isn’t that the most recent release created?

it’s because the 1.10.10 has only 3 fields (major.minor.buildnumber) while the real ones are 4 fields (major.minor.patch.buildnumber) and 1.10.0.21 is lower (patch number) than 1.10.10…
This was due to an error on someone else’s part while testing other deployments. What I’m concerned about is not knowing which environment it’s promoting from. It should always be Dev, not one based on rules I don’t know about…
Thanks again for your time
Richard

Hrm, another option will be to use the chain deployment step template instead of the deploy a release. https://library.octopus.com/step-templates/18392835-d50e-4ce9-9065-8e15a3c30954/actiontemplate-chain-deployment

The key difference with this one is you can either specify a release or ask for the latest release in the subproject’s channel.

Thanks again Bob.
I got to the bottom of the issue last night. The scheduled deployment was promoting the latest build to QA - regardless of whether that had been deployed or which environment it had been deployed to. So, if a project hadn’t changed for a month and was at 2.15.6.50, but a test version had been created later at 2.15.7, the automated deployment would promote 2.15.7.
I worked around the problem by deleting all the later releases which had 3-field version numbers (major.minor.patch). Obviously we need to be aware of this if we do manual releases again.
So it seems we can’t use this to promote what is on Dev, only the latest release.

Is there something we can change to promote what is on Dev, rather than the latest build?

I looked at the chain deployment step, but couldn’t see a way to use Dev as the source. Am I missing something?

Richard

Hi Richard,

Hrm, it shouldn’t be this hard. In my mind, this is a very common use case. I am working on a step template that will hopefully solve this use case. Timeline TBD, but I hope to have it out early 2021.

Thanks Bob. That was my feeling too. Octopus is so good, I’d think this should be bread and butter for it.
I was also wondering if we’d have the same problem with the next deploy - QA to Live/Prod

Richard

Hi Bob, I’ve just noticed that the Trigger for the orchestration project was set to “Deploy new release” rather than “Deploy latest release”. I had to choose this option to get the “Channel” option, which I selected as the “QA only channel” (as per previous suggestions above).
Is that all correct?
I imagine that selecting ‘Deploy latest release’ and picking Dev as the source and QA as the target would do the trick? But QA is not available as an environment as the target
Richard

That’d deploy the most recent release…but the versions of the child project are snapshotted at release creation time. You’d be deploying the same code over and over.

I’m not sure I understand that, but my earlier reply was wrong - it was the fact that Dev was not available as the source.
My only issue now is that the scheduled trigger is not working - deployments were set for 22:00, but failed to start. Any thoughts on that?
Thanks again
Richard

In general, when a trigger doesn’t appear to fire, you’ll want to find the task that processed the trigger. You can go to the tasks screen, then search by task type of Process recurring scheduled triggers. Find the trigger for your timeframe and look at the log. It does a pretty good job of telling you why it failed.

Cool, thanks for that Bob.
It’s trying to create release 2.35.1.2, despite the fact the last release (manual) was 2.35.1.18

I’m using the version template (defined in Orchestrator Settings):
#{Octopus.Version.Channel.LastMajor}.#{Octopus.Version.Channel.LastMinor}.#{Octopus.Version.Channel.LastPatch}.#{Octopus.Version.Channel.NextPatch}

Which I thought would increment the final field only - and set it to 2.35.1.19. It seems I’m missing something
Thanks
Richard

I apologize in advance for such a dumb question, but do you have more than one channel in that orchestration project, or did you go with a single channel?

There’s a default channel and a QA only channel

Hi Richard,

It appears to be an issue with the channel and the fourth number. I’ve tried both next path and next build and I got the same results.

The template I found that worked (and guaranteed uniqueness) was:

#{Octopus.Version.Channel.LastMajor}.#{Octopus.Version.Channel.LastMinor}.#{Octopus.Version.Channel.LastPatch}.#{Octopus.Version.Channel.LastBuild}-nightly.#{Octopus.Date.Year}#{Octopus.Date.Month}#{Octopus.Date.Day}#{Octopus.Time.Hour}#{Octopus.Time.Minute}

As for the actual process, I have wrapped up my step template and will be submitting it for approval today. Keep an eye out in the library for Deploy Child Project.

How it works:

You can provide a specific release (2020.2.2.1), a wildcard release (2020.2.2.*), or leave the value blank. If left blank it will attempt to find the latest release created in the source environment.

I have a different pattern per channel.

When the step ran for the QA channel it had two versions in dev.

It picked the 2020.2.2 release. It did this because it matched the pattern, not the most recent release.

It has a few other tricks up its sleeve.

Source environment:

  • If you provide a source environment it will look for the latest release in that specific environment
  • If you don’t provide a source environment it will use the destination environment and calculate what the source environment should be (that was…interesting to write)

Redeployment

  • By default, you can skip the deployment if it has already been deployed to the destination environment
  • That can be changed to always deploy

WhatIf / Testing

  • You can set a “what if” option to yes, which will do everything but run the actual deployment
  • If the what if option is set to yes, it will set an output variable “ReleaseToPromote” which you can use in subsequent steps (such as approvals, or running this step again but with whatif set to false)

Wait for deployment

  • You can tell it to wait for the deployment to finish or kick of the deployment and move onto the next project.

Hi Bob. That’s really good news - and it looks like a really good addition to the available steps.
Thank you for all your help on getting this sorted-out
I tried the version template you supplied and it worked perfectly - thanks for supplying that.

I’ll look for your new step - any chance you could add a note to this so I get emailed?
Thanks again and have a good Christmas
Richard

Awesome.

The new step was pushed up this afternoon: https://library.octopus.com/step-templates/0dac2fe6-91d5-4c05-bdfb-1b97adf1e12e/actiontemplate-deploy-child-octopus-deploy-project. It’s still a v1, so test it out on a few sample projects before going full YOLO on it.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.