I’m glad to see the rational start of this discussion.
Here is some of the rest of my thoughts.
I have exactly the same problems with development tasks and CI in the past. One of the reasons I have found 12factor reasonable.
About criticism. I think that phrase has been misunderstood a lot. While keeping in mind overall idea here is what I can say about it:
Env vars are granular controls, each fully orthogonal to other env vars in the codebase. The application itself does not do any assumptions about the environment it is launched in.
“You WILL have logical groupings of configuration”, absolutely! But this is not a responsibility of the application. It is the responsibility of an administrator to give all the required information to an application about an environment inside of which it is launched.
Environment variables is the uniform mechanism of exchanging environmental information. That’s why they’re called just that.
An application should just take the env. A developer should just fill the env with useful information. And a developer may use any possible tools to make this task easy.
I’m sure you know or heard about tools like chruby, rbenv, rvm… This is what I’m talking about. Environment management can be easy and flexible. If you can run “rvm 1.9 do gem update” to switch the entire interpreter, why wouldn’t you do something similar to switch “logical groupings of configuration”?
Did you know that you are able to do something like that: “rvm 1.9,2.3 do gem update”? Now imagine that you are able to do that: “env development,test do rake db:drop”. Oh my, this is so explicit and obvious that you can’t even make a mistake in what database you just actually wiped out!
About config/environments/*.rb. First of all, you can map all the values to ENV in config/application.rb so there are no “hard” problems.
But there is more to say. Let’s remember what values we actually talking about:
- Resource handles to the database, Memcached, and other backing services
- Credentials to external services such as Amazon S3 or Twitter
- Per-deploy values such as the canonical hostname for the deploy
As you see, just a fraction of config/environments are actual “environmental” configs. But what about the rest of configs? They’re outside of context of 12factor. They’re the part of some application logic. You really do not want to overwrite them often, unless some appreciable change to the application happens. I would say config/environments are rather “mods” than “environments”. Deterministic models of behaviour.
If you do not wish to suffer you follow this http://12factor.net/dev-prod-parity. Surely, there just have to be some variations between environments. But are they so significant and unpredictable? Think about a modern development cycle and try to figure out really different application states. I think, there are three of them:
- non-interactive automation,
Yes, they’re just familiar test, development and production from config/environments. If more of them exist, there would be more of them by default in a new rails app.
Does it any good to let those configs be in the codebase? It is. How many times have you seen flags (args) like “–debug” and “–no-interaction”? I would bet you rarely think about how many configs does a single flag change. There just exists a concrete purpose for each of these flags.
For any distinct purpose you create a flag, everything beneath are implementation details.
Actually, this part is already works wery well. As I mentioned at the beginning of the paragraph, environment-specific parameters can be set from ENV. And others are managed with RAILS_ENV clearly.
There are not so many problems so far.
Environments from config/database.yml are accessed by Rails explicitly. This makes the usage of gems like figaro and config almost pointless, because you either ruin your development process or just brings +1 config file into the codebase because are still required to have database.yml for things to work.
This problem is almost entirely related to developer’s rake tasks. Even a complete rethinking of env usage in rake tasks will not break any existing deployments.
Even a minor version can make a huge step forward.
вівторок, 12 січня 2016 р. 06:39:51 UTC+2 користувач Chad Woolley написав: