Improving the Quality of Care, one Metric at a Time.
| Build | Status | Code Quality | Test Coverage |
|---|---|---|---|
| Acceptance |  |
 |
|
How do I, as a developer, start working on the project?
Ruby version is specified in .ruby-version. Recent versions of rbenv will detect it automatically.
This project requires Dabo's development provisioning system, Boxen. Go here to setup Boxen.
After setting up Boxen, you can use boxen to clone and setup the Iris project automatically in ~/src/iris by running:
$ boxen iris
Boxen will:
- Ensure Postgresql is installed and running
- Install project version of Ruby and automatically run
bundle install - Install required npm packages (jshint, jscs) by running
npm install - Prepare development and test databases as well as default config/database.yml
- Setup nginx/dnsmasq so you can access the development server at
http://iris.dev/
foreman start
- To start the web server only:
foreman start web - To start the Sidekiq server only:
foreman start worker
open http://iris.dev/(oropen http://localhost:3000)
Heroku access is needed for loading realistic data from integration, staging, and production environments, as well as deploying to any of these environments.
- Obtain
[email protected]Heroku credentials from Passpack. - Login from the command line:
heroku login - Add the Heroku repos:
for x in integration staging production; do git remote add ${x} [email protected]:iris-${x}.git; done
In Rails 4, binaries (rails, rake, rspec) now live in bin/. You no longer need to prefix these commands with bundle exec. Instead, add bin to your PATH environment variable:
# ~/.profile
export PATH=bin:$PATH
Iris uses RSpec for ruby tests and Jasmine for JavaScript tests.
rspecwill run all ruby specs.rake jasminewill start the Jasmine server. Point your browser tolocalhost:8888to run all javascript specs in the browser. The suite will run every time this page is re-loaded.rake jasmine:ciwill run Jasmine specs on the command line without the need for a browser.
In your controllers specs, wrap any command that gets a response (like get :show) in
save_fixtures do. This will generate an html file in
spec/javascripts/features/.
Alternatively, you can add save_fixtures to the bottom of a test that calls
get and it will save the response body as the fixture. However, this method
will not stub out the user id and user email in the headers and footers,
meaning the fixture could change each time controller specs are run.
Then in your jasmine specs, use loadFixtures('the-generated-file.html')
in a beforeEach to have it available in the #body div.
If you are testing features that are hiding behind a feature flip, you will
need to run enable_feature :feature_name inside the save_fixture block
to get it in the generated fixture.
Tests are run on each branch on GitHub via Semaphore
Any branch that passes CI and has an open pull request will have a Heroku instance created modeled after iris-acceptance, available at http://iris-acceptance-[pr_id].herokuapp.com
Feature tests are run in Chrome via Selenium. The Semaphore CI platform also runs feature specs in Selenium Chrome.
Iris is deployed to Heroku. CI will automatically deploy passing builds to the Heroku apps below:
| branch | app | site |
|---|---|---|
| master | iris-integration | iris-integration.herokuapp.com |
| staging | iris-staging | iris-staging.herokuapp.com |
| production | iris-production | iris.dabohealth.com |
| feature branches | iris-acceptance-[your-pr-id] | e.g iris-acceptance-1234567 |
A procedural shell script manages the deploys to Heroku by using Heroku's pipelines to compile a slug once and promote that slug downstream to each successive environment app. The deploy process is outlined in the graphic below.
-
The CI deploys code to
iris-build-slugafter code is pushed to Master and all tests pass. -
Integration has all the code that will be included in the next release. It is where code is merged to Master. Continuous Integration tests must pass before deployment. Data is refreshed as needed. During deployment,
integrationwill enter maintenance mode, promoteiris-build-slugand run migrations. -
Staging is used as a production deploy test, or production practice. Data is always refreshed before deployment. During deployment,
stagingwill enter maintenance mode, copy data from the production database, promoteintegrationand run migrations. -
Production is the only place where users (Dabo staff or customers) access our systems. This is the only environment in which the deploy process is started by a human. The on-call engineer (described below in "Deployment Schedule") will manually deploy code to
productionfrom the CI.
Integration and Staging applications use sanitized data from production (real metric samples and other data, but all personal information scrubbed).
Migrations are run regardless of whether there are new migrations or not.
Temporary "acceptance" apps are created upon opening a pull request for a feature branch. After the pull request is closed, the acceptance app is automatically spun down. See our [acceptance app manager] (https://github.com/dabohealth/acceptance-app-manager#acceptance-app-manager) for details.
Continuous deployment of bug fixes and performance improvements take place Monday–Thursday (never Friday or weekends/holidays). For every production release, an engineer is responsible for deployment and will be on-call until the next release. Additionally, the on-call engineer from the previous deployment will serve as backup on-call.
A [feature flipping gem] (https://github.com/dabohealth/iris#feature-flipping) manages feature deployment. Features can be enabled at a certain time and for certain clients.
Heroku provides scheduled database backups. For a list of available backups for that Heroku environment, run:
heroku pgbackups -a iris-[integration|staging|production]
See https://devcenter.heroku.com/articles/pgbackups for details.
Errors are sent to Airbrake.
New Relic is included in the project in development and via Heroku environments. To see metrics on recent requests in development run:
open http://iris.dev/newrelicor (open http://localhost:3000/newrelic)
In production, use the Heroku web resource link to browse to the New Relic dashboard for the app.
Treat .env like a schema for environment keys. Those needed to run the app in development mode should be set already. Blank entries are not needed in development mode but are used in at least one of the production environments (where they are set via heroku config).
- Javascript code quality is ensured by two npm packages: JsHint and JSCS. They will run automatically as a pre-commit hooks.
Rubocop is configured in .rubocop.yml to enforce code quality and style standards based on the Ruby Style Guide and runs every time you commit using a pre-commit hook.
To identify and have Rubocop automatically correct violations when possible, run:
rubocop -a [path_to_file]for individual filesrubocop -afor all Ruby files
Dabo's current engineering workflow has been fully documented and can be found here.
Features can be enabled or disabled using the Flip gem. The gem provides a dashboard, found at /flip, where a feature can be actived using one of the following strategies:
- default (Allows all features to be enabled/disabled by default. Feature defaults will override this value.)
- database (To flip features site-wide for all users.)
- cookie (To flip features just for you.)
- Declare feature in
app/models/feature.rb
feature :example, #choose a name for your feature
default: false, #disables by default
description: 'An Example'- Use
feature? :feature_nameto restrict/allow access to a feature in the view.
- if feature? :example
%h1 This will be shown if the feature is enabled!
- else
%h1 Otherwise this will be shown!The project backlog is in Pivotal Tracker.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent