Document and set up generalized deployment

[shippy]

Right now, deployment is a black box that only few understand, and I'm sick of reading about everyone deploying all the time. As our test suite, continuous integration and in-production monitoring get better, I think we should work towards the ability to deploy (a) often, (b) comfortably, (c) simply and (d) without bothering Michael Dunlap all the time.

2014/11/11

Deployment:

• Compile list of configuration parameters
• Move configuration parameters into secrets.yml with ENV calls for production
  • now I'm not sure about this, we might just want to call ENV directly...
• Install dotenv-deployment in the production and staging groups
• Test deploy.rb
• Add wiki page
• Update README instructions

Logistics:

• Talk to Michael about syncing DEV instance databases
• Figure out new deployment script structure (maybe still use Capistrano?)
• Figure out changes necessary to Jenkins script
• Should we be resetting the secret key every time? (probably not)

[orenyk]

You beat me to it! Let's make this the main issue for documentation and add deployment adjustments/fixes as new issues as they come up.

[orenyk]

This is critical in order for us to implement the Heroku button and export this app effectively. I've documented the Yale deployment process fairly well in my presentation, but we need to extract from the deployment script a generalized set of deployment instructions. Moving to v4.2, will start discussions with Mike to figure out what needs to happen.

[orenyk]

There has been a lot of discussion about this in the PR for party foul (#770) since I removed an outdated Capistrano deployment script in that branch. We should ultimately offer a generalized deployment strategy using some standard tool for future clients and that script can serve as a starting point for that work. Until then, as I said in the other conversation, I'd rather have no script than a broken one.

[orenyk]

Don't forget to add instructions for the cookie session store (see #880)

[orenyk]

I'm going to go through the current shell script and describe what it does; we can use this as a foundation for our conventional deployment script:

1. sanitize the install.properties file (cannot find this) and run it
2. run the install-${ENV}.properties file (ENV is set by Jenkins)
   1. sets repo_url variable w/ https GitHub url for subsequent git clone
   2. sets the host_name variable (e.g. reservations.example.com)
3. stores current directory as deploy_dir
4. exports the RAILS_ENV environment variable with an install-configured value (in our case either staging or production
5. clean up workspace (removes nodename file with the name of the directory you'll use to store the repo clone - appears to be reservations01 within the current deploy script directory / deploy_dir above)
6. git clone the repo into that directory and move into it
7. git fetch
8. git checkout --force $tag_version where tag_version is the user-configured release tag
9. For each customer:
   1. run install-${ENV}_${CLIENT}.properties (where CLIENT is defined in Jenkins / defined by existence of file in directory)
      1. sets rails_environment variable
      2. sets app_path variable with absolute path to installation directory
      3. sets database variable with database name
      4. sets database_host variable with database server hostname
      5. sets db_username and db_password variables with Jenkins parameters
      6. sets uri variable with client subdirectory (e.g. /clientname where the actual URL is reservations.example.com/clientname)
   2. delete a set of linked directories (log/, public/system/, public/attachments/, and vendor/bundle) and re-link them to directories in the shared/ directory (where shared is a sibling of the nodename directory where the app is located).
   3. if Gemfile.lock exists, go into the nodename directory and bundle install --path vendor/bundle
   4. rename skeleton/template database.yml file, copy in parameters (using sed), and copy it into nodename/config/database.yml
   5. rename skeleton prefix.rb initializer, copy in uri parameter, and move it to nodename/config/initializers/prefix.rb
   6. fix email links (see Email links potentially broken #868)
   7. remove archived build in previous directory, then copy build in current directory to previous directory
   8. move code from nodename to current (they are in different directories)
   9. rake db:migrate if Jenkins parameter passed as true
   10. rake assets:precompile in production or staging Rails environments
   11. in production, run whenever --update-crontab --set "rails_root=$app_path/current" --set "environment=$rails_environment"
   12. create / touch current/tmp/restart.txt to tell Passenger to restart app

So... not too much actual Rails setup, most of this is just moving code around in a way that is probably specific to Passenger / the Yale Rails farm. Next step: look into Capistrano and figure out what actual steps we need to configure / prepare a fresh app (and potentially look into using the production version of dotenv).

[orenyk]

Capistrano info here

[orenyk]

Ok, so reading more into Capistrano it seems like it would almost be a replacement for our deploy script, rather than a supplement to it. It also seems like we wouldn't want to commit Capistrano files that are Yale-specific, so I'm not sure how much of our workflow belongs in the repo and how much should be handled by ITS. I'm going to put this on hold pending further discussion w/ ITS folks.

[caseywatts]

When we get to Rails 4.1 we might use the secrets.yml and it could simplify our seding step quite a bit.

[orenyk]

Ooo good idea. I'll add an issue for that separately.

[orenyk]

#1018 is going to be implemented in #2. I've currently got three environment variables that we'll need to set: SECRET_KEY_BASE, DEVISE_SECRET_KEY, and DEVISE_PEPPER.

[orenyk]

In-progress list of environment variables:

• CAS_AUTH
• CAS_BASE_URL
• RAILS_RELATIVE_URL_ROOT (effectively prefix.rb / uri)
• DB_NAME
• DB_USERNAME
• DB_PASSWORD
• DB_HOST
• PARTY_FOUL_TOKEN
• RAILS_HOST_NAME (for e-mail links)
• LDAP config
• E-mail config
• time zone? (TZ? Not sure how best to handle this)

[orenyk]

Deployment-dependent environment variables (to be saved by Jenkins):

• ENV (e.g. ror_dev or ror_prd)
• HOSTNAME (e.g. reservations.yale.edu or development.reservations.yale.edu)
• APP_NAME (e.g. art or bmec)

These are necessary to set up the deploy directory.

EDIT Alternatively, we can just have DEPLOY_DIR and GIT_TAG (and everything else should be in .env)

[orenyk]

don't forget to add gem 'dotenv-deployment' to the production group in the Gemfile

[orenyk]

Ok, I set up a basic deploy.rb file with configuration options, but I'm not sure how to test it, particularly the whenever gem setup as well as, well, everything. I've consolidated most of the environment variables into a .env.example file (although we still need to deal with LDAP, e-mail, and maybe time zone); I still need to write a detailed wiki page on deployment, update the README instructions with the basics (linking to the wiki article), and deal with logistics. I'd also like to make the ENV['CAS_BASE_URL'] call dependent on the presence of ENV['CAS_AUTH'], but that needs to wait on #1032 and a merge of master into this branch. Done for tonight!

[orenyk]

Added the e-mail config to secrets.yml / .env.example and moved around some Devise parameters depending on whether or not ENV['CAS_AUTH'] is set. I also added dotenv-deployment to the production group in the Gemfile. We still have to deal with LDAP (see #653), so I'll leave it for that issue and open a PR. I will talk to ITS about this in a few weeks.

[orenyk]

I also need to do some more documentation (e.g. write up a wiki page and update the README).

[orenyk]

On second thought, I've merged #653 into here and have implemented the code. Testing for now...

[orenyk]

Ok, so via manual testing it appears as though LDAP works post-refactor, both for CAS and non-CAS authentication (you search by e-mail for non-CAS authentication). This should be documented somewhere but that was way less painful than I imagined it to be.

[orenyk]

I realized that I haven't tried our test suite since making all of these changes... taking a look now :-)

[orenyk]

NVM, all of these were already passing via Travis. I think it's time to document all of the relevant parameters in the wiki and then it's time to merge so that I can move on to Heroku / #275.

EDIT I think we're probably better off forgetting about Capistrano for now and just focusing on the general configurability and deployment of Reservations. The specific deployment methodology might take some time to iron out with ITS but I don't think we should let it block these improvements.

[orenyk]

Configuration parameter definitions now written up here.

[orenyk]

Ok, README has been updated to point people to the wiki page where all of the environment variables are defined. It also includes instructions for setting up config/secrets.yml for local "deployment". I've added config/secrets.yml to .gitignore and moved it over as an example; new developers will have to copy over the example file to get started and should regenerate all of the secret keys and tokens.

The authentication wiki page needs to actually be written (I kinda left it bare-bones when I finished #2), but I think otherwise we're ready to move things forward. Once this is merged in I think we'll be ready for Heroku (see #275)!