[1074] ITS deployment

[orenyk]

Resolves #1074, finishes setting up Capistrano for deployment.

[orenyk]

Ok, squashed and ready for review!

[mnquintana]

🔥 Extra space here

[orenyk]

Good catch.

[orenyk]

Just updated dotenv-rails, moved it to the default Bundler group, and removed dotenv-deployment as mentioned in my last comment.

[orenyk]

We've dealt with a bunch of issues on the ITS side but have finally run into an interesting bug. Since we're updating very old databases there are a bunch of migrations to run, including the EquipmentObject --> EquipmentItem migration followed (later) by the Reservation.approval_status removal migration, which does a bunch of processing on existing reservations to convert any information from that column into either status, overdue, or a tag.

Two issues:

1. Apparently it's really bad practice to use Rails models when touching data in migrations, due to the strong possibility of things getting screwed up later (see here). Apparently good practice is to write SQL statements directly or create local versions of the model, so we should keep that in mind for the future.
2. More problematically, this migration is failing when it tries to save the reservations since it's running validations, more specifically matched_item_and_model which tries to check and make sure that the reservation has been assigned an equipment item, i.e. has been checked out. However, Rails somehow knows that the original association was for an equipment_object (even though the model file has changed), so it's trying to read the equipment_objects table, which doesn't exist and the migration fails.

Ideally, I wish there were a way to "reload" Rails after running a table rename migration so that all models and associations were up-to-date, but this is also a kludge-y fix for bad code 😞. Take-home number 1 is that we shouldn't rely on Rails models in our migrations anymore. Luckily, this migration calls save! at the end so editing to call save!(validate: false) shouldn't violate the principle of never editing migrations too badly and should resolve the issue in this case. I'll go ahead and do that now.

[orenyk]

Also, for posterity, we ran into #1282 and I forgot that I had already fixed it so there was temporarily a duplicate fix in this branch. I rebased onto master and took the fix from there.

[orenyk]

Woo hoo, it is fixed! Man, going back to the v3.4.x codebase makes me really appreciate all the work we've done, particularly with rake db:seed (thanks @squidgetx!). I've now seeded a database from v3.4.10, had to manually make sure that every reservation with an equipment item had been checked out (since this was not guaranteed and would cause one of our migrations to fail), and then checked out this branch and successfully ran rake db:migrate. Hopefully this will be the last bug we have to fix for ITS!

[orenyk]

We've been asked to add an environment variable to disable ALL e-mails for DEV deployments; I'm adding this and using it to optionally set config.action_mailer.perform_deliveries = false in production.rb.

EDIT Done and updated the wiki!

[orenyk]

At this point they've got Capistrano deployment working and just have to build the Jenkins wrappers around it, can someone re-review this code so we can merge it into master?

[orenyk]

Ok, @esoterik looked this over and gave it the green light, I'm going to merge it (finally)!