laa-review-criminal-legal-aid

A service to review criminal legal aid applications.
This service is the case-worker side of Apply for criminal legal aid.

Getting Started

Clone the repository, and follow these steps in order.
The instructions assume you have Homebrew installed in your machine, as well as use some ruby version manager, usually rbenv. If not, please install all this first.

1. Pre-requirements

• brew bundle
• gem install bundler
• bundle install

2. Configuration

• Copy .env.development to .env.development.local and modify with suitable values for your local machine
• Copy .env.test to .env.test.local and modify with suitable values for your local machine

After you've defined your DB configuration in the above files, run the following:

• bin/rails db:prepare (for the development database)
• RAILS_ENV=test bin/rails db:prepare (for the test database)

3. GOV.UK Frontend (styles, javascript and other assets)

• yarn

4. Run the app locally

Once all the above is done, you should be able to run the application as follows:

a) bin/dev - will run foreman, spawning a rails server and dartsass:watch to process SCSS files and watch for any changes.
b) rails server - will only run the rails server, usually fine if you are not making changes to the CSS.

You can also compile assets manually with rails dartsass:build at any time, and just run the rails server, without foreman.

If you ever feel something is not right with the CSS or JS, run rails assets:clobber to purge the local cache.

5. Authenticating a user locally

After clicking "Sign in," you will be shown a list of all users in the local database. Select one to sign in as that user.

To add users, select a user that can manage others and use the user management interface. A seed admin user is created by default (run bundle exec rails db:seed if none are listed). To ensure that the user's name is set correctly on first authorisation, use the format "Firstname.Lastname@example.com."

The last user in the list is "Not.Authorised@example.com." Select this user to simulate a non-authorised authenticated user.

This authentication strategy can be disabled locally by setting DEV_AUTH_ENABLED=false

NOTE: The dev_auth authentication strategy has been enabled for local development and docker-compose by setting DEV_AUTH_ENABLED=true and IS_LOCAL_DOCKER_ENV=true. This must never be enabled in the live (staging/production) service in it's current form as it will expose sensitive information.

Local development with the temporary API gem

The app utilises puma-dev for local development.

Follow the setup proceedure for puma-dev outlined here

Clone apply, and the laa-crime-apply-dev-api locally.

Point the dev gem in apply's gemfile to your local laa-crime-apply-dev-api repo:

gem 'laa_crime_apply_dev_api', path: '../laa-crime-apply-dev-api'

Ensure that you have a ~/.puma-dev/ dir set up which contains symlinks to you local Apply and Review repos (instructions)

You should now be able to access apply and review at the following convenience URLs:

http://laa-review-criminal-legal-aid.test/

http://laa-apply-for-criminal-legal-aid.test/

## Access dev api (as defined in the gem)
http://laa-apply-for-criminal-legal-aid.test/api/applications
http://laa-apply-for-criminal-legal-aid.test/api/applications/<application-id>

Running the tests

You can run all the code linters and tests with:

• rake

The tasks run by default when using rake, are defined in the Rakefile.

Or you can run them individually:

• rake spec
• rake erblint
• rake rubocop
• rake brakeman

Docker

The application can be run inside a docker container. This will take care of the ruby environment, postgres database and any other dependency for you, without having to configure anything in your machine.

• docker-compose up

The application will be run in "production" mode, so will be as accurate as possible to the real production environment.

NOTE: never use docker-compose for a real production environment. This is only provided to test a local container. The actual docker images used in the cluster are built as part of the deploy pipeline.

Feature Flags

Feature flags can be set so that functionality can be enabled and disabled depending on the environment that the application is running in.

Set a new feature flag in the config/settings.yml under the heading feature_flags like so:

# config/settings.yml
feature_flags:
  your_new_feature:
    local: true
    staging: true
    production: false

To check if a feature is enabled / disabled and run code accordingly, use:

FeatureFlags.your_new_feature.enabled?
FeatureFlags.your_new_feature.disabled?

Kubernetes deployment

To provision infrastructure

AWS infrastructure is created by Cloud Platforms via PR to their repository.
Read how to connect the cluster.

Namespaces for this service:

• staging namespace
• production namespace

Encode secrets in Base64

When dealing with secrets, they need to be encoded in Base64, do not use online services for this.

# Encode:
echo -n "new-string" | base64

# Decode:
echo "bmV3LXN0cmluZw==" | base64 --decode

The secrets.yml manifest files are git-crypted so we can commit these to the repository. Follow the instructions on how to setup git-crypt locally and ask any existing collaborator to add your GPG key to the repo to be able to read/write secrets.

In the deploy pipeline we use a symmetric key exported as a repository secret GIT_CRYPT_KEY and a github action to unlock the secrets and apply them automatically as part of each deploy.

Applying the configuration

Configuration is applied automatically as part of each deploy. You can also apply configuration manually, for example:

kubectl apply -f config/kubernetes/staging/ingress.yml

Continuous integration and delivery

The application is setup to trigger tests on every pull request and, in addition, to build and release to staging automatically on merge to main branch. Release to production will need to be approved manually.

All this is done through github actions.

The secrets needed for these actions are created automatically as part of the terraforming. You can read more about it in this document.

Architectural decision records

ADRs are in the ./docs/architectural-decisions/ folder will hold markdown documents that record Architectural decision records (ARDs) for the LAA Review Criminal Legal Aid applications.

Please install ADRs Tools (brew install adr-tools) to help manage the creation of new ADR documents.

To create a new ADR

After installing ADR tools use:

adr new <your ADR title>

This will initialise new blank ADR with your title as a heading and increment the ARD prefix to the correct number on the ARDs file name.

Further info

For information on what ARDs are see here.