unaware8150
How do you choose your mix environment for your QA/staging deployments?
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!)
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
We build reliable cloud platforms for business-critical systems.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First 3 of 3 Posts
benwilson512
Hey @unaware8150
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
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!