Skip to content

Latest commit

 

History

History
161 lines (112 loc) · 4.05 KB

DEVELOPMENT.md

File metadata and controls

161 lines (112 loc) · 4.05 KB

Development

Requirements

Install Dependencies

bin/bundle install

Run Migrations

bin/rake db:migrate
bin/rake user:create_default

Start Server

bin/rails s
open http://localhost:3000
# Login with password `demo`

Start Worker

bin/rake jobs:work

Start Server and Worker

bin/foreman start

Run Tests

Run all tests:

bin/rspec

Continuously Run Tests

Guard automatically runs your tests whenever a file is modified:

bin/guard
  • Type all to run all tests.
  • Type exit to leave guard.
  • Install the Livereload browser extension to automatically reload the browser page.

Automatically reloads a page on asset modification via the following browser plugin:

Setup Production Environment Locally

  • Requirement: Setup local PostgreSQL
# Via Make
# NOTICE: `prod_create_db_user` uses the `postgres` DB to create a new CWB PostgreSQL user (called cloud)
make prod_create_db_user prod_setup

# Manually
export RAILS_ENV=production
bin/rake db:setup
bin/rake user:create

Run in Production Mode Locally

# Via Make
make prod_run

# Manually
export RAILS_ENV=production
export RAILS_SERVE_STATIC_FILES=true
export RAILS_LOG_TO_STDOUT=true
export PORT=3000
bin/rake assets:precompile
bin/foreman start -f Procfile_production

Run Linter

make lint

Tips & Tricks

  • The Rails application preloader Spring automatically speeds up your development.
  • Tests can be tagged (e.g., useful for slow tests)

Local Integration Testing Environment

  • CWB can be locally installed into 2 Virtualbox VMs. Follow the Installation steps using the template from install/virtualbox/Vagrantfile

  • Notice that cloud VMs cannot communicate with the local machines unless both VMs (chef-server and cwb-server) have public hostnames.

  • The Vagrant plugin vagrant-cachier can speed up development by serving as a cache for apt, gems, etc.

    vagrant plugin install vagrant-cachier

Conventions

Commit Messages

  1. Capitalize the subject line (e.g., Fix ... instead of fix ...)

  2. Use imperative verbs in the subject line (e.g., Fix instead of Fixed)

  3. Use the body to motivate the change (i.e., what?, why?, how?) when appropriate. Example:

    Fix HTTP status codes for errors
    
    Problem: Errors (i.e., 404, 422, 500) returned 200 by mistake
    Solution: Return the right error code by calling the right helper method
    

Common prefixes are: Fix, Add, Update, Remove, Improve

Branching Strategy

This project uses short-lived features branches typically prefixed with:

  • feature/ introducing new functionality
  • fix/ fixing an issue
  • support/ supporting changes related to documentation, deployment, or testing

Feature branches are merged into master via Github pull request after a successful build. Minor changes (e.g., README updates) can be committed directly into master (Hint: [skip-ci] skips the CI build for minor commits).

Release / Deployment Strategy

This project follows a continous delivery deployment model and therefore does not use the notion of releases. Checkout the cwb client library for a publicly released Ruby gem.