They're moving config from each individual umbrella application to the root of the umbrella. Gotta love how the team keeps things simple and opinionated. These little choices add up to quite the developer experience.
Elixir 1.9
11–20 of 174 posts
Re: Elixir 1.9
#12Sorry if this is a dumb question, but how do releases fit into the deployment story with containers so prevalent these days? (As in why is this a benefit when you can just package code into a single container to ship it?) Is it that it works with hot code updates? Or it’s a more Erlang-sanctioned way of deploying code?
There's a good 'why releases' section of the article.
Even without the compilation and configuration stuff, it's easier to put the release bundle in something basic like an alpine image, rather than keep docker image versions and app in sync.
Re: Elixir 1.9
#13Sorry if this is a dumb question, but how do releases fit into the deployment story with containers so prevalent these days? (As in why is this a benefit when you can just package code into a single container to ship it?) Is it that it works with hot code updates? Or it’s a more Erlang-sanctioned way of deploying code?
There's a good 'why releases' section of the article. Even without the compilation and configuration stuff, it's easier to put the release bundle in something basic like an alpine image, rather than keep docker image versions and app in sync.
But the article says you have to run the release on the same OS/version that you built it on. So if you're running it on alpine, won't you need to build it on alpine, which suggests you'll need to configure your Dockerfile to compile it anyway?
Re: Elixir 1.9
#14This is great news! The deployment story has progressively improved since I started using Elixir in 2016, but the best way is to just have _one_ community blessed system. Distillery has helped a lot for sure, so it's nice that it's basically been rolled into the base elixir distro.
Based on what I've learned from the Elixir forum, these new releases have "no support for hot code updates / appups / relups". This means that Distillery will remain the best choice for many of us, including myself. I have a very simple deploy process with Edeliver and Gitlab CI/CD that basically just consists of pushing or merging a commit to master that passes the tests. There's zero down-time and it doesn't requir…
Wait, what? I wrote an Elixir/Phoenix webapp around 2015 and one of the major selling points was the ability to hot-upgrade code that was inherited from Erlang. What changed?
Re: Elixir 1.9
#15Congratulations! Notably, they mention switch to Cirrus CI, because it supports FreeBSD also. I wish Travis[1], Appveyor[2], and Azure Pipelines supported it too.
Re: Elixir 1.9
#16Earlier quoted context omitted.
Based on what I've learned from the Elixir forum, these new releases have "no support for hot code updates / appups / relups". This means that Distillery will remain the best choice for many of us, including myself. I have a very simple deploy process with Edeliver and Gitlab CI/CD that basically just consists of pushing or merging a commit to master that passes the tests. There's zero down-time and it doesn't requir…
Wait, what? I wrote an Elixir/Phoenix webapp around 2015 and one of the major selling points was the ability to hot-upgrade code that was inherited from Erlang. What changed?
OP mentions it's still entirely possible with other deployment libraries (Distillery).
Just the one being newly packaged into Elixir 1.9+ by default does not yet support hot-loading...
Re: Elixir 1.9
#17Earlier quoted context omitted.
Based on what I've learned from the Elixir forum, these new releases have "no support for hot code updates / appups / relups". This means that Distillery will remain the best choice for many of us, including myself. I have a very simple deploy process with Edeliver and Gitlab CI/CD that basically just consists of pushing or merging a commit to master that passes the tests. There's zero down-time and it doesn't requir…
Wait, what? I wrote an Elixir/Phoenix webapp around 2015 and one of the major selling points was the ability to hot-upgrade code that was inherited from Erlang. What changed?
The problem with hot code updates is they can break your app if your structs change shape and are extremely hard to get right over a period of time. Best to do rolling deployments with Kubenetes or something...
Re: Elixir 1.9
#18Fantastic. Congratulations to the Elixir team! Something striking from the release announcement: > As mentioned earlier, releases was the last planned feature for Elixir. We don’t have any major user-facing feature in the works nor planned. Part of me is a little alarmed—no one wants a language to stagnate. José makes it clear that this doesn't mean it's the last version: > Of course, it does not mean that v1.9 is th…
I guess Elixir is "done" then? What could be the downsides to this?
Re: Elixir 1.9
#19Earlier quoted context omitted.
Based on what I've learned from the Elixir forum, these new releases have "no support for hot code updates / appups / relups". This means that Distillery will remain the best choice for many of us, including myself. I have a very simple deploy process with Edeliver and Gitlab CI/CD that basically just consists of pushing or merging a commit to master that passes the tests. There's zero down-time and it doesn't requir…
Wait, what? I wrote an Elixir/Phoenix webapp around 2015 and one of the major selling points was the ability to hot-upgrade code that was inherited from Erlang. What changed?
I would be curious to know what makes this feature a major selling point. Aren't rolling deploys easier to handle? I'm not saying it's not a great feature, but honestly, it probably stopped being useful since Erlang/OTP was originally designed.
Re: Elixir 1.9
#20Are releases supposed to replace Distillery? If so, are there any particular reasons to switch?
Elixir's `mix release` is intended to replace (or remove the need for) third-party packages like Distillery. However, it's not there yet, and Distillery is strictly more powerful at the moment.
Notably, Elixir's release implementation does not support hot code upgrades. I use upgrades all the time, and won't be trying out Elixir's releases until this shortcoming is addressed.