You should continue working on your implementation this week. Part of your work this week will be making sure that other developers can build and test your project.
As always, you will submit a revision of your project report, incorporating all feedback you have received so far.
Commit, to the week5
directory,
a single PDF named
report.pdf
. Submit the same
document via Canvas.
You should continue making progress on your implementation, working in your repository. As you make changes to the project, make sure that they are documented in the user manual.
There are two (related) milestones that you should reach this week: your project should be buildable and your project should be tested using continuous integration.
Any developer who happens upon your repository should be able to clone the repository and build your project on their machine (given some preconditions, all of which must be clear). In particular, your repository must contain reproducible instructions on how to clone the source, what dependencies or requirements are necessary, and how to invoke the build system. These instructions must be easily discoverable (they may be part of your user manual).
You must setup continuous integration for your project - whenever a change is merged into the master branch of your repository, the project should be built and tested. We suggest using Travis CI to automate this process, since it is free for open-source projects, is tightly integrated into GitHub, and is familiar to the course staff. You may also use a different tool if you prefer it. Regardless of the CI tooling you use, your build history must be visible to the course staff, and must include at least one passing build and at least one failing build. A good way to meet this requirement is to write a test that fails, commit it to your repository, and then fix the bug that caused it to fail.
As usual, your team will act as another team's customer.
Peer review rubric