We are using Octopus to deploy application in our server, but we have an issue and we want to ask for help.
The question is: Is that possible to deploy the part updates files to server?
We are using SVN + TeamCity + Octopus for the automatic deployment. Here is our steps.
1.Dev check in code to SVN such as he updates the demo.aspx files.
2.TeamCity receives the changes and build for a package.
3.Octopus receives the package from TeamCity and deploy to server.
4.We found that all the files will update to date in server, but actually we just want to update the demo.aspx files and files in \bin folder.
Is that possible to deploy the part updates files to server instead of update all the files in server?
It will be great if you could fix this issue for us ASAP.
Thanks for getting in touch! Sadly this can not be easily done through Octopus.
Octopus, which is based off continuous deployment best practices, believes each package should be complete. This assures that when a deployment happens to a new machine it does not need to rely on previous releases.
We do try to combat having to deploy full packages with our delta compression which will only transfer the difference between the packages.
If you do want to have packages with only changed files you can do this, it will just mean much more work and release dependencies which leads to errors.
On a side note, when submitting a ticket, please only submit it once, we check all our support fronts on a daily basis and having to action the same ticket in several instances slows things down a bit and will end up increasing the time it takes to get a good answer out to our customers.
You said “If you do want to have packages with only changed files you can do this?” Is there any tutorial or example for doing this? Because we think we may need the delta compression instead of full packages.
Absolutely, we have a great documentation page on how delta compression works in Octopus, you can see it here: http://docs.octopus.com/display/OD/Delta+compression+for+package+transfers
When we use delta compression only the difference in the package between versions gets transferred (Assuming the changes are less than 80% of the package). The package however still unpacks the whole solution after transferring the difference. If you want to only package it partially, that would have to be scripted on build and have a comparison, but packaging happens before it gets to Octopus.
I have read the article for “Delta compression for package transfers” which you provided. But it seems that only provide us some concepts instead of some steps for what we do for octopus.
Could you tell me about what is the step for “Delta compression”. I notice that we should use the octodiff tools but I don’t know how to use.
I used 3.3.8 version for both Octopus Server and Tentacle.
When we deploy the packages form TeamCity which we check-in, such as just update web.config, it seems that it will deploy/update all the files in Tentacle.
Actually we just want to deploy or update web.config. Maybe the Delta compression is not we except?
I believe I have done a bad job at explaining how the Delta compression works so let me have another attempt.
Delta compression is responsible for compressing files before they are transferred from one server to another (only applies to NuGet packages).
It also serves to selectively upload only the files that have been modified (so long as less then 80% of the package has been modified)
Octopus believes that previous versions should always be available for use, which is why we follow the versioning strategy that we do.
Because of this, partial files and uploads don’t fall within out best practices and is not something we enable people to do by default.
Delta compression stops uploading the full file again when we are able to rebuild from the difference.
As an example:
If I was to change a web.config file in one of my packages. then create a new release and deploy the package, it would not transfer the entire package from the Octopus server to the Tentacle server, it would only transfer the web.config. However, once the file reaches the Tentacles it will look for an existing package with the same PackageId, Version and file hash. If it finds that it will take steps outlined in the documentation to “inject” the web.config before redeploying the package.
This lets you make little adjustments to your packages without having to worry about uploading the package every time and potentially causing large network usage.
However once the file has been compressed -> transferred -> rebuilt into a new package on the Tentacle server, the package is then run just as it would be in a normal deployment.
Please let me know if this helps you understand the process of using Delta compression a little better
