Dangers of inheriting config

I have just finished migrating a suite of Elixir projects from distillery to mix release. A key part of that change is that all environment variables need to be called from the runtime.exs rather than the various env.exs files.

This is part of a project to move to build once, deploy many times approach.

While working on this I found a few cases where the staging envitonment files inhereted from production. This is a big problem as you may turn things on in production later and not realise that the staging system (which can have a larger number of possible users) will also be using production.

I untangled the config into distinct files (keeping everything as it was) and only when it was reviewed it revealed certain production settings we don’t want in staging.

This relates to the talk Simple Made Easy.

Migrating from Distillery to mix release

Mix release became the offical way to release an Elixir project some years ago. Distillery had been the previous one.

Here are the steps needed to move across:

1. Move any config that uses environment variables into runtime exs.

2. Add a release section in your mix.exs

3. If you were using rel/config.exs to copy files into the release add this to a custom function in the mix.exs step

4. Remove distillery from your mix.exs and clean up the lock file.

5. Adjust your build process to call mix release instead of distillery.

This requires a lot of careful testing!

Learning New Languages

No matter how many ptogramming languages you know there is always another that you need.

Currently I am learning Elm with the next stop being Rust.

The Elm ecosystem is slightly broken on M1 Macs (including via Docker). My plan to reduce the pain is to use Storybook.