...

1. Install WSL2 from the Microsoft Store and VS Code. You don’t need anything else! ✨

   • Docker Desktop is not necessary if you have WSL2 version 0.67.6 or higher (check wsl --version)

2. Setup docker in WSL

   1. Enable systemd by updating /etc/wsl.conf to add:

      Code Block
      [boot] systemd=true

   2. Restart WSL (via cmd)

      Code Block
      language bash
      wsl --shutdown

   3. Install docker

      Code Block
      language bash
      sudo apt update sudo apt install docker.io -y sudo usermod -aG docker $USER

3. Clone the Play repository

   Code Block
   language bash
   cd ~ git clone git@github.com:Spordle/Play.git play

4. Open it in VS Code

   Code Block
   language bash
   code ~/play

5. Relaunch in the devcontainer

   • You’ll see a notification in the bottom-right corner suggesting this

   • You can also relaunch via the Ctrl-P menu by searching for ‘dev containers’

   • This might take some time as it’s pulling and building a few docker images for the first time

6. Check README.md for further instructions on how to install and build Spordle Play

7. Create a branch and open your first pull request! 🎉

macOS

...

...

Development guidelines

• Branching is kept simple; there is no develop branch or any release branches, just master. The golden rule is that master 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 provides 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

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 organised and regular communication throughout the process is critical.

• Daily standups

  • This is a quick opportunity to share what you’re up to, flag any blockers, and ask for help. This keeps everyone in sync and also provides visibility to everyone as to what the team is actively working on.

  • Since we’re distributed across timezones, we use a daily Slack thread for async updates instead of having a meeting later in the day

• Sprint planning

  • At the start of each sprint, we have a meeting to determine what everyone will be working on for the next two weeks from the backlog

• 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

  • We hold a formal meeting at the end of each sprint and an quick informal one midway through the sprint as a healthcheck

• Sprint review

  • This is a meeting near the end of each sprint to showcase our work to stakeholders and gather some feedback to make sure business and developers are still in sync

• Backlog refinement

  • Prior to sprint planning, we need to review the backlog to ensure stories are still relevant, give us an idea of what’s coming, and determine the amount of effort stories will take by assigning points to each story will take so we know how much we can assign during a planning session