Guidelines for accessing production data and systems

General Principles

Pairing

When working in the production environment, or carrying out a task that will affect users directly (eg. using Jenkins to send framework emails ) for the first time, you should pair with another developer. You should also pair with another developer the first time you’re on 2nd line support.

Even if you’re doing a task that you’ve done before, pairing is still encouraged to share knowledge within the team and get a second pair of eyes on user-facing changes.

Document a plan

Writing a plan and sharing with the team is always a good way of getting feedback, especially if you’re working on something complex. This could be a DRD or RFC recorded in Google Drive that’s shared with the whole team for comment, but you could also create a script to carry out a task and ask another developer to review it through the usual PR review process on Github.

Writing down the steps you plan to take also often helps to reveal bugs in the process before they occur.

On the Digital Marketplace

Production database

Warning

Only log in to the the production database as a last resort. The vast majority of 2nd line tickets, investigations and fixes can be done through the API instead. Using the API ensures a clear audit trail of changes which is vital to CCS if a buyer or supplier were to issue a legal challenge.

Whenever you log in to the production database you must always pair with another developer. You should also alert the team in the 2nd line Slack channel before logging in.

API read-only mode

We are often asked to look up information about suppliers, users or services as part of a 2nd line request, all of which can be done through the production API. In order to minimise the risk of making unwanted changes it’s safer to start the API client shell in read-only mode , do your investigation and only start a new client shell with full permissions once you know exactly what needs to be changed.