I have a project in Octopus with a complex process for three environments. There are 3 deploy package steps that look like this:
Deploy Alpha -> Package A
Deploy Beta -> Package A
Deploy Prod -> Package B
Package A is all the raw compiled files which is being generated via Azure Pipelines. The alpha deploy puts them on a test server whereas the beta deploy (multiple steps) zips the files up and dumps them on AWS S3. The prod pipeline in Azure has steps to create Package B and upload it accordingly to Octopus; it does not exist until the prod pipeline runs. The prod deploy (multiple steps) does some work with the files and then dumps them to AWS S3 as well.
Now the problem… In Azure when the Create Octopus Release step runs for alpha, I get the following error:
# Name Version Source Version rules
--- ----------------------------- ------------ ------------------ -------------------
1 Deploy to Alpha 1.0.4.5324 Latest available Allow any version
2 Deploy to Beta 1.0.4.5324 Latest available Allow any version
3 Deploy to Prod ERROR Cannot resolve Allow any version
However, the process in Octopus has the Prod step tied to only the prod environment.
Is there a reason it’s trying to resolve all packages even though the step will be skipped since its not a prod environment push? Is there a way to get around this problem to allow a different package to be used in the same Octopus process that is generated later?
Releases aren’t environment-specific, so, when the Create Release step runs it does so expecting to be run against all applicable environments, and therefore needs to be able to resolve the packages for all relevant steps.
My first thought here would be to look at whether Channels would help alleviate this problem. The basic idea would be to split your environments between two channels. One for Alpha and Beta and one for Prod.
Each Channel would need a Lifecycle applying to them, so, instead of one lifecycle that covers all three environments, you would have one lifecycle with Alpha and Beta and another lifecycle for Prod.
The Deploy Prod step with Package B would be amended to only apply to Channel Prod. This would then allow you to create releases for Channel Alpha\Beta without needing to resolve package B.
You would likely need to also amend your Azure pipelines to ensure the Create-Release steps are aiming at the correct Channels.
The only real downside of this approach is that within Octopus you would no longer have a Release that progresses through every environment, instead, the Releases would be split between the Channels and environments. However, it sounds like your Azure pipelines are already creating Releases for each environment like this, so, it may not be a concern.
Let me know if you’d a bit more explanation on any of this. I can always throw together some screenshots of what it would look like and the configuration steps.
Thanks for the info Paul. I’ll look into the Channels stuff.
A bit more information as there may be other options out there I am not aware of. Package A is just binaries for testing purposes. Package B is an installer created with https://jrsoftware.org/isinfo.php. The reason why they are separate is the installer includes extra files and ends up around 1GB whereas the binaries are only 10MB.
Is there some sort of installer process that others use or is recommended?
It honestly comes down to what works for you. Many people will use the octo CLIpack command to create their packages as zips or NuGet packages and then use the same package throughout their testing.
I don’t see any real problem with doing things your way, though. If I’m being pedantic, then there is the potential issue that whilst your application is tested using the binaries, the installer itself isn’t, so if something went wrong during the creation of the installer, you wouldn’t know about it until it is deployed to the production environment.
A pre-prod or staging environment in the second Channel where the installer is deployed and confirmed as acceptable before the push to prod would mitigate this. Still, ultimately it comes down to whether you think this is a valid concern or not.
Alright. I set the project up in Octopus with two channels: Test and Installer. The Octopus process then has the various steps tagged with which channel it should execute on. Now the Deploy Octopus Release step in Azure does not have a channel explicitly shown, but according to the CLI documentation, it can use the ---channel=VALUE flag which I have added in as an additional argument.
Could you check the project within Octopus and see which Channel release 1.0.4.5330 was created within?
If the Release was created within the Test channel then it can only be deployed to that channel. Adding the --channel won’t really make a difference (I’m honestly not sure why that argument exists for this command. You always have to specify the Release ID, and a Release can only ever exist in one Channel, making this argument completely redundant).
You will likely need to check your Create-Release steps and add the -Channel argument to those steps to ensure that the Releases are created in the Test or Installer Channels as needed.
I’ve put back in the Create Release step in Azure as part of the pipeline. The error it throws now is:
Release '1.0.4.5330' already exists for this project. Please use a different version, or look at using a mask to auto-increment the number.
I think this is what you were eluding to earlier on with it not being traced all the way through? So I am guessing I need to tag the Package for Octopus step earlier with a different version, say {Version}-installer. Is that the case or am I missing something?
That’s correct.
Within SemVer adding a dash to the version typically signifies a pre-release package, so, I’d be tempted to modify the pipeline for the binaries package to create {Version}-binaries and leave the installer one as is.