This documentation is intended for internal use by the RE team.

Development & Release Processes

Development processes

There is currently no single development process within RE. The processes to use largely comes down to the programme where the repository originated, and for new repositories, the programme from which the initial contributors to the new repository moved from.

Extract from the PaaS team manual -

For our wider cultural practices, see the GDS It’s OK poster. For instance it’s okay to ask for help, it’s okay to have quiet days, and many other things.

Using git

Ensure that you are using your GDS email address as the user for any RE git repositories - and set it as the primary email address for alphagov in github settings.

The GOV.UK Styleguide for git contains useful information about using git.

Commit message format

Refer to the GOV.UK Styleguide for examples of how commit messages should be formatted.

Note: Verify uses/expects the Co-authored-by: tag in commit messages when the work has been paired on/mobbed so that github can link those commits to the correct users.

GDS Way code review guidelines

The GDS Way contains guidelines about how to review code

The GOV.UK, Pay, Registers & Verify development processes

The processes for GOV.UK, Pay, Registers & Verify are now very similar - the main difference being the required number of approvers for Verify. The number of approvers required is technically enforced by github.

The GOV.UK development process is documented in the GOV.UK Styleguide

The Verify development process is documented as an RFC in the Verify Architecture repo

The Pay development process is documented in the Pay Team Manual but it defers to the GOV.UK process.

Registers has an automatic template that is used when a PR is created.

The Run/PaaS development process

This is documented in the PaaS Team Manual

The Digital Marketplace process

This is documented in the Digital Marketplace manual

Others?

Raise a PR and add missing content here

Development principles

These are some principles that may be useful to keep in mind when developing our services.

Definition of done

Having a shared understanding of when something is “done” within a team can have two benefits:

• estimates of effort for completing user stories may be more accurate and uniform across members of the team

• it can be used as a checklist to make sure every step of the work is completed

In general, we tend to under-estimate effort as we often focus our attention mostly on the implementation step. Thus, it is helpful to think about all the many other steps around it.

Here we assume user research and high-level planning have been already conducted and there is a well-defined user story ready to be “played” by an engineer or designer.

The definition of done is likely to vary depending on the phase the project is at (e.g. alpha vs beta) and on the peculiarities of the project itself.

However, the following can be a good starting point:

• the person/pair working on the story (owner) has formulated a plan on how to implement the story
• the story has been kicked-off with the team (if the story is a complex one)
• the story has clear and verifiable acceptance criteria, validated at the kickoff
• all concerns or questions raised during kick-off have been addressed
• the owner of the story work on the implementation
• the implementation has been tested
• any issue following the testing has been addressed
• any relevant documentation has been created
• the story owner(s) raises a PR(s)
• another member of the team review that PR(s)
• any comment from that review gets addressed
• the owner merges the PR to master
• all the automated tests (e.g. accessibility, integration, performance, …) pass
• the work has been validated against the acceptance criteria by another team member
• the change has been released to all relevant environments and everything looks fine
• Show and Tell (optional)
• Done!

Release processes

Raise a PR and add missing content here