Home

Awesome

App Prototype

...

Generated with Raygun.

Development

Getting Started

Requirements

To run the specs or fire up the server, be sure you have these installed (and running):

To manage deployments you will need:

It is strongly recommended that you use a version manager like rbenv (for Ruby), nvm or nodenv (for Node), or asdf (for both) to ensure the correct Ruby and Node versions.

First Time Setup

bin/setup

After cloning, run ./bin/setup to install missing gems and prepare the database.

Note, rake db:sample_data (run as part of setup) loads a small set of data for development. Check out db/sample_data.rb for details.

.env

The bin/setup script will create a .env file that defines settings for your local environment. Do not check this into source control. Refer to the environment variables section below for what can be specified in .env.

Running the Specs

To run all Ruby and Javascript specs.

$ ./bin/rake

Note: ./bin/rake runs the bundled version of rake (there's a ./bin/rspec and ./bin/rails too). You can add ./bin to your PATH too, then you'll always use the correct version of these scripts as enforced by the Gemfile.lock.

Running the Application Locally

The easiest way to run the app is using yarn start. This starts all the processes needed for development, including the Rails server and the webpack dev server. See package.json for details.

$ yarn start

The app will then be accessible at http://localhost:3000.

Webpack Dev Server

By default, webpacker will compile assets on demand. In other words, you don’t need to precompile all assets ahead of time — webpacker lazily compiles assets it has not served yet. However, you will need to manually reload your browser to see new changes when you edit an asset.

Alternatively, for live code reloading, you can run ./bin/webpack-dev-server in a separate terminal from rails s. This done for you automatically if you use yarn start to run the app. Asset requests are proxied to the dev server, and it will automatically refresh your browser when it detects changes to the pack.

If you stop the dev server, Rails automatically reverts back to on-demand compilation.

Conventions

Git

Code Style

Rubocop is configured to enforce the style guide for this project.

Additional/Optional Development Details

Code Coverage (local)

Coverage for the ruby specs:

$ COVERAGE=true rspec

Code coverage is reported to Code Climate on every CI build so there's a record of trending.

Using retest

Install and run retest to automatically listen for file changes and run the appropriate specs:

$ gem install retest
$ retest

Using ChromeDriver

The ChromeDriver version used in this project is maintained by the webdrivers gem. This is means that the feature specs are not running against the ChromeDriver installed previously on the machine, such as by Homebrew.

Headed vs headless Chrome

System specs marked with js: true run using headless Chrome by default, in the interest of speed. When writing or troubleshooting specs, you may want to run the normal (i.e. "headed") version of Chrome so you can see what is being rendered and use the Chrome developer tools.

To do so, specify HEADLESS=false in your environment when running the specs. For example:

$ HEADLESS=false bin/rspec spec/system

Continuous Integration/Deployment with CircleCI and Heroku

This project is configured for continuous integration with CircleCI, see .circleci/config.yml for details.

On successful builds, Heroku will trigger a deployment via its GitHub Integration.

Server Environments

Hosting

Acceptance and Production are hosted on Heroku under the email@example.com account.

Environment Variables

Several common features and operational parameters can be set using environment variables.

Required for deployment

Optional

Third Party Services