Page Comparison

...

Windows

1. Install WSL2 from the Microsoft Store. Use 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. https://apps.microsoft.com/store/detail/ubuntu-on-windows/9NBLGGH4MSV6 Setup docker in WSL. Docker Desktop is not necessary if using above.

   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

   Restart WSL (via cmd)

3. Clone the Play repository

   Code Block

   wsl --shutdown

   Clone 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! 🎉

...

• 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 release management. While you can get creative with do a lot with git and branching, mixing these responsibilities creates a lot of unnecessary overhead and provides 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 big thingstory.

• 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 a feature 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 developmentyour work, you can mark it the pull request as ready for review. 👀

  • This provides Draft PRs provide opportunities for early and continuous feedback on your work, or , and allows you to share code what you’re working on with others to ask for help and collaborate together.