The Money Advice Service's responsive website.
Clone the repository:
$ git clone --recursive https://github.com/moneyadviceservice/frontend.git
Make sure you've added the following line to your
Make sure all dependencies are available to the application:
$ bundle install $ bowndler install
Install Mysql 5.5
$ brew tap homebrew/versions $ brew install mysql55
Make sure MySQL is running.
$ brew services start mysql55
Setup the database:
bundle exec rake db:create && bundle exec rake db:schema:load
Copy the features.yml.sample to the config dir:
cp config/features.yml.sample config/features.yml
Make sure to copy the .env-example file:
cp .env-example .env then set .env variables (i.e. GOOGLE API KEY) stored in KeepassX to run tests locally ## Usage To start the application: ```sh $ foreman s
Change CMS URL Path
In development, frontend will use the local CMS for convenience. You can change the MAS_CMS_URL on .env file. Use http://cms.moneyadviceservice.org.uk to point to LIVE content, https://cms.qa.dev.mas.local for testing Or http://localhost:PORT to point to a local running CMS.
Don't forget to restart the server after the modification.
- Fork it
- Create your feature branch (
git checkout -b my-new-feature)
- Keep your feature branch focused and short lived
- Commit your changes (
git commit -am 'Add some feature')
- Push to the branch (
git push origin my-new-feature)
- Create new Pull Request
features: an_active_feature: true an_inactive_feature: false
At runtime you can use these toggles in order to decide whether or not to show a feature:
Feature.active?(:an_active_feature) # => true/false Feature.inactive?(:an_active_feature) # => true/false Feature.with(:an_active_feature) do # code end Feature.without(:an_active_feature) do # code end
Our feature toggles are designed to be used to hide partly built features, often referred to as release toggles. A toggle and any conditional behaviour must be removed once a feature is complete.
Note that the local configuration file config/features.yml is ignored in git so make sure to run any acceptance tests with the feature toggled on and off locally.
If you need to enable a feature in any tests you can use tags. For example, in feature tests you can use:
@enable-feature-name Scenario: View great new feature When I visit the website Then I should see this great new feature
Where the cucumber tag
@enable-feature-name will enable the feature
feature_name for the cucumber scenario.
We like to develop features from the outside in. We write our user stories in a declarative style. When contributing a feature:
- Create a new feature file in features.
- Write scenarios to exercise the scope of the feature in it's entirety.
- Create page objects in features/support/ui and expose them to the world in features/support/world/pages.rb.
- Start with a failing scenario then make it pass.
- Write unit tests for the objects you identify for your feature.
- Start with a failing unit test then make it pass.
- Keep your unit tests isolated.
- Test your features against the mock API and record interactions with VCR.
The application is backed by a RESTful JSON API. This is described for humans as a blueprint file using the API Blueprint Language Specification. Changes you make to the blueprint file will be automatically reflected in the online API documentation and mock API.
### Writing front-end code
We recommend having a flick through these when working on new features:
- Front-end Code Standards – an in-depth guide to the standards we follow
- Common front-end gotchas – quick reference for some common gotchas that may be picked up in PR reviews
- Working with Dough – some information on how Dough works
- Adding Dough to a fresh Rails app
Front-end Package Management
The application uses Bower to manage front-end packages. Dependencies should be defined in the bower.json configuration file. Once installed they will be automatically available to the asset pipeline.
Consuming the front-end without having to manually import dependencies
Useful if you're an agency and want to get up and running quickly, we render both
English and Welsh versions of our 'empty' template. This can then be pulled in via
curl or good old view-source and copying & pasting.
There are minor differences to the header and footer in the empty template, to enable the HTML to run in a static fashion. For example, we remove the authentication links in the header as they require knowledge about the user's sessions – which can't easily be shared across multiple sites, domains, etc.
This is done via a
hide_elements_irrelevant_for_third_parties? flag in the views.
Projects such as RAD keep this stored in their repo, and have a simple CSS file that overrides or adds the bits they want.
Run the following in the command line.
RAILS_ENV=development bundle exec rake karma:install karma:run_once
Deploy to staging and production
Today the current process occurs in GO. You need to change the build number here: https://github.com/moneyadviceservice/scripts/blob/master/puppet/extdata/common.yaml#L249
Make sure before you changed and open a PR to run the follow script and paste on the PR description:
./bin/mas-version-diff 1869 1870
Obs.: 1869 and 1870 is just an example of versions to be shown. Use the GO build number in ascending order.