Overtaking releases - deploying "out-of-order"


I’m looking into your great product and I really like the freedom - no force-feeding of your way to do it…!

Today we have a very simple setup of

  • TEST site
  • PROD site

When a developer has something ready for testing ( feature or hotfix ) he creates a delta-package and deploys this via a powershell script. We can have any number of features / hotfixes on test at anytime - and they can be promoted to production in any order. It of course gets a little tricky if a feature and e.g. a hotfix has a file-collision, but we handle that manually today.

It works but we would like to move into something a bit more structured.

I need to keep a setup where a developer can develop, package, release and deploy a feature/hotfix by them selves - out-of-order all the way from test to production.

I’ve been testing Octopus and would like you to maybe point me to more information or possibly verify my idea. I just watched the “channels walk-through” but that differs from my env. with dev and test being provisioned environments for each - where my test codebase is “one-for-all”

The guideline is to package the entire file set for deployment and then let the built-in delta feature push the changes. This would not really work in out-of-order - since 1.0.2 would maybe overwrite 1.0.1 changes or even bring untested 1.0.1 to production along with 1.0.2.

My idea is to create the delta package our-self and push this to Octopus and from there on use all the awesome features to deploy to our environments.

So i would do something like:

  • Turn of detla via Octopus.Acquire.DeltaCompressionEnabled = false
  • Package the delta set our self for deployment ( like we do today )
  • Include a file with a list of files to delete ( if any ) and add a step to do this in the process

I’m aware that this does not solve the potential file-collision between different features/hotfixes - but I can’t see any other way of achieving the flow I need to make sure that changes are pushed through our system as fast as possible with as little required interaction between devs/teams.

I hope it all makes sence :slight_smile:


Hi Kresten,

Thanks for getting in touch! You were on the correct track when you were looking into Channels and I believe they are the answer to your issue. While our exact examples may not match, each channel can have its own Lifecycle which means you can have a single phase that will allow deployments to any environments. I cannot say we would recommend using your own delta packages nor manually fixing file collisions.

All packages should contain the entire website or application, and be deployable to a new environment without needing previous releases to also be deployed. What I would recommend is you have say a development channel, and a master/live channel. The development channel can have paths defined to make sure it will only deploy over the top of itself, where the master/live channel would have its own variables that means it can be deployed on the same environment as the development channel without overwriting any files or paths. It will give you the freedom to automate without having to do anything manually, and have two sites live in all of your lower environments. It would give you the least amount of interaction between the teams if you can make it all automated. With this method there would be no reason that untested changes would make it to production, as we are working with full artifacts and not packages built from an existing environment.

Please let me know if this sounds like a viable solution and I can help guide you to setting it up or giving ideas about how it all works.
Let me know if you have any questions also.


Hi Vanessa,

Thanks for getting back - i have some additional questions.

The reason for my initial question is related to us not currently using GIT - and this setup requires very effective branching to work as you suggest. Something SVN lacks…

  • Whats the strategy for removing files during a deployment using delta-deploy? My tests shows that the delta deploy does not remove files from the target. I would prefer not to use the purge option.
  • Whats the best way to re-deploy a bugfix in a feature currently in test? Is that to allow overwriting the package and then just deploy it to test again?
  • I’ve seen this in the “Task log”:
Upload package {app} version 1.0.22
Found matching version 1.0.9: {path}
Package {app} version 1.0.22 successfully uploaded to this server
Using package {path} with hash 451dc1a458b9643329fd85c99a9a5bdacccd4835 for creating delta
Original package was 942 KB, delta file is 44 KB
Applying delta to {path} with hash 451dc1a458b9643329fd85c99a9a5bdacccd4835 and storing as {path}
Applying delta: 0%
Applying delta: 50%

Why does it compare to version 1.0.9 instead of the available version 1.0.21 ??


Hi Kresten,

Sorry for the delay in getting back to you.

Our delta deploy feature simply matches the difference in packages to minimise the required upload needed. But the entire package is restored, unpacked and all step functions are completed on that package (transforms, substitutions and IIS features).
We do not support partial deployments of single files. And while we do support installing to a custom directory, the purge option is the only option to clean that directory.

The best method for deploying a hotfix is to create a new release with a new version and deploy that package. The main principle of continuous deployment being single artifacts that are versioned. If you were to reuse a package and a version you do not know really what you are deploying compared to previously. But you also might have issues with variables not being available in that release, same as the process and step snapshots. It is the best policy to have a new package with the hotfix and all of the files, with a new release number. You can create a unique hotfix channel and lifecycle to skip environments that are not required for a hotfix deployment, but again we recommend going through the entire pipeline as you can then have confidence in the package itself and its deployment.

Our delta match will find the last 5 files and match one that is closest to the current version for sending the difference. Sometimes this can be a slightly older version. It compares the package as a whole.

Hopefully this has answered your questions. Please let me know if I can expand on any of my answers.