DEPRECATED - no longer actively maintained

---

Register With A GP Beta Web

master: last commit:

Front end for the register for a GP beta service

TODO: Fill out this long description.

Table of Contents

• Install
• Usage
• Contribute
• License

Install

Local Environment (option 1)

Node

Install Node for your platform. We are targeting version 7.5.0 which is the current release as of writing. If you already have another version of node you can use a Node version manager so select the correct version, the following are good options for managing installed Node versions:

• n
• nvm

Environment Variables

Create your .env file on your local project directory and define these variables.

NODE_ENV=development
SESSION_SECRET=put_in_a_random_string_here_thats_longer_than_thirty_two_chars

POSTCODE_API_HOST=api.getAddress.io
POSTCODE_API_KEY=<getAddress.io API KEY>

GP_LOOKUP_API_URL = http://localhost
GP_LOOKUP_API_PORT = 9292
GPLookupAPISSL = "0"

GP_EMAIL_ROSEBANK_HEALTH=test@test.com
GP_EMAIL_PEEL_CROFT_SURGERY=test@test.com

The GP emails variable name template is GP_EMAIL_<THE_GP_KEY> in upper case form.

Dependency Management: Yarn

Once you have node installed, you need to install the yarn package manager. This will allow you to install the JavaScript dependencies that are specified in package.json

$ yarn

Docker & Compose (option 2)

Make sure you have Docker and compose installed for your operating system then run:

$ docker-compose -p gp-reg -f docker-compose.yml up --build --force-recreate

Note: The Dockerfile is currently set up to provide a development (live-reloading) server, we need to look at removing devDependences from the runtime environment when we do start hosting in Rancher

If you want to run in production mode then you should run:

  docker-compose -p gp-reg -f docker-compose.yml -f docker-compose.prod.yml up --build --force-recreate "$@"

Because these commands are annoying to type there are some helper scripts in the bin directory:

Script	Command
bin/dev.sh	$ docker-compose -p gp-reg -f docker-compose.yml up --build --force-recreate
bin/prod.sh	$ docker-compose -p gp-reg -f docker-compose.yml -f docker-compose.prod.yml up --build --force-recreate "$@"

To correctly test the production version (it sends cookies with the secure flag) you will need to browse it with a HTTPS connection. I do this by installing a local proxy that generates a self signed certificate and forwards all the traffic.

# globally install dev proxy
$ npm -g i dev-proxy

# start server in detached mode
$ ./bin/dev.sh -d

# start dev-proxy
$ dev-proxy -p 3333:3334

then browse to https://localhost:3334 - you will get a certificate warning and you can either install the local dev certificate or ignore the warning if you know what you're doing.

Usage

Development

$ yarn run dev

ES2017 and Babel

The JavaScript in the project is written in ES2017 and transpiled into ES5 using Babel, you can view our babel configuration in package.json under the "babel" key.

Environment Variables

Variable	Description	Default
NODE_ENV	if we are running in production or development mode	development
PORT	the port for the http server to listen on (optional)	3333
SESSION_SECRET	the password for signing the session cookie	No default
EMAIL_USERNAME	Username for Exchange Webservice
EMAIL_PASSWORD	Password for Exchange Webservice
EMAIL_HOST	Exchange Webservice host (with https://...)
GP_EMAIL_[practice key]	GP practice recipient email address. See GP Email addresses for more info.
POSTCODE_API_KEY	Api key for getAddress.io
POSTCODE_API_HOST	Api host for getAddress.io

Services

Elasticsearch

The GP data stored in ElasticSsearch. We are using the ES search index for current GP lookup functionality.

Elasticsearch Updater

GP data changes updating by a elasticsearch-updater instance. We are not maintaining elasticsearch-updater repository. We just integrated the docker image to our infrastructure.

GP Email addresses

To keep the value of the recipient email address private they need to be stored in environment variables. Each GP email variable is made up of GP_EMAIL_ and a constant case of the key stored in practices.json.

Example:

peel-croft-surgery would be:

GP_EMAIL_PEEL_CROFT_SURGERY=email-address@domain.com

Tests

Unit tests

You can run the tests with the following:

$ yarn test

Acceptance tests

Acceptance tests are running through codecept.js and backed by Selenium.

Run tests Locally:

Installation on Linux or Mac:

./node_modules/.bin/selenium-standalone install

Running the tests on Linux or Mac:

Terminal session 1:

./node_modules/.bin/selenium-standalone start

Terminal session 2:

yarn test:acceptance_local

Run tests on Travis:

1. checkout branch acceptance-test.
2. Merge the changes/branch you want to test into branch acceptance-test this should start a Travis job.
3. In Travis click on build history and you should be able to see acceptance-test click on it to see Job log.

Production

$ yarn build && NODE_ENV=production yarn start

Contribute

Pull Requests

We use Github Flow. If you're in the organisation then just create a branch and create a pull request.

If you're outside of the organisation then we're not currently unsure how you'd assign the copyright of your contributions to the NHS. If you do have a significant contribution you'd like to make then talk to us first and we'll figure it out.

Architecture Decision Records

If you look in docs/architecture/decisions you'll see our Architecture Decision Records. Which is where we record large decision about the design of this project including the context around that decision.

Code Quality

Style Guide

Write code that matches our code style which is eslint:recommended plus 2 space indentation, always use semi-colons and single quotes for strings.

You can check your code conforms by running

$ yarn run lint:eslint

Coverage

We want to keep coverage high and our test suite does output a coverage summary. The build will fail if coverage drops below:

• 75% of statements
• 75% of lines
• 70% of functions
• 75% of statements

This is a low bar and we aim to increase it as we write more code.

You can see the coverage summary by running:

$ yarn test

it should look like:

File	% Stmts	% Branch	% Funcs	% Lines	Uncovered Lines
All files	77.59	50	82.35	77.59
client	100	100	100	100
webpack.config.babel.js	100	100	100	100
server	83.33	50	90	83.33
hello-world.js	100	100	100	100
index.js	80	50	87.5	80	... 115,122,131
server/plugins/nunjucks	66.67	50	66.67	66.67
index.js	66.67	50	66.67	66.67	... 26,27,28,29
server/plugins/static-files	100	100	100	100
index.js	100	100	100	100

Editorconfig

We have an .editorconfig which checks you're not leaving unnecessary spacing, strange indentation or missing new lines at the end of file.

You can probably get a plugin for your editor to tell you when you're breaking our rules. Alternatively you can run it manually:

$ yarn lint:editorconcfig

If you're code doesn't conform then the CI build will fail.

Continuous Integration

TravisCI

We are using TravisCI for our continuous integration, each commit triggers a CI build which runs all the tests and the linter. Travis build generating a dev docker instance and deploying to Rancher. You can reach the dev instance domain on Github pull-request page. The domain will appear bottom of the page after all build finished.

Check CI/CD workflow diagram here

TeamCity

We are using [Teamcity] to push the release to Staging and Production.

In Teamcity under Rancher Deployments > select register-with-a-gp-beta-web you will see three jobs

Promote Release to Staging
Promote Release to Production 
Promote Release to Production UKWest

Select the appropriate job. You will see the latest release you made in github. Select the desired release and click on Run on right side of the page.

License

Short version: MIT Long version: see LICENCE.txt

Small note: If editing the README, please conform to the standard-readme specification.

© Crown Copyright