team03 : Team Project: FrontEnd CRUD, part 1: Index Page, and Delete Column

num ready? description assigned MW lect due MW lect assigned TR lect due TR lect
team03 true Team Project: FrontEnd CRUD, part 1: Index Page, and Delete Column Wed 11/02 05:00PM Thu 11/10 11:59PM

Set up tasks for lab on Wednesday 11/02

You should have six team members, and there a six setup tasks to do. So ideally, you’d divide these up one per person.

But, if you have fewer than six team members present today, I suggest you still try to get all six of these done with the team members you do have.

Note that there is an order here, so keep that in mind when organizing tasks:

Big Picture: what is team03 all about?

From a high-level standpoint, you’ll be doing these things:

Coding Tasks:

Set up Tasks

There are several set up tasks. I suggest that you divide these up among your team, and indicate on the team slack channel who is doing what.

Here’s the full list, followed by more detail about each one (in the dropdown boxes indicated by the triangles; click the triangle (▶) to reveal the steps for each one.

Ideally, if you have six team members available to help out, each team member will do one of these. If you have fewer than six team members available, I suggest combining either (3,4) or (5,6) since they are quite similar, and can easily be done quickly by the same person.

Setup Task 1: Creating your team’s Kanban board

  1. Make sure you are the only person creating a Kanban board for your team

    • Tell the rest of the team (via your Slack channel) that you are setting up the Kanban board (so that you don’t have two folks doing it at the same time.)

    • Before you do, make sure that someone else didn’t already post that they were creating the Kanban board for the team. And wait a few seconds to be sure that there isn’t someone else typing in that they are doing it at the exact same time.

    • If your entire team is in meeting person, you can also just check in with them in person.

  2. Go to this URL: https://github.com/orgs/ucsb-cs156-f22/projects

  3. Click “Add Project”. In the modal that pops up, select “New Board”. (If you accidentally create a table, you can convert it to a Board later.)

  4. Name your project team03-f22-6pm-3 (substitue your team name)

  5. Then, share your project with your team. You don’t need to share it one person at a time; you can just share it with the team name (e.g. f22-5pm-3) and give them Admin access.

  6. Add a column for “In Review” to the three default columns, and drag it to the proper spot.

  7. At the top of your team’s slack channel, pin a link to your Team03 Kanban board: That process looks like this:

cs156-copy-kanban-link

Setup Task 2: Populating team03 repo with starter code

One team member should clone the team03 repo, which should be found here:

Section 1 2 3 4
5pm team03-f22-5pm-1 team03-f22-5pm-2 team03-f22-5pm-3 team03-f22-5pm-4
6pm team03-f22-6pm-1 team03-f22-6pm-2 team03-f22-6pm-3 team03-f22-6pm-4
7pm team03-f22-7pm-1 team03-f22-7pm-2 team03-f22-7pm-3 team03-f22-7pm-4

Steps (illustrated below)

Explanation Command
(1) Add the starter code repo (git@github.com:ucsb-cs156-f22/STARTER-team03.git) as a remote git remote add starter git@github.com:ucsb-cs156-f22/STARTER-team03.git
(2) Checkout branch main locally git checkout -b main
(3) Pull from the main branch of the starter git pull starter main
(4) Push to the main branch of your repo git push origin main

That should establish the main branch of your repo so that everyone on the team can then clone it and use it as a starting point.

Setup Task 3: Set up -docs and -docs-qa repos (must be done after 2)

This task has three parts:

  • Part 1: Enable Actions, Set up DOCS_TOKEN, Run job to create -docs and docs-qa repos
  • Part 2: Give whole team admin access to -docs and -docs-qa repos, and enable GitHub pages
  • Part 3: Run jobs to set up Storybook, and adjust links in README.md

Part 1: Enable Actions, Set up DOCS_TOKEN, Run job to create -docs and docs-qa repos

In this task, you’ll set up a GitHub Pages site for documentation of your code base; for now, that just consists of the published Storybook, which is an interactive catalog of all of your React components.

To do this, follow these steps:

  1. Go to the Actions tab of your repo, and if Actions is not already enabled, enable it.

  2. Go to the settings page for your personal GitHub account, like this:

    image

  3. Find the Developer Settings in the left navigation, near the bottom.

    image

  4. On the developer settings, choose Personal Access Token image

  5. Click Generate New Token. You’ll need to confirm your password. image

  6. Fill in the description with your team03 repo name (like shown below). Note that the description is just for humans, so the formatting doesn’t have to be exact. This is just so you can remember what the token is for.

    Select 90 days for the expiration, and then select repo as the only scope (it includes all the detailed scopes underneath).

    image

    Finally, scroll down and click Generate Token.

    image

    You’ll be shown a token value (this one is fake and has been deactivated). Copy it, because once you close the window it’s gone, but DO NOT PASTE IT ANYWHERE except in the secrets portion of your team03 repo (next step). This value can be used in place of your GitHub password, so you need to protect it.

    image

  7. Return to your main team03 repo, and go to Settings page for Secrets: Actions (This is done on the regular team03-f22-4pm-1 repo, NOT on the -docs and -docs-qa repos.)

    image

    On the Secrets page click New Repository Secret then add a secret called DOCS_TOKEN. Be careful here, because the name must be exactly DOCS_TOKEN, not DOC_TOKEN or anything else; this value is referenced in the GitHub workflow scripts.

    image

    After you are done, it should look like this:

    image

    If you need to replace the secret (e.g. for debugging reason), you can overwrite it, but once you store it, you can’t look at it. So if you get it wrong, you just have to create a new one; you can’t edit the old value.

  8. Now, once DOCS_TOKEN is updated, and till in your main team03 repo, and go to the page for GitHub Actions (the Actions tab). You should see these workflows in the list on the left:

    image

    00-publish-docs-to-github-pages-setup: set up -docs and -docs-qa repos (run once, manually)

    This should automatically create the repos with -docs and -docs-qa that will host your React Storybook.

  9. Wait for that jobs to finish, and verify that your -docs and -docs-qa repos have been created.

Part 2: Give whole team admin access to -docs and -docs-qa repos, and enable GitHub pages

Go through all of the steps below for both the -docs and the -docs-qa repos.

  1. Visit the Settings page for the repo

  2. Visit the Collaborators and Teams link (second on left navivation) image

  3. You should see your own GitHub (the one of the person that created the repo) in the list of folks with access. You should click the Add Team button (upper right) to add your entire team:

    image

    You’ll see this pop-up modal:

    image

  4. Type in your team name (e.g. f22-5pm-2) and the team name shoudl pop up so that you can add it.

    image

  5. Click the button, and the modal should change to look like this:

    image

  6. Change the permission level to Admin, and the click to add your team.

    image

  7. It should add your team to the list of folks with access:

    image

  8. Now, still under the Settings page for the repo, then look for Pages in the left navigation. You want to enable GitHub pages, so that the settings look like this:

    image

Remember: repeat these steps for both -docs and -docs-qa

  1. Now return to your main team03 repo (not the -docs or -docs-qa but the one with the Java and JavaScript code).

  2. Go under Actions, and click on the job that starts with 02-publish-docs-to-GitHub and you should see this:

    image

    On the right hand side of the screen, find where it says Run Workflow, and click it. That should expose this box:

    image

    Click Run Worfklow

  3. Repeat this step for the job that starts with 04-publish-docs-to-GitHub.

  4. When each of these two jobs is finished, you should be able to navigate to your GitHub Pages sites at URLs like this (subsitute your own team name):

    And these links should show a Storybook page like the ones shown below (except your team name will show instead of STARTER-team03. The branches listed may be different two, but this is the general idea of what the pages should look like.

    image

    image

  5. Go into the README.md file of your main team03 repo, and edit the links to the documentation. They will look like this when you start:

     TODO: Add correct links to the -docs and -docs qa GitHub pages sites

 * Storybook (production): <https://ucsb-cs156-f22.github.io/STARTER-team03-docs>
 * Storybook (development/qa): <https://ucsb-cs156-f22.github.io/STARTER-team03-docs-qa>

    After you edit, it should look like this (with links appropriate for your team). Note that you should remove the part that says TODO.

     * Storybook (production): <https://ucsb-cs156-f22.github.io/team03-f22-6pm-4-docs>
 * Storybook (development/qa): <https://ucsb-cs156-f22.github.io/team03-f22-6pm-4-docs-qa>

That’s it for this task.

Setup Task 4: Google OAuth (may be done at any time, but must be coordinated with 5 and 6)

Coordinate with the folks doing task 5 and 6 so you know exactly what the URL will be for your prod and qa apps.

Then set up Google OAuth for these. You can do that by creating a new Google OAuth app, or if you have an existing one, you can just add more “callback urls” to the list of existing ones, e.g.

image

Either way, your job is to end up with a value for GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET that you can put in the Config vars for your teams prod and qa Heroku deployments.

The folks doing Setup Tasks 5 and 6 may set up those values with placeholders, or they may not set them up at all, but it will be your job to make sure those have the correct values, and that Google OAuth then works. You will need to collaborate with the folks doing Setup tasks 5 and 6.

You are done when you can login with OAuth on both your prod and qa apps for team03.

Setup Task 5: Push main branch to team03 heroku prod (must be done after 2 and in coordination with 4)

Create a heroku instance for your team03 app, with a name such as the following (substituting your team):

Then:

  1. Set up the Heroku app to automatically deploy from main branch of your repo, the This should deploy the starter code to the Heroku app.
  2. Add a config var called PRODUCTION with the value true
  3. Add the config vars for GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET; just fill in values todo for now; the person doing set up task 4 will fill in the real values.
  4. Add a config var called ADMIN_EMAILS and add all of your team, plus your instructor (phtcon@ucsb.edu) and your mentor (the TA or LA listed in https://bit.ly/cs156-f22-teams). Their email can be found pinned to the announcements channel on the Slack.
  5. Make sure the Heroku app is up and running, and that you can login with your Google account, and see the Admin menu.

  6. Add the same folks you add to ADMIN_EMAILS as collaborators on the Heroku app (i.e. using the Add Collaborator button under the Access tab:

    image

If it works, you have just one more step: Edit the README.md of your main repo to fix the link to the production deployment.

It will start out looking like this:

TODO: Add a link to the deployed Heroku app for your team here, e.g.

* <https://f22-7pm-3-team02.herokuapp.com>

Change it so it looks like this (removing the TODO, and replacing f22-7pm-3 with your team name:

* Production deployment: <https://f22-7pm-3-team02.herokuapp.com>

The team member doing step 4 will be getting the correct values for GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET but they can’t do that unless/until you give them access, which is one of the things you should have done above.

You will need to collaborate with the person doing Setup tasks 4.

You are all three done with Setup Task 4, 5, 6 done when the team can login with OAuth on your prod and qa apps for team03.

Setup Task 6: Push main branch to team02 heroku qa (must be done after 2 and in coordination with 4)

This is the same as Setup Task 5, except for the qa deployment instead of prod.

To save space, I won’t repeat the instructions; just refer to those instructions, with these differences:

  1. Add -qa to end of app name, e.g.

  2. Do not set up the app to automatically deploy the main branch. Instead, deploy the main branch once (or as many times as you need to get the app up and running with OAuth) and then leave it for manual deploys of feature branches that need to be tested.

The team member doing step 4 will be getting the correct values for GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET but they can’t do that unless/until you give them access, which is one of the things you should have done above.

So, you will need to collaborate with the person doing Setup tasks 4.

You are all three done with Setup Task 4, 5, 6 done when the team can login with OAuth on your prod and qa apps for team03.

Adding Issues

Now, each of you may choose to continue working on the same database table that you did in team02, or you can choose to mix it up; that’s a decision I’ll leave up to the team.

As a reminder, these are the six tables:

Choose which of these you are going to work on. Then, for your database table, you are going to add a few issues to the Kanban board.

The easiest way to do this is to start by creating Cards on the Kanban board, and then Converting them to Issues.

Here is what that process looks like:

create-card-convert-to-issue

Here are the cards you need to create. I’m using Recommendation as the example here; substitute in your database table name in place of that.

The idea is that you should make a separate pull request for each of these issues; and it should be code reviewed and merged separately.

For each, you should get all of the tests to pass before moving on to the next issue.

Once you’ve made the cards and converted them to issues, the next step is to add detail to each issue, including acceptance criteria.

Open up issues to work with them.

At a later stage, you’ll be adding acceptance criteria. To do that you need to go to the full issue view. Here’s how that looks:

open-issue

Confusion about closing issues

Take note of the Close Issue button. A common mistake is to confuse two things:

If you have the window for an issue open on the Kanban board, here is how you close it:

close-issue-window

By contrast, if you accidentally click the Purple “close issue” button when you really just intended to close the user interface (I do this several times a week), here is how you reopen it. Note that you may have to move it on the Kanban board as well, since closing an issue might automatically move it around. Here’s what that looks like:

accidentally-close-issue

About acceptance criteria

A well written issue should have:

Learning to write good acceptance critera is a crucial skill. You want to think like an adversary: i.e. someone that is trying to trick you. The acceptance criteria should be written in such as way that if you had a really lazy programmer on your team, there is no way that they could pass the acceptance criteria without actually doing everything that is needed for the feature to work.

As an example, suppose the issue is “Add Recommendations to the nav bar”.

If your acceptance criteria consists only of:

Then the programmer could add the word “Recommendations” as static text (rather than as a pull down menu) and strictly sopeaking, they would have satisfied the acceptance criteria. But, they clearly would not have done what was intended!

So better is:

Adding Acceptance criteria to your issues: the mechanics

The mechanics of adding acceptance criteria to your issues are these:

Content of your acceptance criteria

Now that you understand the idea of acceptance criteria, and how to enter them, we are going to leave it up to you to decide how to write them out.

We encourage you to seek feedback from each other during your code reviews on whether the acceptance criteria are well-written. If they are reasonable, we’ll give you full credit, but if they are missing or sloppy, your team may lose points.

Keep in mind that the team03 grade is a team grade and not an individual grade. So please hold one another accoutable for writing good acceptance criteria. If you are not sure, ask the staff for guidance.

More details on team03

In this team project, our starter code has a frontend and backend, and we are focusing only on the frontend; you will likely not have to make any modifications to the backend.

We are focusing on learning these new React concepts:

Copying your team02 work into the starter code.

You’ll start with the starter code STARTER-team03, and then add to it the files you created in team02 to implement the database tables and backend CRUD operations

These will likely include, for each of the database tables you created in team02:

The first pull request you make should simply copy those files from your team02 repo into the appropriate directories.

Your next task: add a menu with one option for each of the six database tables

You’ll see on the menu bar that there are menus for Todos, Dining Commons and Dates.

You should add a menu item similar to that for Dining Commons, for the database table you are working on.

You’ll need to coordinate with your teammates to ensure that you don’t end up with merge conflicts.

It may be easier to have one person on the team add all six menu items; that’s up to you to coordinate.

Next Steps

Now, take on each of the issues you added to the Kanban board.

Make a new branch each time, and do a separate pull request for each issue.

The videos for team03 contain the information you need to carry out the steps:

As you finish each issue:

Also, and I can’t emphasize this enough: keep each PR small. We are trying to get you into that habit, because it will pay off in the project phase, and in real world practice.

When all of your issues are either complete, or at least have open pull requests, turn your attention to helping the team to get finished.

Check in with the team

Your next steps

The team03 assignment will be followed shortly by team04, which will use the same repo, code base, and kanban board; you can think of it as “team03 part 2”.

Will there be a team04

There may or may not be a team04; it depends on how much time is left.

If there is, in team04, you’ll add a data entry form for each of your six database records. That data entry form will be used for both entering new records (i.e. the POST route) as well as editing database records (the PUT) route. You’ll also add Create and Edit pages to the pages directory.

You’ll then hook up the “edit column” in the table to the Edit page.

Asking for help

If you need additional guidance, ask on the #help-team03 channel, and we’ll try to steer you in the right direction.

When you are done

When all branches are merged to main, all tasks on Kanban board in the done column, please submit on Canvas as you did for team02. Link coming soon.