Two important stories, end-to-end.

This sprint’s goal is to develop at least two fundamental, different stories end-to-end. Tackling additional stories to get ahead is OK, but be sure your two most valuable and important stories are done very well and following all expectations of this sprint.

On Sunday, November 12th, there’s an intermediate deadline of one story running end-to-end in staging.

On Monday 11/20, you will demo these stories running on your cloud staging server in-class.

2x End-to-end Story Expectations

1. Interactive, reproducible demo from the front-end in staging following concrete instructions.
2. Actions taken in the front-end persist in the database.
3. Well-factored, idiomatic layers between angular template(s) and entities (component/widget class, front-end service, API route, backend service).
4. Full test coverage of unit tests for your feature’s impacted backend service(s). See the testing docs for more info on testing tools and test coverage report generation.

Treat Stage Branch as Production and Never Break Stage/Production

Don’t merge your work into stage until it is functional and ready for launch. Work in feature branches until then, branch off of feature branches for making progress on the feature (and PR/merge back into the feature branch!) and only merge a feature into stage once it is ready. After any merge to stage, your team should be monitoring your Cloud Apps deployment for build success, database reset post-deploy, and testing that it is functional. Starting on Monday, November 13th, if your CloudApps stage is broken we will begin applying penalties to sprints. For this course, your stage branch is effectively main and production; breaking production in a real-world setting is a red alert scenario where you want all hands on deck to fix the issue and get your staging environment operational again. The best way to avoid bringing down stage is to verify that changes work on a code reviewer’s DevContainer, not just the original PR author’s, before merging changes in.

Team Project Management

Continue utilizing the expected tools and workflow of the course:

1. Maintain your Project Board with cards linked to issues, assigned to team member(s), with descriptive titles for all cards/issues
2. Perform work on branches off of stage
3. Perform pull requests with well written titles and messages and request code reviews from team members
4. Make effortful and helpful code reviews for your team mates, helpfully maintaining high standards of code
5. Squash and merge approved PRs into stage

Technical Specification Documentation

Add a new markdown document in your docs directory following the naming convention of your design document from Sprint 0, but with a name suffix of -spec.md. You will not author a full technical specification, but

1. Descriptions and sample data representations of new or modified model representation(s) and API routes supporting your feature’s stories
2. Description of underlying database/entity-level representation decisions
3. At least one technical and one user experience design choice your team weighed the trade-offs with justification for the decision (we chose X over Y, because…)
4. Development concerns: How does a new developer get started on your feature? Brief guide/tour of the files and concerns they need to understand to get up-to-speed.

Extra-Credit (1 point) - Catch Your stage Branch up with csxl.unc.edu Production

The TAs are not permitted to assist with this extra credit opportunity in or outside of Office Hours.

Some PRs have landed in production at csxl.unc.edu since you began Sprint 0: https://github.com/unc-csxl/csxl.unc.edu/commits/main

To earn this point of extra credit, you should catch your stage branch up to upstream/main such that you have commit 26e033e, or later, in your stage branch. You may need to resolve conflicts. When creating a PR for this catch-up branch, rather than squashing and merging into your stage in this instance you should use the “Create a Merge Commit” strategy. This strategy will retain the history from production’s main branch.

This is good practice, and easier to achieve, if it’s done semi-regularly. Additionally, this serves as a prerequisite to being considered for merging your team’s features into production after the semester ends.