Select deployment target within an environment


Like most, we have dev, QA, UAT, prod, etc. However, we have 2 QA environments (QA1 and QA2). This is needed because sometimes new features will be in QA and an important production issue comes along that we need to rush through. So we use the QA2 machines to test the hotfix without disrupting the other QA testing already in progress (yes, I know that can cause issues and code needs to be synchronized). Anyway, we don’t want to alter the Deployment but we want the option to say "Deploy to QA, but use the QA2 server). I feel like these should be optional targets within an environment but I think I will need to create a specific QA2 environment and make the environment optional in the lifecycle (is there such a thing as optional?). One thing that would seem right would be to have the lifecycle specified not in the process but when I create a release. Is something like that possible?

Any ideas?

Hi Andy,

Thanks for getting in touch! You have two options here, which works best for you is your choice :slight_smile:

Firstly you will need to create it as an additional environment, this will be the best way to distinguish what you need clearly in all the other steps.

Option 1: In your Lifecycle have a QA phase, and add both of your QA environments, however then have it set to ‘deploy to at least 1 of these environments before continuing’. This is a way to make the QA2 deployment optional and all other deployments only having to hit QA1. This will give you slightly more flexibility with reusing releases to go to that environment.

Option 2: This is more formal. Create a second Lifecycle where the QA phase only goes to your QA2 environment, but have it as a separate channel on your process and include all the steps you need. Then when you create a release for this occasion you select the appropriate channel which will in turn select the correct Lifecycle.

Please let me know if I can expand on any of this or point you to the correct documentation of the option you think will be best for you.


Thanks for the help.
I’ve been working on option 2. I wasn’t very familiar with the Channels feature but I am starting to understand. I think it will work just fine for me.

Octopus is pretty flexible but as you know, every development shop does things differently and we are no exception. I like the version rules for channels. I’d love to say only a hotfix build can be used in the Release when my Hotfix Channel is used. The problem is, we identify hotfix builds in an odd manner. We use a build number scheme like this Year.DayOfYear.0.buildnumber (2016.12.0.1) however the existence of a 1 in the third spot (2016.12.1.2) means it is a hotfix. We can do things like this because really the build number only has value internally. In any case, it doesn’t seem like I can add a version rule to check that. If you can suggest a way to accomplish that, I’ll be pretty excited.

My next task is to figure out how to get Octopus to work with TFS to create release notes. I’ve got an idea to use PowerShell to:

  1.   Get the previous Prod Release from Octopus
  2.   Get the Build Version that was deployed from previous release
  3.   Use the current BuildVersion and previous BuildVersion to figure out which TFS work items are associated
  4.   Display a list of work item in the release notes.

I’ve seen some articles that try to do some similar things so I think it can be done. If you can offer any guidance on that task, please let me know.


Hi Andy,

What version of TFS are you using? There are much easier ways to do this with the new ones but the old ways ARE a bit hacky.
If you let me know I can guide you to the best advice.


I am using TFS 2013 (on premises). I am thinking about an upgrade to 2015. Sad to say our 2013 instance doesn’t have any of the updates installed.

Hi Andy,

Unfortunately if you are using that version then anything you will need to do will be hacky for what you require.
I believe there are quite a few different blog posts about it out on the web, we don’t specifically recommend any over others, it depends how you want to do it really and what works best for you.

As for the version numbers for your hotfixes - we really rely on SemVer and while its technically in a semver structure, it doesn’t follow the rules for increments so I can’t think of how it would be written or used as a rule. Your best solution would be to use a -hotfix tag instead or in conjunction. It just might be one of those dreaded have to make a change to match the tool terrible answers I sometimes have to give.

Let me know if I can help further.

Regarding the “-hotfix” idea… yeah I have been considering it and know what you mean. It may not be the perfect solution but it would work. Of course, I’d need to figure out how to get OctoPack to publish my Nuget package with the SemVer since that isn’t fully supported by Nuget.

In any case… can you send me a link to how I would create the release notes if I was using the latest version of TFS? That might provide just enough info so I can convince the higher-ups to let me upgrade TFS!

Thanks for all of the help,

Hi Andy,

OctoPack will allow -hotfix as that version of NuGet also does. While NuGet doesn’t support full SemVer it does for that part, we rely on it!

Here is the documentation with some screenshots: