search

bitwalker / distillery

Simplify deployments in Elixir with OTP releases!
MIT License
2.96k stars 398 forks source link

Ask confirmation if attempting to build release --upgrade without changed mix version #558

Open Qqwy opened 5 years ago

Qqwy commented 5 years ago

Description of issue

Whenever you've created a release, and are building a new one that you want to use for a hot-upgrade, if you build this one without changing your mix version, then stuff goes wrong once you attempt to upgrade. To complicate things further, one you've encountered this, bumping the mix version afterwards and building a new release will create an .appup that is worthless.

The only 'simple' way to fix this problem is to perform a hard (non-hot) upgrade.

Proposed fix

If, when the user would attempt to execute this, and Distillery realizes that there already is a release for this app version, it would ask for a confirmation, then this gives us an explicit way to solve the issue before it becomes a problem.

OvermindDL1 commented 5 years ago

I would definitely like this as well, a few times I've released the same version... >.>

bitwalker commented 5 years ago

Well the simple way to fix it is to just checkout the code of the last deployed version, rebuild the release, then checkout the "new" code, bump the version and then build the upgrade - but that's not really the issue.

It should be possible to warn and/or ask for confirmation before building a release for a version which is already built, so 👍 from me.

bencates commented 5 years ago

Adding to this, things go wrong if the application version hasn't been bumped even if the release version has.

I'm attempting to set up automatic versioning of our releases, which I initially did by setting the version in rel/config.exs to a string of the form "#{mix_version}-rev.#{number_of_git_commits}". This produces a fresh release version for every deploy, assuming at least one commit has occurred.

This appears, at first glance, to work. A newly versioned tarball is created, bin/myapp upgrade $NEW_VERSION unpacks the new build, bin/myapp describe reports the new version number. Except the application isn't actually upgraded. The old version continues to be used, even after a full application restart.

I think, after finally understanding what's going on, that this is probably correct behavior (none of the applications in the release have changed, so the hot upgrade is a no-op). But it's very unintuitive and the official documentation isn't much help.

A confirmation dialog would go a long way toward helping onboard new applications, as would some guidance and/or support for ways to set up a continuous deployment workflow without requiring the developers to manually increment the application version in the mixfile every time they want to deploy.