The API-driven next-generation MAYDAY site
This is currently deployed on Heroku in two environments:
- Staging https://services-staging.mayday.us/
- Step Two Staging: https://services-step-two.mayday.us/
- Production https://services.mayday.us
application.html.erb template includes a
<meta> tag instructing search engines to not index anything on the site.
The app is a standard Rails app right now, so getting started should be straightforward for those with Rails experience.
After you clone the repository, copy the
.env.example file to
.env, and supply real values for any environment variables you will need for your development work. Another MAYDAY Tech Team member can help you with this.
If you already have Docker and Docker Compose installed, starting this app is as easy as
After you've created the Docker containers, you can apply the migrations to the database with
docker-compose run web rake db:migrate.
If you don't want to use Docker for some reason, you can also just install ruby and all dependencies on your own:
- Install RVM.
- Install Redis
- Install Posgres and set up a user account.
- Install gems w/
You will also need to start a local PostgreSQL database and a Redis instance.
Finally, apply the database migrations with
This app uses sidekiq to do background processing for a few tasks.
By default, the app expects a sidekiq worker process to be available. You can start this process locally by running
bundle exec sidekiq -c 5.
If you don't want to send jobs to sidekiq, you can set the
SIDEKIQ_TESTING environment variable to
Deployment & Hosting Environments
To hook up this app with Heroku's command line tool in your development environment, follow these instructions:
- Make a Heroku account if you haven't already
- Get someone to add you as a collaborator on the staging Heroku app
- Install the Heroku toolbelt on your machine: https://toolbelt.herokuapp.com/
- Once installed, run the
cdinto your clone of this repository, and run
heroku git:remote -r staging --app mayone-staging
You can test if it works by running a command like
You can now deploy to staging the standard Heroku way. Example:
git push mayone-staging master
Common Staging Commands
Once you are connected to heroku, you can use the following to help testing
heroku run rake db:seed # seeds the db w/ legislators, states, zips heroku run rake db:seed:dummy_data # creates dummy campaign heroku run rake db:purge # Purge DB of all data heroku run rake db:purge:api # Purge DB of API generated data heroku run rake db:purge:dummy_data # Purge DB of dummy seed data
Note: only run
rake db:seed after full purge
Deploying to Production
Deployments to production are still manual for now. If you have already configured Heroku as specified in the development section above, you're halfway there:
- Get someone to add you as a collaborator on the production Heroku app
cdinto your clone of this repository and run
heroku git:remote -r prod --app mayone-prod
You can now deploy to production the standard Heroku way. Example:
git push prod master
You can also look at production logs with
heroku logs --app mayone-prod.
The site currently uses Travis CI for Continuous Integration (CI). Whenever new code is pushed to the master branch (or included in a pull request), Travis will start a new build for that code.
Watch the builds here: https://travis-ci.org/MayOneUS/mayday-2.0-backend
All successful builds of the
master branch will be automatically deployed to the staging Herkou app. All successful builds of the
m2 branch will be automatically deployed to the step two staging app.
This app is configured to use New Relic's application monitoring.
The easiest way to access the monitoring data is through the Heroku dashboard:
- Go to https://dashboard.heroku.com/apps
- Click on either the staging or production apps
- Click on New Relic APM.
You will be automatically signed in to the New Relic dashboard.
We use a different approach to monitor sidekiq (taken from the sidekiq wiki). First, we expose two URLs which give basic information about the queue status:
OKif the queue size is less than 100, or
UHOHif it's above 100
OKif the queue latency is less then 30 seconds, or
UHOHif it's above 30 seconds
We monitor these URLs using Pingdom and alert our Slack #engineering channel when there's an issue.
We also run the sidekiq dashboard UI on our Heroku servers. You can access it by going to
/sidekiq. Ask another MAYDAY Tech Team member for the password to this dashboard on our staging and production servers.
Sometimes the production site has hiccups. Here are tips on how to solve some common ones:
Maxing out Postgres connections
About every other month, a New Relic alert gets triggered because our Heroku dynos can't connect to the Postgres database. This is most likely because the Postgres database has run out connections - our current plan only allows for 20.
Until we can figure out something better, solve this by running killing the current connections. Run
heroku pg:killall -amayone-prod. That will terminate all connections to the Postgres database. You should then run
heroku restart --app mayone-prod immediately so that all worker and web dynos reestablish their connections to the database. We haven't prioritized resolving this as it doesn't seem related to traffic congestion.
Contributing / Code Review Process
Key Goal: Ensure at least two parties have reviewed any code commited for "production."
- Fork/Branch off any new feature development
- Regularly commit to your branch.
- When done, create merge request into master. Your merge request should be conflict freeand all tests should be passing.
- Assign another developer to review your merge request.
- Merge request is reviewed and made on github.
This project is open source under the Apache License 2.0.
Note that while this license allows code reuse, it does not permit reuse of Mayday PAC branding or logos. If you reuse this project, you may need to remove Mayday PAC branding from the source code.