Application deployment: multi nuget based vs custom deployment package

Posted on June 30, 2014 · 2 mins read · tagged with: #deployment #NuGet #Octopus Deploy

So far I encountered a few patterns for deploying application. Speaking of those based on nuget packages, I can easily distinguish two of them.

Package with references

that’s the first one. Frequently it’s not a custom package. It’s based on the main solution project (the application part) and is pushed to a feed with packages based on other solution projects. This leads towards design where packages are:

  1. small
  2. meant to be cross-app reusable
  3. mirrors the solution and project dependencies
  4. has references to other packages
  5. needs a nuget feed to resolve other dependencies during the deploytment time

Unfortunately, packages of this kind are not stable build artifacts. One can easily change multiple apps by pushing to the NuGet feed libraries used by installed projects. Packages once build and deployed may be changed between publications on environments which greatly diminishes the meaning of deployment package. Iff one totally controls pushing to the feeds and provides staging for feeds, this may work, otherwise - can be considered error pr one (one cannot tell if the package published once, can be republished in the higher environment).

Self-sufficient package

which is the second one. This kind of package, prepared specially for deployment, consists of all items required by the given deployment, which provides packages that are:

  1. bigger
  2. targeted towards deployment
  3. orthogonal to a solution organization
  4. has no references to other packages
  5. needs no nuget feed to resolve other dependencies during the deploytment time

This kind of artifacts, used by Octopus deploy consists of snapshots of all dependencies in the given moment of build. Snapshots, by default immutable and stable, brings a self-sufficient packages, which can be simply extracted in a given environment. This for the price of declaring a custom nuspec, brings the repeatable deployment on all the environments and is a preferable way of doing deployments of mine. Even if you don’t want to use Octopus Deploy for some reasons.

Comments

Funny, but all those different kid of aproach has been already dealt with. Where? On Linux. Seriously, package managing and building is the core functionality of free software. Nugent and onothers are trying to keep up here ;-)

by chengin at 2014-06-30 18:39:28 +0000

Not saying that's an invention:) Just discussing different strategies.

by scooletz at 2014-06-30 22:13:14 +0000
← Previous Post Next Post →