How do you choose your mix environment for your QA/staging deployments?

[unaware8150]

Good day, folks!

I’m a long time lurker of the forum, but I decided to jump in into the community to ask a question that it seems obvious, but I find difficult to answer: Which mix environment do you use when you have QA/staging environments for your elixir application? how do you choose which mix environment to use?

In Ruby/Ruby on Rails deployments, it’s common to create a new environment configuration with the same name you want for each type of deploy: development, qa, staging, test, production and I’ve seen this pattern also in certain phoenix codebases, but it feels a bit forced for me when working with elixir, IMHO.

What I usually do is that I choose dev.exs for development deployments, test.exs to configure and run the test suite and prod.exs for QA/Staging/Production environments and then I tweak certain configs (like secrets or log levels) at the config/runtime.exs level.

What’s your approach?

Thank you all for your replies!

---

_{Please note the aim of threads like this is for you to explain things in your own words. Please see this thread for details (videos/links to further reading are also welcome though!)}

[benwilson512]

Hey @unaware8150

@unaware8150

What I usually do is that I choose dev.exs for development deployments, test.exs to configure and run the test suite and prod.exs for QA/Staging/Production environments and then I tweak certain configs (like secrets or log levels) at the config/runtime.exs level.

This is the way (mostly, just tack on releases). The thing to distinguish is between “build environments” and “deployment environments”. As you say for development and testing, these are done often on people’s computers and have dedicated build environments to handle the different dependencies and tasks necessary for testing and dev.

For all deployments though, we always use prod.exs. More specifically, we have a build pipeline which builds a release artifact (this could be a simple release .tar file or a full docker image) and then we deploy that artifact in whatever deployment environments we need / want to. This means that we have identical byte for byte artifacts going into each of those environments, increasing our confidence that if the release behaves a certain way in QA / Staging, then it should do so in prod.

[christhekeele]

@benwilson512

The thing to distinguish is between “build environments” and “deployment environments”. As you say for development and testing, these are done often on people’s computers and have dedicated build environments to handle the different dependencies and tasks necessary for testing and dev.

I like to use MIX_ENV for build concerns (debug logs in dev, mocks in test, optimizations in prod) and MIX_TARGET for deployment concerns, to differentiate between things like demo, QA, staging, prod, etc. Those normally get deployed as prod builds, but can be deployed as dev builds if extra visibility is needed.

[linusdm]

Welcome @unaware8150 and great first question!