Can "Automatic Release Creation" use more than one "Release Creation package step"?

Legacy Uncategorised
1

I currently have two steps for each applications’s deployment process.

One step creates a release targeted at one environment (dev), and the other step created a release targeted at another environment (qa). When I either use TeamCity to create packages, or create them manually in Octopus, I am able to just run both steps and generate a release with both versions. The “Automatic Release Creation” appears to only allow one deployment process step (“Release Creation package step”) to be selected, which prevents me from using this feature. Why? Am I missing something? Is there a workaround to allow more than one step to be executed automatically? Any information would be useful; thanks!

2

Hi Jason,

Thanks for getting in touch! We are currently in the process of creating the documentation for our new 2.6 features but let me see if I can explain this here.
Automatic Release Creation needs a single package defined to know when to create a release. We let you define which package in a project will be that defining package.
Many projects can have multiple packages, but you would not want the release creation to start for the wrong package if you have to upload 5.
So based on your own build configuration or process you should know (or define) which order the packages get uploaded, and which will hit the repository last.
Based on this you select that package as ‘the one’ that triggers the release creation knowing all previous step packages have already been uploaded.

So with that information in mind, and the way you have described your project, I can assume you only want to push the package for the environment you are ready to release to. So in that specific project this would not work. Could you explain more about the project and why each step is for a different environment, and how they are linked. It is not a scenario we have thought of, and this will help us have a discussion about it. Separating these steps into two projects would be the only solution at this time to use this feature.

Thanks!
Vanessa

3

Thanks Vanessa,

Let me attach some screenshots so that I can more easily explain what I am doing. It turns out that selecting that second step does actually cause both to be built; but this is not intuitive from the way the feature is shown on the screen. Even though my OP’s issue seems to be solved, here is what I am doing in case it is useful for your team in figuring out workflow, or for another user trying to set up the same scenario:

For technologies I am using TeamCity 8.x and Octopus 2.6. I have a solution with multiple projects, each of which needs to be packaged and deployed separately as both Debug and Release builds. For discussion let’s assume I have projects named A, B, and C that need to have both Debug and Release builds. My goal is to have Octopus auto-generate releases of these builds so that I can push Debug builds for any combination of { A,B,C } to a developer staging environment, and push Release builds for any combination of { A,B,C } to a QA staging environment.

Originally I had two Build Configurations in TeamCity. The first was a Continuous Integration build of the solution which used Octopack to generate nupkg artifacts (6 in this case – 3 projects, 2 builds each). A second build configuration was triggered by this being completed, which used the “Octopus Deploy: Create Release” build step from the Octopus/TeamCity plugin to generate releases in Octopus. This mostly worked, but I do not want two build configurations in TeamCity.

In order to fix this I reconfigured TeamCity to match what is seen in the “teamcity_build_steps” screenshot. Here there are five build steps in a single build configuration:

  1. Build unit tests (unimportant for this discussion)
  2. Execute unit tests (unimportant for this discussion)
  3. Build the debug configuration of my projects, run octopack, and store the nupkg files in a specific directory
  4. Do the same as step #3 but in Release mode instead of Debug
  5. Push nuget packages from both directories to the Octopus nuget server

For information on how steps #3 and #4 are configured can be seen in the “build_configuration_with_octopack” screenshot. Mildly frustrating was figuring out that I had to use the OctoPackAppendToPackageId parameter to add ‘Debug’ and ‘Release’ to the nupkg name before the version, since adding it after breaks SemVer and causes errors to occur. This is counter to advice from this discussion, which I could not get to work: http://help.octopusdeploy.com/discussions/questions/1786

This TeamCity build step order allowed me to avoid complex solutions to artifact-lifetime issues seen in threads such as: http://help.octopusdeploy.com/discussions/problems/556

Once the packages are pushed to Octopus, I want to create releases automatically. I upgraded to 2.6 because of the new automation feature. Each of my projects is configured as seen in the “octopus_project_steps” screenshot. Here, each project has two build steps, one of which deploys the Debug build to the DEV environment, and one of which deploys the Release build to the QA environment. Since they target separate environments, this can be safely run against either environment without extraneous actions being taken. Great.

However, as seen on the right, it is unclear that the “Automatic Release Configuration” should be set to the second of these packages based on the upload order of the NuGet packages from TeamCity. After I posted my OP, I ran some tests and found that selecting the second of my build steps (Release) works, because in TeamCity I push the Debug packages before the Release packages during step #5.

Additionally, I was previously confused due to an issue where no release would be generated for two of the three projects. It turns out that projects A, B and C all need to have their Settings -> Release Versioning option set to “Use the version number from an included NuGet package” or else no release would be generated. This may be due to my use of default/unconfigured nupkg values right now, but I’m not certain.

Hopefully this workflow is useful to someone, and is informative to your process. If there is anything that I am doing here that is “wrong” as far as how Octopus is intended to be used, please let me know so that we can discuss.

Thanks in advance!

teamcity_build_steps.png
teamcity_build_steps.png815×557 35.1 KB

octopus_project_steps.png
octopus_project_steps.png1670×507 45.2 KB

build_configuration_with_octopack.PNG
build_configuration_with_octopack.PNG892×392 31.5 KB

4

Hi Jason,

Thanks for the excellent explanation. Are you doing anything wrong? Nah you have a set process, and you used the tools available to get it working how you needed.
This is great though, it gives me an idea on areas we can make our documentation stronger. It’s a hard line though because everyone’s process is slightly different.
I will have a look at tweaking the text around auto release creations also.

Vanessa