Create a Deploy Ready version of Crash API

[bhgrant8]

Certain config changes will need to be made in order to enable our API to be deployed to the AWS cluster. As our Crash API is in a functional form exposing the basic tables, it would be beneficial for us to align with DevOps needs. I would prefer to deploy early and then continue to build from the base point.

Our work here should closely align with this ticket from ops: https://github.com/hackoregon/civic-devops/issues/4

Issue here is to track what we need to track our deliverable from a ops/platform standpoint to get something live that follows our CI/CD deploy strategy.

Base Requirements:

• [x] project team has a Django API that runs successfully
• [x] project team has a working run script (perhaps with our help, or based on a generic template we supply) to launch their API
• [x] project team has tested their API running in a Docker container (based on a generic template we supply), and that it responds to requests outside the container
• [x] API will require no application security (authentication or authorization)
• [ ] Travis web environment configuration will be managed by the DevOps team
• [ ] the rest of the API CI/CD infrastructure from 2017 projects should be sufficient starting place for any project team (don't get wrapped around the axle of trying to accommodate "what-if" scenarios that haven't been presented yet)

Breaking down the last requirement into a bit more detail:

• [x] WSGI HTTP Server - Gunicorn
• [x] Serves staticfiles in prod mode - implements whitenoise correctly, collects static @ runtime, and has staticfiles in .gitignore (http://whitenoise.evans.io/en/stable/django.html)
• [x] config/secrets handled through an env file
• [x] use a gunicorn.config.py file for configuring gunicorn
• [x] using gevent/async workers correctly including any monkey-patching as needed?
• [x] if monkeypatching, way to override to allow dev. server to work in local development
• [x] Create a staging docker-compose to test the deploy version locally
• [ ] .travis.yml
• [ ] Create a travis docker-compose file
• [ ] Testing - #8
• [ ] serve at expected url

[znmeb]

I'm going to propose we use https://github.com/hackoregon/transportation-system-backend/tree/znmeb-merge-new-database as the test case for this, now that it's working locally on my workstation.

[bhgrant8]

Hey @znmeb, I have done most of the work for this in a branch. I still need to review your branch and see how they work together, which I have not had time to do as of yet.

Ultimately we are not looking to move far away from our development/deploy strategy of last year, or to a system which is overly complex, so this will be a consideration and has been in the initial development of our container and repo.

[znmeb]

which branch are you in? I can just fix all the bugs in that the same way I did in mine. ;-)

[bhgrant8]

@znmeb reviewed your branch, only one real issue I saw, maybe a reason for it? Let's focus on that for the moment. I have a game plan here.

[znmeb]

What was the issue? Is it flagged in the review comments?

[bhgrant8]

closing as stale