Hi
We have 3 build configurations per application
I cannot see how I can incorporate this into octopus as it only looks at one nuget package that comes from team city which will be either one of the 3 builds, is there a way to force staging to look at staging and live to look at live and dev to only look at a dev build?
Regards
Jeanre
Hi Jeanre,
Am I to understand that you have 3 different versions of the same package? For example, if the package is MyPackage.1.0.0.0.nupkg, you will have three slightly different copies of it with different content, but the same version number?
If so, Octopus won’t support this currently. Octopus is built on the idea of taking a single package and deploying it to each environment - it can’t deploy a different package to each environment.
Can you explain more about the differences between the Dev, Stage and Master packages? What kind of content differences exist in them?
Paul
We can do skype chat? As I am really interested in your project and would lIke to contribute.
Sent from my iPad
Sent from my iPad
Begin forwarded message:
From: Jeanre Swanepoel tender2+dfbfbd1aa0aed31bca59e265e8979cd9fe67e09e0@tenderapp.com
Date: 10 March 2012 9:00:34 PM SAST
To: jeanre@netaddict.co.za
Subject: Re: Multiple Build Configurations in Team City [Questions]
Has there been any updates to this request? I would need support to have different configurations for each environment for Octopus to work for me. Our application is comprised of 6 GAC assemblies, 3 web projects, 3 silverlight xaps, and several click-once deployed wpf apps, as well as background windows services.
Octopus seems to be able to handle everything nicely except for the xaps and click-once wpf apps. I have teamCity packaging source code for each of our 8 configurations so we currently have something like this:
I would like to have a nuget package for each configuration in the same version that I could specify with a version parameter in each environment. Are there any workarounds for setups like this? Great product by the way. I hope to be able to use it.
To chime in:
Our current development process is the AccuRev ‘stream model’, where we also have Dev, Qa, and production build outputs. We deploy the ‘dev’ build output to the dev environment, Qa output to Qa, etc…
I’m dealing with the same question now. My current thinking is have each Team City build configuration publish to a unique NuGet server for that stream, and then once I have the Octopus project configured how I want it, clone it out for the three environments and set the source NuGet servers to be different. I’m not so hot on this idea for a variety of reasons.
I ended up having each build configuration automatically create a release in Octopus using Octo.exe with the NuGet packages from that build, that way when you want to deploy your release you just log in and it’s a small matter of finding the build you want to deploy. We also append a string, e.g. “-alpha”, “-beta”, “-qa”, (nothing for release) per the Semantic Versioning, although this really is just to help us distinguish, as our build numbers are always unique.
I just found an answer that will work for me…using multiple configurations in one build process and then adding an environment name to the package id…in the end it looks like ‘mywebsite.dev.1.0.0.2’ and mywebsite.qa.1.0.0.2 etc…
/p:OctoPackAppendToPackageId=$(BuildConfiguration)
Jeff - I’ve replied to your question on this other thread with comments about this “package per environment” approach, which we usually recommend to avoid 
http://help.octopusdeploy.com/discussions/problems/45248-multiple-project-deploy#comment_39566107