We have identified several projects that could be undertaken to extend the current framework in support of one or more of these goals:
- Providing students with a more authentic experience of widely used industry practices
- Supporting a wider range of target applications
- Improving the code base
- Automating the setup of a full test deployment of the application, including external dependencies such as database systems (in our case, the relevant technologies would be Spring Boot Testcontainers and Docker.)
- Digging into the Spring Boot Authentication/Authorization system to provide an alternative to OAuth authentication that only applies in the test environment, but is close enough to the real Google OAuth Authentication that the test results are still valid.
- Using Playwright to automate the actions that a user would take in a browser and make assertions about the content of the returned pages.
It’s a challenging project, but you’d potentially have some help; there may be other students working on it as well.
Currently, whenever we make a change to a CMPSC 156 project that alters the database schema, the application breaks unless we rebuild the database from scratch.
But we are on the brink of actually going live with at least two (possibly three) of the applications, with real live production users. Once that happens, jsut “resetting the database” when there is a schema change is no longer a viable strategy. Instead, we need a proper database migration solution such as Flyway or Liquibase.
The work here is to:
- Examine pros/cons of Liquibase vs. Flyway, and choose one.
- Construct examples and programming exercises for first staff, then students, to get comfortable with the technology.
- Incorporate it into our actual practice.
Folks in m23-10am-4 (esp. Iain) worked on a workflow that would only do stryker mutation testing on the changed files in the PR.
We should review this, and consider establishing this as the new workflow for all of our STARTER code bases, and each of our legacy projects.
The proj-happycows app has a new example of how to do paged database queries and present those to the user with a paged frontend; there are likely many other places in our code bases where this could be done as well.
There is an autograder for team01, but it needs some updating.
It would be great to have autograders for team02 and team03 as well. This may require some updates to the assignments, but that’s ok.
Figure out the mystery of this: https://dokku.com/docs/deployment/zero-downtime-deploys/
No CHECKS file found. Simple container checks will be performed. For more efficient zero downtime deployments, create a CHECKS file. See https://dokku.com/docs/deployment/zero-downtime-deploys/ for examples