RELEASE.md

Delivery workflow

We use 10 swim lanes on the Jira board.

1. Sprint Backlog/Ready for development

• meets definition of ready

2. Development

• active local development
• push to remote; the branch name must start with a ticket number, for example ER-xxx
• mark PR as draft and summarise deliverable
• associate to release candidate milestone

3. Blocked

• stalled or parked
• label PR as blocked

4. Developer Peer Review

• ER-### branch
• feature deployments
• meets definition of done
• mark PR as ready and request review
• once approved move ticket to #5

5. Ready for QA

6. In Test QA (Quality Assurance)

We do not have review applications in HfEYP, so QA can either take place after merged in development or in staging. If you'd like to see the PR on the development instance before merging, you can deploy from that branch.

• seek business analyst sign-off
• confirm the acceptance criteria
• label PR as pass or fail
• once passed merge to main branch and move ticket to #6

7. Integration testing

• development deployment
• main branch
• https://hfeyp-dev.azurewebsites.net
• update accessibility and quality checks as required

8. Approval PO (Product owner)

• staging deployment
• rcx.x.x release candidate tag
• https://staging.help-for-early-years-providers.education.gov.uk
• open milestones (release candidates)
• seek product owner sign-off

9. Release

• production deployment
• vx.x.x version tag
• https://help-for-early-years-providers.education.gov.uk
• close milestone and rename from rc to v
• periodically publish a release CHANGELOG

9. Done - Live

• post release tasks

Definition of Ready

• description is clear and unambiguous
• acceptance criteria are present and understood
• ticket is estimated to be deliverable within a single sprint

Definition of Done

• meets acceptance criteria
• includes appropriate documentation
• includes unit and feature tests
• maintains minimum coverage
• review app deployed
• deployment tested by the author

GitHub labels

Github PRs use descriptive labels, most of which are applied automatically.

1. adr, Architectural Design Record.
2. dependencies, Pull requests that update a dependency file.
3. documentation, Improvements or additions to documentation.
4. frontend, Changes to assets detected.
5. pipeline, Github workflow changes.
6. ruby, Pull requests that update Ruby code.
7. terraform, Changes to Terraform detected..

Manual labels:

1. blocked, Currently blocked.
2. review, Review app deployed for testing.
3. bug, Squashes a bug.
4. pass, Acceptance criteria met.
5. fail, Acceptance criteria NOT met.

Application state

• Rails.application.live? returns true if deployed as a final release to our public facing workspace.
• Rails.application.staging? returns true if running in staging
• Rails.application.development? returns true if running in development

Dependencies

Application libraries and workflow actions are monitored by Dependabot.

---