lab04 : MVP Release, MVP Review, Testing

num	ready?	description	assigned	due
lab04	true	MVP Release, MVP Review, Testing	Fri 10/22 11:00AM	Fri 10/29 11:59PM

Finalize MVP Materials (lab03 requirements)

Finalizing your demo (MVP video)

• Plan a five minute presentation video
• Please prepare a 5 minute YouTube video (unlisted or public, your choice)
  • See the bottom of the lab02 description for information about creating your MVP video.
  • Links to videos will be made available to the class for peer review, but will not be made public
• Present to an audience of potential users
  • Not to an audience of CS148 students, or the instructor or TAs.
  • Explain what problem the app solves, or what need it fulfills, as you demo the features of the app.
• Stay focused on user functionality.
  • Do not go into details of implementation, or team process.
  • There will be other presentations for that.
• Optionally, you may introduce with a powerpoint slide, and/or close with one, but the bulk of the time, you should be sharing your screen and showing us your app.
• At the end, tell us a bit about upcoming features planned for the next iteration.

At next week’s Wednesday lecture lect09 you’ll be asked to evaluate other teams’ presentation(s), so plan to watch them and be ready to do some very brief writing after each one.

Add Installation instructions to your README.md

• by 10/25/21, 23:59 PDT == Code Freeze Deadline (for details on the README format, see lab03)

Point us to your video

• by 10/26/21, 23:59 PDT create a file team/MVP_DEMO.md containing your MVP video link and any additional information you see fit that you think doesn’t belong in the project’s README.md. Also enter the link in the team links spreadsheet

Lab04 New Deliverables

MVP Tag/Release in your GitHub repo

By the end of Monday, 10/25/21, tag and release your MVP project in your github. This brief article gives some suggestions on versioning numbering.

To create a tag:

Option 1: Web UI

• You can use the web UI to create a tag, but it will only create the tag from the current version (most recent commit). The tag is automatically created when you create a new release in the git UI.
• Skip directly to ‘Create a Release’

Option 2: command line instructions.

(Choose this option if you need to create a tag that is earlier than the most recent commit)

git tag v1.0.0 <commit ID>

note - v1.0.0 is the tag name, and commitID refers to the last commit in your MVP

you can find the commit ID using git log, or using the history tab in the github web ui

if done correctly, you should see something like this in the git log

if you messed up, you can delete the tag using git tag -d <tag_name>

Verify that everything looks good, then git push origin <tag_name>

Your newly created tag should appear in your tags page on the web UI

To create a release:

Option 1:

• If you want to create a release from the current, most recent commit
• On the right hand column, there should be a section labeled ‘Releases’. Click on ‘create a new release’
• Put v1.0.0 in the ‘Tag Version’ box, and fill out the rest of the boxes.
• Click `Publish Release’ and the tag will automatically be created for you

Option 2:

• If you want to create a release from an existing tag
• On the right hand column, there should be a section labeled ‘Releases’. Click on ‘create a new release’
• There should be a toggle between Releases and Tabs right above the ‘Tag Version’ form. Click on Tabs to toggle over.
• Click on the menu (with 3 dots) on the far right hand side of the tag, and select ‘Create Release’
• Fill out the form, and Publish Release

New Deliverable: Participate in the MVP review and review other groups’ MVPs

In class on Wed, 10/27/21, 14:00, we will watch the videos all the groups have created, and provide feedback in a simple Google Form. You will get points towards lab04 for submitting these forms.

New Deliverable: Testing

Over the next week, the following testing deliverables will give you points towards lab04:

• Make sure that every person on your team is assigned to at least one issue in the in-progress column of your Kanban board at all times. If you complete work on the last open issue you were assigned to (yay!) and you move it to the Done column, immediately assign this team member a new issue from the Sprint backlog and move it to the in-progress column. Make sure that all these issues have clear acceptance tests/criteria and that you verified these before calling the issue Done.

• Use a unit testing library / test runner of your choice (we recommend JEST for Javascript/React and PyUnit for Python (comes with the Python package as “unittest” module)) to implement at least one unit test in your code. Mind you, one unit test will not really do you any good, apart from making you go through the motions. The benefit of unit testing, and test-driven software development in general comes from consistent use and embrace of it as a software engineering methodology, but for now we won’t require fully instrumenting your code with tests, even though we encourage it as a matter of principle!