Skip to content
TrekTrak Documentation

Software Development Process (SDP)

Principles

  • We are responsive with our asynchronous communication and answer within 24 hours.
  • A work item needs a motivation, technical description, dependencies, and acceptance criteria before anyone can work on it.
  • Project tasks should be of reasonable size, large tasks should be broken down into manageable and well-defined chunks
  • The backlog will always have work items ready for the next week at a minimum.
  • The Pull Request has to be reviewed by at least two team members before being merged.
  • We aim to evenly distribute the workload among all team members
  • We will meet weekly to discuss goals,questions, and connect with the project manager to go over progress and new needs.
  • Tracking task progress is done through GitHub projects, specifically our team Kanban board
  • Asynchronous communication on the project needs to take place on a dedicated Discord server
  • There are no “dumb” questions or ideas, and everyone is expected to communicate ideas to better serve the project and its purpose and avoid taking on parts of the project individually

Process

We are using a GitHub kanban board to keep track of team progress. We have well-defined tasks that can be moved from each of five stages:

  1. Backlog
  2. Ready
  3. In Progress
  4. In review
  5. Done

Our team works asynchronously due to busy schedules, and this type of development process will enable efficient work under these circumstances. If required, we can meet with team members to work together on tasks that correlate to each other. This also enables a quick standup meeting every week, because tasks are easily identifiable from a birds-eye view.

Work that needs to be done is placed in the backlog until it is defined enough to be deemed ready. When a task is completed, it will be reviewed by two team members and presented to the project’s stakeholders for feedback.

Roles

Design Responsible for the look and feel of the application and creating the initial designs for the front end. The Frontend developers will try their best to replicate these designs as closely as possible.
Frontend Responsible for writing the code that drives the client-side portion of the application. This includes efficient communication with the backend, proper data caching techniques, and ensuring that end-user data is correctly handled and not lost.
Backend Responsible for writing the code that drives the server-side portion of the application. This includes handling connections made from client-side code, proper handling and cold-storing of application information, and ensuring that end-user data is secure and accessible where needed.
Scrum Master Responsible for facilitating the communication and collaboration between team members. Also ensures the the scrum framework is being followed so that the project runs smoothly

As we continue with the project timeline, roles could be switched between the team until a unique strongpoint is discovered by each member. Although the work will be different, tasks should be evenly distributed in terms of difficulty.

Currently, our roles are:

Role Members
1. Scrum Master
  • Alex Ulbrich
2. Back-office Frontend Team
  • Edson
  • Ryan
  • Jason
3. Mobile Frontend Team
  • Stephen
  • Aidan
  • Yang
  • Lei
4. Backend Team
  • Stephen
5. Design Team
  • Lei

Tooling

Version Control GitHub
Project Management GitHub Issues and Projects
Documentation Starlight, Google Docs, GitHub README
Test Framework TBD
Linting and Formatting Prettier
CI/CD GitHub Actions
IDE Visual Studio Code
Graphic Design Figma
Others Google, StackOverflow, AI tools (Bard, ChatGPT, etc.)

Definition of Done (DoD)

  • Acceptance criteria are validated
  • Changes are reviewed by at least 2 members on the team
  • Changes are merged (to main branch)
  • Unit and integration tests are successful and meet all requirements
  • Changes are implemented in the frontend, backend, database
  • Limited or at best, zero regressions
  • Documentation is updated
  • Release notes are updated
  • Breaking changes are evaluated/avoided
  • Changes are deployed to staging
  • Demo is prepared for next stakeholder meeting
  • Tasks are moved from “To-Do” section to “Done”

Release Cycle

  • Merges to the main branch will automatically produce staging builds
  • Merges deemed as a new release will deploy to production for end-users to interact with
  • Aim for 1 or 2 new releases per month
  • Use semantic versioning MAJOR.minor.patch
    • Increment the minor version for new features
    • Increment the patch version for bug fixes
    • Increment the major version for breaking API changes

Until the API is stable, major should be 0.

Environments

Environment Infrastructure Deployment What is it for? Monitoring
Production Supabase (Backend) + Vercel (Web Frontend) + App Stores (Google Play Store or App Store; Mobile Frontend) Release For production of features and application N/A (Tools are provided by Supabase / Vercel)
Staging (Test) Local, similar to Dev PR Initial testing for selected users N/A (Tools are provided by Supabase)
Dev Local (MacOS, Windows, iOS, Android) + Docker-ized Services (Backend) Commits Development of application and feature updates N/A (Tools are provided by Supabase)