Support conditional deployment steps

Legacy Uncategorised
1

For instance, based on which Environment is used, a certain deployment step should (not) be executed.
This allows different environments to pick from different package sources as well, as a package source is bound to a deployment step.

2

Hi Xavier,

This can somewhat be achieved by not selecting any target machines for the package in the environment.

For example, if Package A has machines elected in Dev, but not Production, then it will be skipped in Production.

Is that what you had in mind?

Paul

3

Hi Paul,

I want only one of the environments to be targeted actually (based on a condition, e.g. the environment parameter), not both.
Both environments share a common target machine (my localhost).

Let me put this in context :slight_smile:

I’m using a continuous delivery setup on my workstation with a local TeamCity and local Octopus installation.

If I am connected to the internet, TC is building against the VCS remote, pushes the octopus pkg to MyGet, and triggers Octopus through octo.exe to deploy the package to every machine within the defined environment.

If I’m working offline, TC builds against my local clone, pushes the octopus pkg to a local repo, and triggers Octopus through octo.exe to deploy the package on my localhost.

It’s the same package, the same project. Only a different pkg source and target environment, based on the online or offline scenario.

A simple condition on a deployment step (e.g. if env == local, then skip), or a parameter for the environment to be used by octo.exe would solve this.

Now I have worked around it by creating two different Octopus projects, each with their own separate environment to be used in a single deployment step, and updated the TC build step to instruct octo.exe to pick the correct Octopus project based on offline/online situation.

4

Hi Xavier,

I think this could be accomplished using one project configured like this.

Assuming you have two environments, “Local” and “Remote”, and two NuGet feeds “LocalPackages” and “RemotePackages”, you would create two steps like this:

Step 1: Deploy YourPackage from LocalFeed to machines in the "Local" environment
Step 2: Deploy YourPackage from RemoteFeed to machines in the "Remote" environment

It would have the effect of skipping step 1 when deploying to the Remote environment, or skipping step 2 when deploying to the Local environment.

As I think about this, I think there might be a bug at the moment because I think it might fail to download the package from the remote feed if you are offline even if none of the machines need it. So for now the two project solution you have is probably best, but going forward I think you could condense it into one. Hope that makes sense,

Paul

5

Hi Paul,

I think the bug you mention is indeed what forced me into thinking there was something missing :slight_smile:

That’s exactly what is happening: the task fails because it attempts to fetch a package from a pkg source location linked to a step that has no machines checked for the target environment.

2012-01-13 21:07:06 INFO   Stage 1: Downloading packages from NuGet servers
2012-01-13 21:07:09 ERROR  System.AggregateException: A child activity failed. ---> System.AggregateException: One or more child activities failed ---> System.Exception: Could not find package MyGet.Web 1.1.1.6 in feed: 'D:\TeamCity\buildAgent\work\57a20f49a318b9b8\Sources\MyGet\MyGet.Web\bin'
at Octopus.Server.Tasks.Deploy.PackageFetcher.Fetch(String feed, String packageId, String version)...

Keeping the double project setup for now :slight_smile:

Thanks!
Cheers,
Xavier