Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Preparation

Environment setup

Spordle Play uses a devcontainer based environment which runs in Docker through VS Code. This helps keep developer environments in sync and reproducible, and avoids clashing with anything else you’re working on if you’re working on other projects.

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. Compose creates an internal network that allows containers to communicate with each other using their container names, which is useful to know for your app container.

If you have any of these services already installed, the container networking won’t 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

  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:

      [boot]
      systemd=true
    2. Restart WSL (via cmd)

      wsl --shutdown
    3. Install docker

      sudo apt update
      sudo apt install docker.io -y
      sudo usermod -aG docker $USER
  3. Clone the Play repository

    cd ~
    git clone git@github.com:Spordle/Play.git play
  4. Open it in VS Code

    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

TODO

Likely similar instructions above, but with Docker Desktop.

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 release management. While you can 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 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.

  • No labels