I’m looking at versioning our packages different so that it doesn’t have to deploy each package every time. But in order for this to work octopus would have to skip deployment steps if the package version deployed on the server is the same. Is this the way it works? Or will it redeploy no matter what?
Hi Nathan,
Deployment won’t be skipped - it will re-upload and re-deploy the existing package.
One of the tasks on the Octopus Trello (https://trello.com/board/octopus/4e907de70880ba000079b75c) is to disable individual steps. So your ‘release’ would contain the old package, but the specific deployment (e.g, to env A) could choose to skip the package.
Hope that helps,
Paul
Yeah, but that suggestion (submitted by me) covers a different scenario. I’d like these packages the automatically determine if they should run. Right now we have 7 different projects to deploy separate parts of it. The previously mentioned individual tasks ticket would help to deploy ad-hoc. But what I’d like to see is for us clicking deploy on one project and the deployment determine’s what it should do. Something else I’ve looked into is passing variables from one task to another (another suggestion I have in here.) Which would allow me to run a script, set a variable and then handling things in the deployment scripts manually.
Eventually I want all of this to be automated and triggered externally. Until we have some of these pieces figured out it’s out of reach (not to mention the fact that there isn’t a way to trigger a deployment externally.)
Hi Nathan,
Thanks for expanding. Thinking about this some more, I think the current behavior might be a surprise in the first place - if a package is installed already, most people would probably assume it would be skipped. The times where you want to force re-deployment is probably an edge case.
I’ve added another task to Trello (this on in the v1 backlog) called “Make re-installation of existing packages optional”. Let me know if that matches more closely to what you had in mind.
Paul
Yes. I think that would be very helpful. In that case I could version the database packages based on if there was a database change (revision history) as well as version the SiteOffline package to align with the database. The result should be that if the database is not updated I just get a site update. If the database is updated it will take the site offline, upgrade the database, upgrade the site and then bring it back online again.
I would feel that skipping deployment on packages that exist would be the default but allowing a re-deployment option if necessary to accommodate things like this.
http://help.octopusdeploy.com/discussions/questions/8-forcing-redeployment