Deploying Branch related packages to Environments

I am trying to deploy to Environments based on the feed directory holding packages.

I have attached the scenario I am using.

Before I give up and just clone all my projects, I would like to know if I am doing it wrong or if it will be in the 3.2 release which supports Branches.

octoerr.docx (47 KB)

Hi,

Thanks for reaching out. Your apporach should be working. Could you please follow these instructions and send us a raw log so we can see what is going on?

  1. Add these 2 variables to your project http://docs.octopusdeploy.com/display/OD/Debug+problems+with+Octopus+variables

  2. Create a new release (so the new variables take effect) and deploy it.

  3. Send us the raw log of that deployment http://docs.octopusdeploy.com/display/OD/Get+the+raw+output+from+a+task

Regarding your question about the Branching feature: In 3.2 you’ll be able to have all the packages in the same feed, and point branches to specific ranges or branches of your packages. So your scenario will be much easier in that version.

Thanks,

Dalmiro

Hi Dalmiro,
Thanks for the quick response.

Attached are the logs for each run:

TEST01 still fails.

The following line from the log file indicates that Octopus is resolving the Package Version before establishing the Environment and I cannot see how that will work.
14:38:36 Verbose | Checking package cache for package Game.Product.Service.Host 1.0.0.43252

Until the Environment is resolved the location of package will not be found in the relevant package feed location.

Variables and Feed locations below.

[cid:image001.png@01D0EFC7.225F36A0]
[cid:image002.png@01D0EFC7.225F36A0]

[cid:image003.png@01D0EFC7.6697A910]

Don’t see the expanded variables in the TEST01 file either?

Terry

ServerTasks-2100-TEST01.log.txt (9 KB)

ServerTasks-2103-TEST02.log.txt (27 KB)

Hi Terry,

Sorry for the delay here. Did you create a new release for TEST01 after adding those variables so they take effect? re-deploying a release created prior to adding those variables would explain why they dont show up.

I’ve reproduced the expected scenario on my lab and took screenshots of the whole process while adding some notes. Please take a look at these notes to try to figure out what’s different on your end:

[Each step has its own screenshot]

  1. This is the configuration of the feed TestFeed. Notice that the feed ID is feeds-testfeed

  2. Config of feed TestFeed15.3.0. Its feed ID is feeds-testfeed15-3-0

  3. This one looks pretty much like yours. The value of the variables must be identical to the feed’s IDs.

  4. Using a custom expression and only putting the variable #{f1} in there.

  5. Creating the release. At this point the environment still hasn’t been set, so by default Octopus will use the value of #{f1} that its not scoped to any environment, which in this case is feeds-testfeed. Octopus finds a package with the name “testConfig” on feeds-testfeed which makes him happy enough to let us continue with the release creation.

  6. When we finally deploy to TEST01, Octopus re-evaluates the value of #{f1} and realizes there’s a version of it that is scoped to this particular environment. So it changes its value to feeds-TestFeed15-3-0 which points to C:\Feeds\TestFeed15.3.0

  7. When we deploy to TEST02, Octopus again re-evaluates the value of #{f1} and changes its value to feeds-TestFeed which points to C:\Feeds\TestFeed

If after checking this you still can’t find what’s wrong, my recommendation would be to:

  1. Upgrade to the latest Octopus version (currently 3.1) and try again.
  2. Schedule a call so we can troubleshoot this together on a screensharing session: https://calendly.com/dalmirogranias

Best regards,

Dalmiro

Hi Dalmiro,
I will go through your scenario and see if I can spot what is wrong.

One point though.

To create a release I am doing this:
octo create-release -project “Logistics - Meta - T1” --deployto TEST01 --ApiKey=xxx --server http://gm-t-ho-oct-01

So, this will create the Release and Deploy in one action.

Could that be an issue?

I am also in the process of upgrading to 3.1

Terry

Hi Dalmiro

I can see why your scenario works and mine does not

Just to clarify

The feed-id is getting identified correctly but the package appears to be the same version in each feed location.

In c:\feeds\TestFeed create a package called TestConfig.1.0.0.123.nupkg
In c:\feeds\TestFeed15.3.0 create a package called TestConfig.15.3.0.456.nupkg

What you will see is that initially the Package gets resolved as TestConfig.1.0.0.123 and then when the Environment gets resolved to TEST01 Octopus tries to deploy TestConfig.1.0.0.123 from the
Feed directory c:\feeds\TestFeed15.3.0 which it will not find

So, the resolution at Deploy time nedds to understand the version number of the packages?

Terry

Hi Terry,

What you’ve described is exactly what is going on. This is exactly the scenario we are going to support in 3.2 with the support for Branches. You’ll be able to set 2 different branches of the same project, and each will be able to point to different feeds and different version ranges of your packages.

At the current version, the easiest way to manage this would be to make a clone of this project and have each project use a different feed.

Best regards,

Dalmiro

Hi Dalmiro
This is what I feared. We are likely to have hundreds of projects with 3-4 branches.

When is 3.2 likely to be released?

I have got a Powershell script to Clone a project and I could spend some time getting it to clone and then alter the feed-id using the Octopus Client dll.

But I am also happy to be a BETA tester for the feature if that is possible.

Regards

Terry

Hi Dalmiro,
I have just realised that the clone script I am using is yours.

An excellent piece of work.

So all I need to do after Cloning the Project is to reset the feed from Testfeed to testfeed15.4.0

Is that really simple to add into the .\CloneOctopusProject.ps1 script?

Regards

Terry

From: Terry Ninnis
Sent: 21 September 2015 17:50
To: 'Dalmiro Grañas’
Subject: RE: Deploying Branch related packages to Environments [Questions #5600]

Hi Dalmiro
This is what I feared. We are likely to have hundreds of projects with 3-4 branches.

When is 3.2 likely to be released?

I have got a Powershell script to Clone a project and I could spend some time getting it to clone and then alter the feed-id using the Octopus Client dll.

But I am also happy to be a BETA tester for the feature if that is possible.

Regards

Terry

Hi Terry,

We don’t have a specific date for 3.2 yet, but we are commited to shipping new versions and fixes every a couple of weeks instead of months -> http://octopusdeploy.com/blog/continuous-delivery-of-octopus

We have just released 3.1 a few hours ago, and we’ve been running 3.2 builds for a couple of weeks already. So stay tuned to our blog as we’ll be releasing a pre-release/beta version for anyone that wants to test it. Trust me when I say it wont be too long before you can get your hands on a 3.2 build.

Regarding the Powershell script, I’d recommend you to let the feed as a variable and clone the project that way. Then have each project team modify that variable accordingly on their own project. This recommendation is mostly because the feed reference is set on the Nuget Deploy step on each deployment process, and its way easier (and safer) to deal with variables than modifying a deployment process from a script.

If you need to programatically add the variable to a project, let me know and I’ll give you a script to do it.

Thanks,

Dalmiro

RE adding the variable: Take a look at this script from the Octoposh module, also written by me.

Hi Dalmiro,
Excellent stuff

Clone script with a call to Update-OctopusVariableSet is perfect for me.

Many thanks for pointing me in the right direction.

I can live with this and look forward to the 3.2 release.

Terry