How to passing a value to Octopus Deploy using Azure DevOps Release Pipeline

[Quads71]

I’m currently doing a POC where we are planning to utilize the Azure DevOps Server Release Pipeline to create and deploy an Octopus Release. During my testing I can hardcode the Release Number (default value is latest). But how can I pass a value to change the following Project variables in Octopus Deploy?

[Kenneth_Bates]

HI @Quads71,

Thanks for getting in touch! Great to hear you’re working on a POC, and I hope the process has been smooth for you so far!

You can control which variable value is used in different deployment contexts by defining their scopes. Meaning if one variable has two different values, each scoped to a different environment (as an example), deployments to these environments will pick up the applicable value. Would this give you the control you’re needing?

Additionally, you can provide a value to a variable at deployment time by defining it as a prompted variable. When deploying via the Azure DevOps plugin, you can supply the value by passing --variable=Label:Value in the additional arguments section of your Deploy step. You can reference the available arguments at the following doc page.

deploy-release - Octopus Deploy

I hope this helps! Let me know how you go or if you have any further questions going forward.

Best regards,

Kenny

[Quads71]

Hi Kenny,

Thank you for the quick response. My POC right now is not going well. So in my POC I have the two steps one is to create and one to deploy. For the create it looks like it went fine but in the screenshot the Version I pass is 2.19.3.2 which is the version of the package that I want the deployment to use. But as you can see the Version that it wants to use is 2.20.0.40, why? How can I override this value?

f

Now I look at the https://octopus.com/docs/octopus-rest-api/octo.exe-command-line/create-release link. I’m somewhat confuse with the following maybe you can help me.

–project=VALUE Name or ID of the project
–defaultpackageversion, --packageversion=VALUE
Default version number of all packages to use
for this release. Override per-package using –
package.
–version, --releaseNumber=VALUE
[Optional] Release number to use for the new
release.
–package=VALUE [Optional] Version number to use for a package
in the release. Format: StepName:Version or
PackageID:Version or
StepName:PackageName:Version. StepName,
PackageID, and PackageName can be replaced with
an asterisk.

Currently this is my Octo.exe arguments that I pass in the command line:

–variable=oTfsProjectName:$(Rel_Name) --variable=packageversion=$(Rel_Num)

So in the log I see this:

2019-09-12T13:02:44.3664096Z ##[command]“F:\Agent_work_tasks\OctopusDeployRelease_8ca1d96a-151d-44b7-bc4f-9251e2ea6971\2.0.135\Octo.exe” deploy-release --project=“DevOps2019_Dev2” --releaseNumber=“2.19.3.2” --server=http://xxxx.com/ --apiKey=*** --variable=oTfsProjectName:PHLY.GW.BC.HOTFIXES --variable=packageversion=2.19.3.2 --progress --deployto=“Development”

In the screenshot below you will notice the package is PHLY.GW.BC.HOTFIXES.2.20.0.40. but in command line argument I did pass 2.19.3.2 so where is the 2.20.0.40 coming from and how to I change this at runtime?

Should I be supplying the following command line parameters to make it work?
–defaultpackageversion, --packageversion=VALUE
–version, --releaseNumber=VALUE
–package=VALUE

If so would it be something like this?

–variable=oTfsProjectName:PHLY.GW.BC.HOTFIXES --variable=defaultpackageversion, packageversion:2.19.3.2 --variable=version, releaseNumber:2.19.3.2 --variable=package:PHLY.GW.BC.HOTFIXES.2.19.3.2

I appreciate your help. Thank you in advance.

[Quads71]

Hi Kenny,

In addition to my response, in the Azure DevOps release pipeline I first do a create release which I supply the Project Name and in the additiona Octo.exe Arguments section I entered the following: My thinking here is that the package id will be replace with the Package ID (see screenshot of the step). Is this possible? What is the proper way to accomplish this?

–variable=oTfsProjectName:$(Rel_Name) --variable=packageversion:$(Rel_Num) --variable=package:StepA:DevOpsDeployment:$(Rel_Num)

[Quads71]

Hi Kenny,

I apologize I should have done this from the beginning. So here is what I’m trying to accomplish and see if it make sense.

So our issue right now is as follows: Our development team has multiple ongoing projects, they also have numerous deployment targets for the sake of simplicity let me just call these targets as Dev1, Dev2, QA1, QA2, MO1(this is a UAT box), MO2 (this is a UAT box), Prod1, Prod2.

The task is to find a solution where depending on availability the deployment can go
Example1:
Dev1 --> QA2 --> MO2 --> Prod1

Dev1 --> QA1 --> MO1 --> Prod2

Dev2 --> QA1 --> MO2 --> Prod1

So the permutations can be enormous and when using Octopus by itself you have to create a Project that has a linear approach so we cannot go from Dev1 to QA2 etc., this is my understanding without creating multiple projects. I could be wrong.

The question here is how can this be accomplish? The initial thinking is to create what you see in the screenshot and have it point to a Octopus project dedicated to a target machine (i.e. Dev1, Dev2, etc.)

Below is the current setup I have for this POC each project can only deploy per name (i.e. DevOps2019_Dev1 can only deploy to a Dev1 box) and it cannot be promoted.

The other question I have is what if the package id for example the initial deployment is called “PHLY.GW.BC.RELEASES” and then later on there is a hotfix so now the name is called “PHLY.GW.BC.HOTFIXES” per my testing this seems like not possible. I’m hoping to get some suggestions on how this can work. Or other alternative.

[Kenneth_Bates]

Hi @Quads71,

Thanks for following up and supplying all of that great comprehensive information. I’m sorry to hear your POC so far hasn’t been as smooth sailing as we would hope!

From how I’m understanding your requirements, you’d want to specify your package version value in your create-release step by passing --package=VALUE, in your case it’d look something like --package=DevOpsDeployment:2.19.3.2 (PackageID:Version). It looks like currently the latest package version is being selected by default for the release. Prompted variable values are supplied to them at deployment time, and not at release creation time. So passing the --variable=Label:Value for the package version won’t work to specify the package version the release is created with.

There a couple of potential ways to address the need to deploy through any of these permutations of targets. You could split them up into separate environments and define your lifecycle(s) to include optional phases. Or maybe even use the channels feature which would allow you to create releases that progress through another lifecycle (which is often used for hotfixes that you mention in your next question). With channels, you can also define version rules to automate package versions being selected when creating releases. It might be worth having a read of our channels documentation, and I’d be interested to hear if it helps.

Channels - Octopus Deploy

I hope this helps! Don’t hesitate to reach out if you have any questions or concerns moving forward.

Best regards,

Kenny

[Quads71]

Thank you Kenny, Octopus is somewhat new to me. I barely touch it until this POC. I will read through the documents you mentioned and if you do not mind maybe I will be reaching out to you for best practice approach.

[Kenneth_Bates]

Hi @Quads71,

That sounds good! We’ll be here to assist in any way we can if you have any questions or concerns in the future.

Best regards,

Kenny

[Quads71]

Hi Kenny,

Good morning, ok I think I finally able to figure out the channels I do have a question regarding environments. I understand a deployment target can be set to a target roles which that target roles can contain multiple deployment targets. My question is, what is the best practice and is it possible to specify a deployment target during a release? For example a Target Role called “Dev1” has 2 machines but I want to only deploy to 1 or the 2 machines.

I found this variable from one of your reply from another post, the question I have is are you supplying the display name, the tentacle URL or the actual machine name? It is not clear from the guide. Can you give an example?

–specificmachines=value

Per your site:
–specificmachines=VALUE
[Optional] A comma-separated list of machine
names to target in the deployed environment. If
not specified all machines in the environment
will be considered.

[Kenneth_Bates]

Hey @Quads71,

Thanks for following up! The --specificmachines=VALUE argument expects the actual machine name(s) given to them in Octopus. These will be shown as the Display Name in the web portal. This will then deploy the specified release only to the targets you’ve specified. You can also do the opposite by specifying machines to exclude in the deployment by using the --excludemachines=VALUE option.

You can also do this same thing when deploying in the web portal while in the deployment page, as shown below.

I hope this helps! Let me know if you have any other questions or concerns moving forward.

Best regards,

Kenny

[Quads71]

Hi Kenny,

Thank you, I actually figured it out through trial and error yesterday but it just confirmed by your response. Regarding the excludemachines that is a good to know. I did not realize it is available now in the command line argument.

Have a nice rest of the day and weekend.

[Kenneth_Bates]

Hi @Quads71,

Thanks for following up, and that’s great to hear you got it sorted! Don’t hesitate to reach out if you have any questions or concerns in the future.

Best regards,

Kenny

[Quads71]

Hi Kenny,

Our POC so far is moving in the right direction but I have a question regarding promote-release? What is this use for? In our POC we are using the Azure DevOps release pipeline to call an Octopus command line. Currently I’m just using Create -release and Deploy release and have a command line parameter to ignore the create release if it is already present.

I looked at the Promote-release documentation but it does not have much of information as to when it should be used and in what scenario. That would be beneficial for someone like me who is not a Octopus Deploy user nor expert.

[Kenneth_Bates]

Hi @Quads71,

That sounds great! Regarding the promote-release command, this will simply take the latest successfully deployed release to the specified environment, and promote it to another. It might be easier to visualize, so I’ve pasted a screenshot below.

Here I’m using the following command, which will deploy release 0.0.2 to my Test environment: octo.exe promote-release --project="Web App" --from="Dev" --to="Test" --server="OctoURL" --apikey="API-XXX"

If you’re instead simply promoting your releases through your lifecycle via the web portal, you could safely just avoid this command from your Azure DevOps setup.

I hope this helps! Let me know if you have any further questions or concerns moving forward.

Best regards,

Kenny

[Quads71]

Hi Kenny,

Appreciate the quick response. So in my POC it seems like just using the Deploy release works just wondering is there any additional benefit by using the Promote release? Is it needed or can it be skipped?

Our current workflow needs the ability to be able to go for example Dev Environment (can be one or more machines) --> Testing Environment (can be one or more machines) then a possibility to either go back to Dev again (different machine) or to another Testing environment (again different machine). If I’m guessing here the Promote Release will promote it to the next environment but once you promote can you still go back to a lower environment? These are extreme examples but possible in our environment.

I think for a straight happy path of Dev --> Testing --> Acceptance --> PROD the promote release is the ideal way to go.

[Kenneth_Bates]

Hi @Quads71,

You’re quite welcome! You can use the promote-release command to deploy to an earlier environment in your lifecycle, though this specific command probably isn’t optimal based on the scenario you’ve described. You can also specify the environment to deploy to using the deploy-release command that you’re more familiar with, while specifying the release version to deploy. Referring to my screenshot pasted in my earlier reply, the following two commands do the exact same thing (where the promote-release will take the latest release in Dev to deploy to Test):

octo.exe promote-release --from="Dev" --to="Test"
octo.exe deploy-release --version=latest --deployto="Test"

However the promote-release command doesn’t have a release version option, so it will always take the latest release which has already been deployed to an environment, whereas the deploy-release command requires the release version to deploy.

I hope this helps!

Best regards,

Kenny