Table of Contents |
---|
Preparation
...
Set up laptop
Set up accesses
Gmail
Slack + Slack channels
Jira
Github teams
Keepers
AWS to download prod backup
Sentry
Datadog
Create accounts in the staging environment and database
Environment Setup
Spordle Play uses a devcontainer which runs in VS Code and Docker. This helps keep development environments in sync and avoids clashing with anything else you’re working on.
The devcontainer is configured with docker-compose to automatically sets up an environment with containers for nodejs, Postgres, RabbitMQ, and Minio with the correct versions.
If you have these already installed, the container networking is configured to not conflict with existing ports and VS Code will automatically expose services to the next available port, while the standard ports are used within the devcontainer environment.
Windows
Install WSL2 Ubuntu from the Microsoft Store
https://apps.microsoft.com/store/detail/ubuntu-on-windows/9NBLGGH4MSV6Setup docker in WSL (Docker Desktop is not necessary if using above)
Enable systemd by updating
/etc/wsl.conf
to add:Code Block [boot] systemd=true
Install docker
Code Block sudo apt update sudo apt install docker.io -y sudo usermod -aG docker $USER
Restart WSL
Clone repository
Code Block cd ~ git clone git@github.com:Spordle/Play.git play
Open in VS Code
Code Block code ~/play
Relaunch in devcontainer
Check
README.md
for further instructions on how to install and build Spordle Play
macOS
TODO
...
different development environments
Play prod: deactivated
Play staging: account + db access
SID staging: account
Time tracking policy
Different confluence documents for Play
Show around codebase and explain the different core pieces and frameworks
Most important, React-Admin and Loopback
How we work
Play is a remote agile team that’s distributed across different cities, provinces and timezones, just like the users we build for.
To make this work effectively, we use agile sprints to keep ourselves organized and regular communication throughout the process is crucial.
Development guidelines
Branching is kept simple; there is no
develop
branch or any release branches, justmaster
. The golden rule is thatmaster
must always be in a production-ready state. 🚀Why? A code repository is meant for code, and continuous integration tools are meant for deployments and release management. While you can do a lot with git and branching, mixing these responsibilities creates a lot of unnecessary overhead and can provide a false sense of security for developers to merge incomplete work.
Play is a full-stack team working in a monorepo with JIRA stories designed to be completed within a single branch for all components (API, apps, etc). 🚄
The goal is to be able to review a single pull request and be able to checkout and test that branch easily. We want to be fully confident that a branch is ready to be merged and the story is able to be considered done so it can be shipped and we can move onto the next story.
Depending on the nature of the work, we may decide to gate functionality behind flags. This allows us to finely manage releases in the deployment process. 🚉
Some work inevitably needs to be done in stages, as we need to break up epics into more manageable stories. If it doesn’t make sense to expose something to users early on, or we only want to expose it in staging initially, flags are a useful tool to manage this.
When working on a story/branch, open a draft pull request early on! Once you’ve completed your work, you can mark the pull request as ready for review. 👀
Draft PRs provide opportunities for early and continuous feedback, and allows you to share what you’re working on with others to ask for help and collaborate together.
Agile process
Sprint planning
Before starting a sprint, we have a meeting to determine what everyone will be working on for the next two weeks.
We use planning poker for all developers to assign points to each story using a Fibonacci scale, which indicate the amount of effort (not time) that each story requires to develop
Developers are encouraged to have autonomy over the stories they choose from the backlog. This process is guided by the number of points they feel they can successfully deliver within the sprint timeframe and priorities set out by stakeholders as determined during other meetings
Daily standups
This is a 15 minute meeting for everyone to spend a couple of minutes each to share 1) what you worked on yesterday, 2) what you’re working on today, and 3) if you’re blocked on anything. This keeps everyone in sync and also provides visibility to everyone as to what the team is actively working on.
This should be a quick meeting to respect everyone’s time, so use it to coordinate more detailed meetings with anyone you need to solve your problems with.
Retrospectives
We continuously deploy our work and continuously improve our process. Retrospectives are an important step in the agile process to determine what works and what doesn’t work. Most importantly, this is a blameless process and faults no one as we seek to improve things for everyone
This is a meeting held at the end of each sprint
Sprint review
We have an internal review for developers after each sprint to keep everyone in sync and share what’s going on and share achievements. More eyes on each other’s work also often helps find issues before users do.
This process is a work in progress. While Spordle is still relatively new to agile, we will likely always consider this process to be a work in progress and flexible to change to adapt our changing needs.
Communication
Prefer using channels and groups over direct messages
Don’t hesitate to work and discuss in the open so that the team has an idea of what you’re working on and can also learn from what you’re doing
While communication in channels is encouraged, that also doesn’t mean participation from everyone is expected in every discussion
As we’re a distributed team, we default to asynchronous communication
This acknowledges that people may be tied up with something else at the moment or in another time zone and having lunch
Likewise don’t feel pressured to respond immediately when you see a message if you’re in the middle of something. If it’s an emergency the sender should make that clear.
It can also be more effective to start a quick huddle or Meet call, don’t hesitate to do so
Sometimes you need a quick response, or you find yourself going in circles in a chat, or you want to share a screen