Move deployment support to separate gem #95

Merged
merged 5 commits into from Apr 22, 2014

6 participants

@bkeepers
Owner

Most pull requests to dotenv are to support different deployment scenarios. As I explained in #71, I'm not convinced that dotenv should even be used in production. But I also live in a fantasy land where I don't have to manage production environments. Either way, I'm not the right person to be maintaining features that I don't need or use.

So here's my proposal: move all deployment related stuff to dotenv-deployment. dotenv will remain a very small shim intended for development. Someone else can manage dotenv-deployment and let it evolve into whatever people need for managing production configuration.

I would love thoughts from people that don't live in my fantasy land. /cc @wfarr @jnewland @asenchi @garno @elskwid @markrebec @linyows

If this sounds like a good idea, then I would love help testing these changes.

gem 'dotenv', :groups => [:development, :test], :github => 'bkeepers/dotenv', :branch => 'deployment'
gem 'dotenv-deployment', :github => 'bkeepers/dotenv-deployment'

Once everything appears to be working, then I will:

  • Release 0.11.0 with a dependency on dotenv-deployment and deprecation warnings for moved features
  • Remove deprecation warnings and dependency and release 1.0

Closes #71

@elskwid

@bkeepers: Nice work! The separation of the env manipulation from the deployment concern is great to see. Heck, the more focused README alone is worth the effort. (Full disclosure: I've stated before that I think this is a good idea. AND IT IS!)

The release plan with warnings of deprecations makes a lot of sense.

Good to see this happening.

@elskwid elskwid commented on the diff Feb 23, 2014
README.md
Storing [configuration in the environment](http://www.12factor.net/config) is one of the tenets of a [twelve-factor app](http://www.12factor.net/). Anything that is likely to change between deployment environments–such as resource handles for databases or credentials for external services–should be extracted from the code into environment variables.
-But it is not always practical to set environment variables on development machines or continuous integration servers where multiple projects are run. Dotenv load variables from a `.env` file into `ENV` when the environment is bootstrapped.
+But it is not always practical to set environment variables on development machines or continuous integration servers where multiple projects are run. dotenv loads variables from a `.env` file into `ENV` when the environment is bootstrapped.
+
+dotenv is intended to be used in development. If you would like to use it in production or other environments, see [dotenv-deployment](https://github.com/bkeepers/dotenv-deployment)
@elskwid
elskwid added a note Feb 23, 2014

A good signal that the line between the gems is in the right place. "You're here to load stuff into ENV but if you want to do something else go over there."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@elskwid elskwid commented on the diff Feb 23, 2014
README.md
@@ -84,29 +80,6 @@ Whenever your application loads, these variables will be available in `ENV`:
config.fog_directory = ENV['S3_BUCKET']
```
-## Capistrano integration
@elskwid
elskwid added a note Feb 23, 2014

👋 👋

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@linyows

LGTM

@markrebec

Love this idea! Separating this both gives a better base where we can continue to evolve any deployment stuff as new use cases and deployment tools come about, and it helps to discourage some of the "misuse" of Dotenv and to better inform the community of intended/recommended deployment integrations.

@garno

Love this idea as well! 👍

@bkeepers bkeepers merged commit 6bfd750 into master Apr 22, 2014
@bkeepers bkeepers deleted the deployment branch Apr 22, 2014
@bkeepers bkeepers referenced this pull request Apr 22, 2014
Merged

1.0.0 #106

@orendon

Since bundler require gems in order, this forces the user to put dotenv-deployment before dotenv-rails on the gemfile, otherwise it will show deprecation warning, even if dotenv-deployment is present (At least until #106 gets merged)

@bkeepers Let me know if you want me to update the docs or something, We're good anyway once 1.0.0 is released

Owner

Doh, good point. I should have tried to require dotenv/deployment first and rescued the error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment