📝
How will you approach this project as a team?
🫱🏽🫲🏾 Setup project teams
This is a project you will build in a team. First form your team, then start the project by forking the repo.
1. Form your team
- Split into teams of 3 or 4. Use a random team generator.
- Get together with your team during class day and agree on your way of working for this project.
2. Agree your Way of working
This is the most successful strategy
- Create a temporary Slack channel for your team. Use this channel and your class time for communication about the project management and the product development.
- Each team member must understand the requirements of a ticket before moving it from the Backlog to Ready. Make use of your class time to discuss the tickets as a team.
- Decide whether you are going to work on tickets individually or as a pair. You may work faster on your own but may learn more as a pair.
- Each feature must be reviewed by another member of your team . Set a branch protection rule on your main branch to enforce this.
- Each team member can pick up a new ticket only when their old ticket is in review. Work on one thing at a time.
3. Set up the repo
- One person should fork the project repo to their own GitHub account.
- Add the other team members as collaborators to the repo.
- Now someone else should make a copy of the example planner and link it to your project repo.
- All the tickets for your project are created as issues in this repo. Batch clone the tickets into your project planner.
On your branch protection settings:
Require a pull request before merging. When this is enabled, all commits must be made to a non-protected branch and submitted via a pull request before they can be merged into a branch that matches this rule.
Require approvals: 1. When this is enabled, pull requests targeting a matching branch require a number of approvals and no changes requested before they can be merged.
Building your product 🔗
Git workflow
You will use a feature branch workflow for this project. This means that you will create a new branch for each ticket you work on. When you are done with the ticket, you will open a PR and your team will review your work. Once approved, you will merge the branch into main.
You should be familiar with this workflow by now. Let’s put it to the test by working on many different components at the same time, in a real Agile team.
Components
Make your components in the src/components folder. Organize your components into sub-folders and keep everything tidy. There are examples given for you to follow.
Styling
There’s a starter stylesheet set up. It uses sass, which is a way of writing complicated CSS more easily. You can write plain CSS in any .scss file, so you don’t have to learn SASS to do this project. (But you might want to learn it anyway, because it’s awesome.)
If you don’t like these styles, you can replace them with your own. You can also use pre-made stylesheets from Tailwind, Bootstrap, or any other CSS framework you like. But focus on the functionality first, and worry about the styling later.
Test driven development 🔗
Tests
The test runner is called Vitest and it’s set up to run tests in the src folder. You can add more tests in the src folder and they will be picked up by Vitest, so long as you name them with the .test.jsx extension. Make sure to use the .jsx extension, not .js.
You can write tests using the same Jest syntax you have already learned in these files.
The React Testing Library is also available in the tests, and the docs are a great resource for learning how to use it.
You will need to write a test for each component you build. Write the test first, based on the requirements given in the ticket. Then write the component to make the test pass.
There are some examples given to help you. Come to class with questions about how to write tests.
Shipping your product 🔗
Deploying your site
Your site must be deployed and the link shared. You can use Netlify. If you would like to explore other deployment options, make a ticket on your board and plan it out.