How to synchronize matching (NuGet?) packages

Our application has many parts in it - web app, windows services, DB scripts, etc. Each component is built into its own package. For instance, DB is rarely changed, so DB packages mostly stay at the same version for a long time. Web App tend to change very often and produces several packages per day.

How shall I make Octopus understand packages matching rules? We cannot just say - get the same versions of each package, because for instance DB package is on lower version, simply because newer version was never produced and the old one is the latest.

I understand that my question is rather vague and hope you can steer me to the right direction.

General Octopus guidance implies there is one package for everything for consistency and integrity, but it seems to be a huge waste as we would have to deliver it to all machines! Web part of the package is complete waste on the SQL Server, etc. We would rather only deliver relevant components to machines in particular roles and that implies releases consisting of components packaged individually. That’s where package synchronization question comes from.

I hope you understand what I’m trying to solve.


Hi Konstantine,

Thanks for getting in touch! I have seen a few tickets you have created, and see that you are really getting into your Octopus setup and evaluation well which is great.

I think that part of your questions below show a little bit of confusion about what Octopus does. So I am going to explain a little bit of a scenario and how package deployments work that I hope will answer your questions.

Octopus can both work with out of sync package versions and multiple modules in a single project. This includes packages that you only want deployed to a database server and packages that belong only on a webserver. With roles you can define the roles of a machine to determine which steps and packages are deployed to them. Octopus will also always select the latest of a package by default, but that doesn’t mean that all packages need to have the same version number to work. It will select the latest of your database package while selecting the latest of your windows services package but they do not have to even be close to version each package will be determined individually for its own latest version regardless of when it was processed.

We also cache packages on the local Tentacle specifically for the last version installed (even with retention policies) so if you release a new version of the web services but the database hasn’t changed, we will not re-upload the package again. You can even set it to not redeploy the package if it is not required.

From what I am reading and interpreting from your questions, I believe that Octopus naturally deals with this well and you should find it works as you would hopefully expect it to.

Please let me know if this leads to any further questions or if I can point you at specific documentation or videos about these subjects.

Vanessa, thank you for your answer!

I understand that for each role the latest version of the package for that role is selected and deployed if it has changed since the last deployment. This is how I expect it to work 95% of the time. But what if we find about the flaw in the latest version and need to rollback, say web service, to previous version. What Octopus is going to do to machines in other roles? Is there a way to define behavior for that case? What it does by default?

BTW I’m going to get “quiet” for some time while I work on the new environment we need to deploy to, but after that I will come back and try to make Octopus our central deployment hub for all environments and all purposes.

Hi Konstantine,

If you have a situation where like in your example the web service is flawed and you need to roll back, if you have a previous version where you know it wasn’t flawed you can re-run the previous successful deployment and either re-release the entire deployment or pick steps that are relevant like the web service. If you are using our methods and have your files in versioned directories and packages cached this should be a very quick process.

I hope your setup is going well.