How We Work
Our Slack Channels
Our Team Channel
This channel is used for internal team discussions, queries, support and PR reviews. Team members can use this channel for any blockers, raising issues and knowledge sharing.
Public Support Channels
Platform Operations currently covers services for DSO and Probations. Queries related to these services can be posted on the relevant channel for a PlatOps team member to look into. Please read the channel descriptions for more information on how to use.
- #ask-digital-studio-ops - for DSO support queries and access requests
- #ask-probation-hosting - for Probation support queries and access requests
For information on the Platform Operations Support model, please see the Platform Operations Support Role page.
Sprints & Ceremonies
We operate on a two-week sprint cycle, using Jira to manage and track our work. Our regular agile ceremonies help keep the team aligned, accountable, and continuously improving
Sprint Cadence
- Sprint Length: 2 weeks
- Sprint Kickoff: Held at the beginning of each sprint to align the team on sprint goals
- Sprint Planning: Session to estimate work, establish capacity, and commit to which tickets enter the upcoming sprint
- Retrospective: Held at the end of every two sprints (monthly) prior to starting the next sprint, allowing the team to reflect on what went well and where we can improve
Daily Standup
- Timing: Held daily at the start of the day (09:45) for 15 minutes.
- Format:
- The facilitator shares the Jira board.
- Team members, starting with who was on support rota the previos day, take turns walking through:
- What they completed yesterday / have been working on
- What they plan to work on today
- Any blockers standing in their way
- Any remaining time after round-robin updates is used to dive deeper into blockers or quick technical alignments.
Jira Board & Tickets
Our Jira board is used to track current sprint tickets, backlog priorities and epics.
Writing Stories
What makes a good story?
A good story should contain the following:
- Summary: A brief summary that outlines what the ticket aims to achieve, and why
- Description: A more detailed description of the work to be done
- Acceptance Criteria: The criteria that needs to be met for the task to be considered “done”
- Engineering Steps: What steps the engineer needs to make to implement the changes
- Documentation Links: documents in Confluence, for example, that include guidance on how to complete the task, or aspects of the task
As an example, assume that we have a task to grant access to the CIDR range X.X.X.X/32 for one of our projects in AWS:
Summary
As a Platform Operations Engineer
I want to add an ingress rule to Security Group X within AWS Account Y
So that I can grant access to users within the X.X.X.X/32 range
Description
We need to grant access to users within the CIDR range X.X.X.X/32 for project Y, so that they can gain access to the application. We will need to make this change via Terraform, and receive confirmation from the users that they can access the application as expected.
(And then provide any other relevant information, e.g. documentation links, screenshots, previous tickets, repositories etc)
Acceptance Criteria
- Security Group X within AWS Account Y is updated via Terraform (to grant access to X.X.X.X/32)
- Users within the CIDR range X.X.X.X/32 confirm that they can access the application as expected
Engineering Steps
- Locate the security group module in this repo
- Add a new ingress rule permitting port traffic for CIDR range
- Run ‘terraform plan’ locally to verify changes and review the diff etc.
Documentation Links
Add any links to documentation that will help in completing this story
Story Points
Story points are allocated to our JIRA tickets, and are used to measure the effort/complexity of each task:
| Story Points | Definition |
|---|---|
| 1 | I know exactly the code I would write if I went back to my desk right now, there is no significant testing required (Example: Simple config change, adding a user etc) |
| 2 | I know what is required, and there are existing examples to rely on. I have done something previously in this area (Example: Straightforward Deployment) |
| 3 | I will probably have to look a few things up, and maybe consult others. There are some unknowns going in, and any changes will have to be tested |
| 5 | I only have a vague idea of how to do this, some unknowns may appear that could take more time. Requires significant testing, co-ordination and review. There are several components being changed - but this should be achievable within a sprint |
| 8 | Someone who knows this domain better should split this up into discrete stories that deliver values incrementally |
Reviews & PRs
All changes should be raised through a Pull Request (PR) and reviewed by another engineer before being merged
Raising a Pull Request
The engineer making the change should:
- Create a PR with a clear description of the change and why it is required - a link to the ticket it relates to is helpful
- Ensure the PR contains all relevant changes and does not include unrelated modifications
- Request a review in the #internal-platform-operations Slack channel.
- Include a link to the PR in the Slack request
Reviewing a Pull Request
The reviewer should review the PR to ensure that:
- The change addresses the stated requirement or issue
- The implementation is correct and follows existing patterns and standard
- The change is appropriately scoped and does not contain unrelated changes
- Configuration, infrastructure, or application changes are safe and appropriate
- There are no obvious security concerns or unintended access changes
- Naming, formatting, and documentation follow the conventions of the repository
- Tests or validation have been completed where appropriate
- Any relevant deployment, rollback, or operational considerations have been considered
- The PR description provides enough context to understand the change
If changes are required, the reviewer should leave clear comments on the PR. The requester should address the feedback and request another review where necessary.
Approval and Merge
Once the reviewer is satisfied with the changes, they should approve the PR.
The requester is responsible for monitoring the PR and, once the required approval has been received and any checks have passed, merging the PR in a timely manner.
The requester should not leave approved PRs unnecessarily open, as this can delay delivery and leave changes in an incomplete state
Support Rota
For information on the Platform Operations Support model, please see the Platform Operations Support Role page.
Want to add a new page?
Assuming that you are part of the Platform Operations Github Team, you can add a new page to this repository by:
- Creating a new
filename.html.md.erbfile within the source directory - Raising a pull request and getting a team member to review it (this is usually best achieved by reaching out in the internal team channel as listed towards the top of this document)
- Once you have merged the pull request, monitor the publish github action
Once the Github Action has passed successfully, you should be able to see your page live on the Platform Operations Runbooks site.
Please ensure your file contains the following at the top:
---
title: <The title of your page>
weight: <A number to determine the order of your page in the left-hand navigation panel>
last_reviewed_on: <When the page was last reviewed, in YYYY-MM-DD format>
review_in: x months ## How often the page should be reviewed, in months
---
<%= current_page.data.title %>