Separate OctoPack from MSBuild to enhance Continuous Integration

Is there are way to separate OctoPack from the main MSBuild build process? I understand that OctoPack essentially combines the NuGet pack command with extra logic to know what to include for a release - presumably not only build output, but content files, etc…

I want to break up my monolithic build configurations in TeamCity and move the octo-packing to a separate build configuration in its own step, then followed by the standard create-release and so on…

There are 2 strong and good reasons for that:

#1. All the projects that need to be octo-packed for deployment belong to a single solution with a strongly coupled set of business logic libraries and intertwined dependencies. Separating each one of these projects is not a trivial feat. The entire solution source is contained in a single repository and my MSBuild acts upon the solution file.

The build alone is actually fairly fast, barely a few seconds per project (most of the sources are content files,) but with the OctoPack target enabled in MSBuild takes much-much longer. Because of this I have to wait several minutes just to hit the next create-release build step, which then creates releases for each NuGet package that is published to the internal NuGet feed.

#2. Unit tests should be ran before any packing is done: There is no point in wasting all the time creating packages and using up space in the artifact repository for builds with failed unit tests.

I have been successful in the following proof of concept: let the regular build complete (fast) in its own build configuration and then simultaneously trigger packing configurations (based on the NuGet pack step) with artifact+snapshot dependency on the build configuration (build output is published as artifact). This way I can progressively start creating releases and trigger automatic deployments in Octopus without having to wait for the other packing configurations to finish.

Furthermore, this can easily be extended to incorporate intermediary unit-test configurations, thus handling case #2.

This way I maximize the amount of time either my TeamCity build agents and Octopus are doing actual work. It cuts time down the entire process significantly.

But this is not a complete solution, as the NuGet pack step DOES NOT DO the exact thing OctoPack does, in particular with content files. Plus, I’d rather stay closely integrated with the Octopus Tools.

Hi Fernando,

Thanks for getting in touch. I’m a little confused at what you want to do though.
Currently in TeamCity you have to elect (via the checkbox) to run OctoPack. Could you run a fast build configuration, run the tests etc then have another build step that does call OctoPack ?



Hey Fernando,

We ended up moving to nuspec to solve a similar issues in #1. At first it seemed like it was going to be a hassle to constantly be defining nuspecs, but we ended up with a few templates that get reused (e.g. one for web api, one for mvc, one for libraries).

We also moved away from using the packaged tooling in the CI environments (we are using Jenkins right now, but I remember team city) in favor of a DSL (i.e. psake). So packing and testing is straight forward after the initial setup of the scripts, and highly customizable. Not to mention, your build process is not coupled to the UI of the CI environment. so if you ever decide to ditch Teamcity (or in my case Jenkins), your not stuck migrate configuration out of an UI.