Is it possible from the Create Release button on the Octopus Deploy manager website to trigger a build in TeamCity.
Our workflow is we have CI builds in TeamCity using debug configuration that will automatically trigger Octopus Deploy’s to our dev server, this would be one project.
We would set up a 2nd project in Octopus Deploy for our QA/Production work flow were we would like our product managers to go into Octopus Deploy and use the Create Release and be prompted for a few variables a specific changeset, a release date etc and use that to trigger a build in TeamCity which will than be deployed to our QA server. After testing the PM’s would go back into Octopus and promote the release to Production. We want to automate it as much as possible so we don’t want the 2 steps of having to create the build in TeamCity then selecting it in Octopus Deploy, the developers would most likely have to go into TeamCity to trigger the build.
We would like to have the PM’s run everything from the Octopus Deploy Dashboard.
Is this possible?
Thanks in advance,
-Jay
Hi Jay,
Thanks for getting in touch, unfortunately this isn’t possible.
The way we would approach this, is after doing your debug build in TeamCity, you could also do a release build, and push the packages to the Octopus server. Then the packages would be there in time for the manager to create the release.
Hope that helps,
Paul
Paul,
We have a moderate sized dev team and have a fairly large amount of CI builds per Sprint cycle. Our cycle lasts 3 weeks so I wouldn’t want to have that many release versions built along with every dev build. The ratio of dev to release builds could easily be 20:1.
So in a worst case scenario we would just have a dev run a release build in TeamCity when the Sprint cycle is over and then start the QA/Prod release cycle from Octopus or have that build trigger the QA deploy.
I wouldn’t be opposed to going the route you suggested CI doing both dev and release and then we can just promote the release build we want, but first we would have to overcome our package size concerns. Our primary deployment is a web application and we use package restore within VS, our nutrans file is used by TeamCity to generate a nuspec file and the NuGet package is created with all the dependencies included. Our package size is about 55MB, 50MB of that 3rd party packages from NuGet (an internal mirror of NuGet.org), 3MB is libraries from our internal NuGet repo and 2MB is the actual application.
I am not sure that is the best practice and would be open to other suggestions on how to package the web app in a NuGet package, if there was a way to exclude the 50MB of 3rd party dependencies and have Octopus Deploy get those from NuGet on deploy that would be ideal, even our internal dependencies possibly. I also know people have moved away from using package restore in VS and I am not opposed to that either, if it would make a difference.
Lastly we use the NuGet Pack runner in TeamCity to create our packages, we are running TeamCity enterprise 8.14 currently. If using OctoPack would allow us to do things differently using that instead is not a problem, we have just always been using this runner before we started looking at Octopus.
If you have a better approach to dealing with the packaging (I’m sure you have come across this type of situation), we would be interested in hearing your suggestions.
Thanks,
-Jay
Hi Jay,
There’s not much that can be done about the package sizes (there’s no way to use NuGet dependencies in Octopus, for reasons that are long and complicated, but perhaps we’ll be able to for ASP.NET vNext). However, you can use retention policies in Octopus to automatically clean up these packages to prevent too many of them building up.
On the whole, Octopus is a convention-based, opinionated tool, which is what keeps it so simple. The kind of workflow you’re describing goes against what the tool is designed to do. Hopefully the workflow I’ve described above will be a possibility for you.
Hope this helps!
Paul