An exercise to put to practice software development teamwork, database integration, containers, deployment, and CI/CD pipelines.
Your team works from a single shared GitHub repository.
To create it, exactly one member of the team - decide among yourselves who - clicks the Fork button on this repository to make a copy of it in their own GitHub account. That member then gives the rest of the team access to it: in the new repository's Settings tab, under Collaborators and teams, add each teammate and the course admins by their GitHub usernames. Everyone else clones that one shared repository, rather than making further copies of their own.
All code changes are made in feature branches within that one repository and merged by pull request. Because the team's repository is a fork of this one, GitHub will set the base repository of a new pull request to this repository rather than to your team's - change it back to your own team's repository, or your teammates will not be able to review or merge your work.
Share the web address of the team's repository using the messaging app specified by your instructor, posting it wherever the instructor has directed. That is how the work is submitted.
This is an open-ended exercise for you to show your mastery of software engineering, with some specific requirements:
- Your software must be composed of at least 3 different subsystems.
- One of those subsystems must be a MongoDB database.
- The other subsystems are custom - they can be anything of your choosing. Code must be primarily written in Python.
- Each custom subsystem's code must reside within its own subdirectory within this "monorepo".
- Each custom subsystem must be a containerized application, each having its own
Dockerfilewith the image hosted on Docker Hub. - Each custom subsystem must have its own CI/CD pipeline using GitHub Actions, with a separate workflow files for each subsystem. These workflows must be triggered by any code change, whether via
pushorpull request, to themain/masterbranch. The workflows must build, test, deliver the images to Docker Hub, and deploy any subsystems that are designed to run online (i.e. any web apps or other online services) to Digital Ocean. - Each custom subsystem must contain unit tests that provide at least 80% code coverage.
- You are welcome to use computing platforms such as Raspberry Pi or other embedded or mobile devices you have available, if they make sense for your project.
Replace the contents of the README.md file with a beautifully-formatted Markdown file including:
- a plain-language description of your project, including:
- badges at the top of the
README.mdfile showing the result of the latest CI/CD of each subsystem. - links to the container images for each custom subsystem, hosted on DockerHub.
- the names of all teammates as links to their GitHub profiles.
- instructions for how to configure and run all parts of your project for any developer on any platform - these instructions must work!
- instructions for how to set up any environment variables and import any starter data into the database, as necessary, for the system to operate correctly when run.
- if there are any "secret" configuration files, such as
.envor similar files, that are not included in the version control repository, examples of these files, such asenv.example, with dummy data must be included in the repository and exact instructions for how to create the proper configuration files and what their contents should be must be supplied to the course admins by the due date.