For simple configuration options like API endpoints I generally use the same tactics I use for node and Angular projects – look for environment variables or a key in a
config.json or similar before possibly falling back to a default value.
The vastly harder problem is keeping consistent Julia package environments across deployments, which could potentially be solved by Pkg3 if/when it lands.
Right now my nightmare situation goes as follows: I find a bug in some product that I’ve released to production. I pull it up on my development machine, but it doesn’t run because I ran
Pkg.update() the previous week which introduced breaking changes in a few packages (or if it’s a module, I have conflicting version requirements between it and other modules). I then either need to temporarily check out old versions of the affected packages, or make a bunch of modifications just to get it running again (and then also update the packages in prod).
Pkg3 julep does a good job of explaining how we got here. It’s not that
Pkg2 screwed something up – it’s just optimized for a different situation where all julia code on a system uses the same version (and prevents us from hauling around a bunch of different copies of every module).