A Slack app built as an Azure (durable) Functions App for communicating with the cache-flush function app.

• Install the appropriate version of Azure Functions Core Tools version 2.x for your development platform of choice
• Clone the repository - git clone https://github.com/nhsuk/cache-flush-slack-app.git
• Install npm dependencies - npm install
• Rename example.local.settings.json to local.settings.json. Edit the file to include valid values.

• Start the Function app - func start

The Slack app is configured to use Interactive Components and Slash Commands. The lifecycle of the application starts with a user initiating a request with a slash command. The details of the command can vary but the Request URL must be set to the endpoint /api/slash-start (this can be changed easily within both the Slack app and the Function app).

When the application receives the slash command request it will respond with a modal view. The lifecycle of the modal is handled by the Function app. The Request URL must be set to the endpoint /api/orchestrator-client (this can be changed easily within both the Slack app and the Function app).

Submitting the request to flush the URLs from the cache in the modal initiates a request to the cache-flush app. The request is likely to take several seconds (and may take 10-20 seconds depending on the state of the APIs i.e. whether they are running hot or cold). When the response is received it will be displayed within the modal view (if it is still open) and a direct message will be sent to the user.

Deployments to all environments are fully automated and are tested to confirm the deployment has been successful as part of the deployment process. Therefore, if the deployment job succeeds you can be confident the application is working.

Deployments are configured via azure-pipelines.yml and run within the nhsuk.utilities project. The pipeline is not public. In order to view it a login is required. The deployed applications are protected using the standard function app authorisation mechanism i.e. authorization keys. The keys are maintained as secrets to prevent abuse and unwanted use.

Review environments are deployed for every PR and are available at https://nhsuk-cache-flush-slack-app-func-dev-uks-pr-<PR_NUMBER>.azurewebsites.net/. When a PR is merged into master the review environment will be deleted.

Merges to master generate a deployment to the integration environment.

The creation of a release generates a deployment to the staging environment.

Deployments to production are only possible if the change has been deployed to the staging environment. The deployment to production must be approved. Using approvals enables a pause between the deployment to staging and the deployment to production. It is often necessary to seek a sign-off prior to deploying to production and this setup allows that to happen.

Environment variables are expected to be managed by the environment in which the application is being run. This is best practice as described by twelve-factor. Environment variables are stored in an instance of HashiCorp Vault and retrieved by running ./scripts/get-variables-from-vault.sh.

The script requires the following environment variables to run successfully. The script will validate the existence of the variables before making a request to Vault. There are no default values and they all must have a value set.

The following environment variables are required for the application to run successfully. There are no default values and they all must have a value set.

During deployment of the application additional environment variables are retrieved from Vault. They define the details of where the application will be deployed within Azure.

The variables vary for each environment. There are no default values and they all must have a value set.

1. allowed-users.csv is a CSV file containing a list of allowed users. Each record consists of a user_id aka a member_id. The user_id must be in the first column for it be to recognised by the application as an entry. The second column should contain the name of the person to make it easy to see which users are included within the file. The name of the user is arbitrary, however, the suggested format is firstname_lastname e.g. steve_hunt.

This repo uses Architecture Decision Records to record architectural decisions for this project. They are stored in doc/adr.