Development, staging, production, and beyond
Environments, sub-environments, and configuration simplicity with EnvKey 1.1
This is EnvKey’s first major feature announcement after launch, and it’s going to be a bit strange, because after introducing the feature I’m going to explain why it might be better not to use it.
First, just a bit of background.
Three Environments
As a configuration tool, EnvKey is fundamentally based on a three environment split: development, staging, and production.
Why? Because any program running on any computer in the world belongs to one of these categories, and every app in the wild needs all three of them.
We need development environments when we’re building and testing our apps. We need production environments to serve end users. And we need staging environments to bridge the gap so we can try stuff out in a production-like (but not really production) setting.
But what if you need to go beyond this holy trinity? What about CI servers and background workers and feature branch servers and who knows what else? You need additional environments, right?
Sub-environments
In fact, the ability to create additional arbitrary environments has been the most requested feature since EnvKey’s launch, and now with the introduction of sub-environments in EnvKey 1.1, you can create as many as you want.
Here’s how it works: you add a sub-environment as a descendant of development, staging, or production.
Then you can add variables or overwrite existing ones.
Once you’ve created and configured the sub-environment, you can generate ENVKEY(s) for it to give server(s) secure access.
Ok, now that I’ve shown off the shiny new feature, here’s the argument for using it sparingly.
Pitfalls
There’s a trap lurking here.
Every full fledged app needs development, staging, and production environments, and, of course, needs them to each be configured somewhat differently from each other. But every one of those differences in configuration is also the source of a potential bug.
Say you’re using Stripe for payments. You set a STRIPE_SECRET_KEY in your development and staging config, but you forget to add it to production. Now all of your tests and and qa will proceed without a hitch, but when a potential customer tries to pay you in production, it ain’t gonna work.
You might see where this is headed: as the number of environments with distinct configurations increases, the potential for config-related bugs increases as well. It gets harder and harder to keep track of the state of everything. And the worst part is that these types of bugs often elude tests, so they are among the most likely ones to find their way into production.
You gotta do what you gotta do
Sometimes, there’s no way around it. Perhaps you’re building some sort of demo that needs to use production API keys but connect to a different database. Or you have a CI setup that runs your app on several devices and needs to behave a bit differently on each one. In situations like these, additional environments are necessary, which is why this feature was added to EnvKey.
But do you really gotta do it?
But if you can avoid the fragmentation, you should. Say you have a background worker that has some config associated with it — stuff like REQUEST_DELAY=1000 and REQUEST_RETRIES=5. Since your app’s main web server process doesn’t use these values and your worker does, you may be tempted to create sub-environments — one each for the development, staging, and production versions of your worker config. I think this is a mistake. It’s much better to just add the config at the top level just like the rest of your variables.
Sure, the web server process will have some superfluous config that it doesn’t use, but it won’t do any harm, and more importantly, you won’t double the number of distinct configurations you have to keep track of.
The same applies when you have a test server that has some test-specific config that you don’t need in development. That’s fine — just add the config under the development environment directly. It’s far more important to maintain simplicity and have confidence that your development environment and your test server environment mirror each other exactly than to save a few meaningless bytes.
To each according to their needs
If you do have a need for sub-environments, this feature will help you keep them de-duplicated, organized, in sync, and secure.
If you don’t, all the better. I’d suggest keeping things as simple as you can for as long as you can.
If your team shares API keys and other secrets over email, Slack, or Google Docs, EnvKey can help. You’ll improve security, speed up development, prevent bugs, and simplify ops with a ~15 minute time investment by keeping configuration securely in sync for developers and servers.
Go here to learn more and download the latest version of EnvKey.
