Ideal deployment?

[daguar]

Placeholder for discussion of the question:

What do the ideal deployment instructions look like for CityVoice?

(And then, what can we hit realistically with the requirements of the app?)

[daguar]

Here's my initial outline of steps for a "user" (here, a deployer):

1. User edits config/content.yml for the AppContentSet configuration (this is CMS-style stuff like what text appears on the front page)
2. User looks at data/subjects_EXAMPLE.csv, and puts their own subjects' data in, renaming to data/subjects.csv
3. User looks at data/survey_EXAMPLE.yml and replaces the stuff there with their own survey, renaming to data/survey.yml
4. User runs rake db:create, rake db:migrate to set up the database locally (see note [1] below)
5. User runs rake import (alternately, rake import:subjects and rake import:survey). This ensures that the CSV and YML files are valid and the import works.
6. User adds and commits the changed files
7. User runs deploy_to_heroku.sh which takes care of the rest of the steps

Thoughts?

[1] This might make a case for the default database.yml using SQLite -- Postgres could then be recommended for serious development, but simple redeployment wouldn't require Postgres.

[migurski]

I like this flow, it’s pretty simple. It implies that the user would need to remember to git commit the .yml, .csv, and other files, but this is in many ways easier than the URL-based flow I talked about in another comment. The script in step 7 might unhelpfully hide a lot of complexity—what actually goes in there, beyond git push heroku?

[migurski]

Ohana’s setup script is an example of one that I think hides way too much complexity, for example. Lots of hard-to-read shell-fu going on in there.

[daguar]

Totally agree on avoiding hidden complexity. (cough, let's install RVM by curling an arbitrary script, cough)

what actually goes in there, beyond git push heroku?

There's a few steps documented in https://github.com/codeforamerica/cityvoice/blob/revamp-for-local-setup/getting_started.md#deploying-to-heroku that are needed, namely:

heroku labs:enable user-env-compile
heroku addons:add heroku-postgresql
heroku config # Look for your postgres URL's environment variable in output, e.g., HEROKU_POSTGRESQL_RED_URL
heroku pg:promote HEROKU_POSTGRESQL_RED_URL # Remember that your "color" here may be different
heroku config:set SECRET_TOKEN=the_token_you_generated_goes_here_no_really_put_it_here_dont_leave_it_like_this

I believe we can remove the Postgres stuff: I think pushing a Rails app will take care of the addon and promotion by default.

So at that point, we're talking 2 steps (user-env-compile and secret token) so probably keep that in the README.

[migurski]

Nice, much simpler. Which env var is needed at the compile step?

[daguar]

This is to make the Rails asset pipeline work.

I've talked with folks at Heroku, and this is basically the bane of their Ruby team's existence. So just trust me on this one. (I also spent literally days making this work.)

There's details here: https://devcenter.heroku.com/articles/rails-asset-pipeline

but if you want me to explain it in detail you will have to buy me a high-quality craft beer.

[migurski]

I too hate the Rails asset pipeline. I’ve asked @pui if there is a way to skip it and just use paths to static assets like a normal human, but she assures me there is not.

[daguar]

(Since we're committing stuff here, we can alternately have users just pre compile assets and put them in source control. This is actually more robust since user-env-var is experimental, but has all the downsides of keeping assets in git.)

[migurski]

Are we talking images and CSS, or per-app voice files as well?

[daguar]

To my mind, just CSS, JS, and images.

I'd vote against voice files, but if we're doing the ultra-minimal approach, we could consider it.

The problem will be as mentioned before: Twilio will cache your voice files based on URL. Could explore hash-based storage strategy for this, but eh.

If you think it'd be worthwhile to consider storing voice files in git, go ahead and open a separate issue and we can... hash it out.

On Feb 23, 2014, at 11:58 AM, migurski notifications@github.com wrote:

Are we talking images and CSS, or per-app voice files as well?

— Reply to this email directly or view it on GitHub.

[daguar]

Actually, how users add voice files is probably on topic for this thread. So nevermind.

[migurski]

Twilio seems to respect cache-control headers. Does Rails know enough about HTTP to correctly generate them?

[daguar]

Ah! Yes! I think I hadn't considered that since our original strategy was S3 (which may also allow for that, but I never looked into it; just tweaked the bucket folder name for version and updated DB.)

Pretty sure Rails can handle the headers for assets. Could even write a custom controller if need be.

On Feb 23, 2014, at 12:09 PM, migurski notifications@github.com wrote:

Twilio seems to respect cache-control headers. Does Rails know enough about HTTP to correctly generate them?

— Reply to this email directly or view it on GitHub.

[migurski]

So, does that mean it's in theory possible to skip the asset pipeline and the experimental feature?

[daguar]

Correct.

Asset precompilation just generates the stuff that will be served, but will need to be redone (and recommitted) if you change anything.

In a "nuke and redo" scenario, this doesn't matter much, though.

[migurski]

:cherries:

[daguar]

Oh hey wait a sec: environment vars now available in all Heroku builds! https://devcenter.heroku.com/changelog-items/416?utm_source=dlvr.it&utm_medium=twitter

[migurski]

Nice!