Thanks for getting in touch! While Octopus can not exactly only update a several .dll's in your deployment, it does take advantage of delta compression during the transfer. The following documentation page outlines how we handle this. So technically if the new package has <80% difference, only those changes will be pushed to the Tentacle to be deployed. However, the entire package will still be deployed once the file differences are transferred to the Tentacle.
Let me know if the above helps or if you have any further questions.
So, let me try to assess how a pipeline for that would work. Please correct me if any of my assumptions are wrong, or if there is an easier way to do things.
In essence, that would mean we'd install the software on our client's servers and manually configure the environments for those servers. Simultaneously, we'd have TeamCity create a "mirror" installation on our build server which looks just like a full installation, having all the files in the same places. Then, we'd add the mirror installation folder into a package (Is that even possible? And if so, what package type would be suitable for this?), and push it to Octopus. Octopus would finally deploy the package to the configured environments and overwrite the files in the installation folders with the newer versions.
Is that something that would work? Or am I getting the wrong idea here?
On a related topic, assuming we were to install our software on different drives on different servers that are part of the same environment (so the installation path is different), how would we best handle the deployment process? The installation path of our product is registered in the registry on installation. Is that something we can use when deploying packages with Octopus?
Thanks for the information! I believe Octopus can help you out a lot with automating this process. First thing to note is that Octopus excels at automating the configuration of your deployments, once you have configured your projects, variables, environments, targets and Lifecycles.
You can configure pretty much every aspect of your deployment through various steps available in Octopus, if we do not have a step for it then you can use a Custom Script.
Generally you would have a single application per a package, build your build with any dependent files it need including any configuration files or custom scripts(this can also be handles by Octopus as per above documentation). In order to separate your deployments between certain machines in the same environment you can use the target roles feature. These act as logic separators in Octopus, letting you scope different variables in your deployment to different machines, or multiple.
An example would be your final question about installing Octopus to different drives. This can be achieved with a combination of our custom installation directory feature and target roles.
Your project could have some variables like the following: Name | Value | Scope