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