Webhook for deploying

[mtbentley]

After the tests pass, build the docker container and deploy it to a test server (ie docker.case.edu:3000). Once it gets a +1 from a team member, push it live.

This will probably be done with a really simple python web server running on the docker.case.edu, and tag the docker images with ":test" for testing and ":latest" for production.

[StephHippo]

💯 for Continuous Delivery

[mtbentley]

Some more thoughts: on pull requests, pull the refspec looking to be merged, try to docker build it (it should work), tag it with the git commit hash, and run it on a random port. If nothing breaks, comment asking for a team member to +1 it. After it's +1'd and merged into master, automatically deploy.

Some considerations:

1. When to rake db:migrate?
2. rake db:migrate should be run on a test db, NOT PRODUCTION.
3. Have an automated system to load the test page and run some basic tests to make sure it doesn't 500 and stuff mostly looks correct?
4. Anything else? Thoughts are welcome.

[mtbentley]

Also, tag versions with github tags and well as Docker tags for easy rollback and bug identification. Should probably (definitely) make sure there's a way to signify backward-incompatible database schema changes.

[ajm188]

My thoughts are your first comment (referring to "some considerations"):

1. Always run rake db:migrate. If there are no pending migrations, it doesn't do anything, so this is harmless.
2. Definitely
3. If it just runs the feature tests I think that should be fine.

[ajm188]

Tagging versions is going to be a little trickier. We can always safely bump the patch number, but detecting when we should bump the major/minor number is going to be more difficult.

For example, we can use rake to detect whether or not there are pending migrations, but we can't tell programmatically if those are backwards compatible (and we would bump the minor version) or not (and we would bump the major version).

I think we could solve the migration issue programmatically by parsing the pending migrations (which I know how to do), but there are probably other issues with this that I haven't thought of yet.

[mtbentley]

It (tagging) is mostly so we don't roll back to a version that's incompatible with the production DB schema. We could simply bump the minor version (y in x.y.z, did I get that naming right? It's major.minor.patch?) when there are migrations, and then manually check compatibility if we need to roll back to an older minor version.

[ajm188]

Yeah you have the naming right. The problem is that if a migration removes a column from a table for example, that's a breaking change, so it should bump the major version. So you can't just bump minor version indiscriminately.

[mtbentley]

OK. It's not too big of an issue, since as long as we get the tests right we won't have to roll back very often. We can figure out version numbers when this actually becomes a feature.

[ajm188]

Agreed

[mtbentley]

This should automatically build the docker image every time changes are pushed to master. The next (and last) step is to setup a docker hub webhook to tell the server to re-deploy on changes.

EDIT: server-side configs updated to pull from hacsoc/jolly-advisor. Now all that's needed to redeploy is to SSH in and run one command. It seems to all work.

[mtbentley]

It will also re-build each time rails updates too.