As part of your project activities, you will be creating project documents and other artifacts. Together they comprise your final project submission. See assessment for details.
Your GitLab project should contain everything related to your project! This includes your project proposal, meeting minutes from your sprints, software releases that you produce and any other documentation that is required.
1/ GitLab Project
Your GitLab project must be setup as described in the Getting Started section, and should minimally include:
- A project landing page (aka README, see below).
- All related documentation and source code (see below).
- Release pages for each sprint (see below).
- Milestones corresponding to each sprint.
- Issue lists for each sprint, including issues closed as part of that sprint.
- Unassigned issues representing incomplete work.
2.1. README (Project Landing Page)
You should have a markdown file in the root of your source code repository named
README.md. This will serve as a landing-page for your project (i.e. its the first thing that users will see when visiting your project page!). It should contain the following sections.
# SUPER-COOL-PROJECT-NAME ## Goal A brief description of your project. What is it? What does it do? ## Team Members List each person's name and email address. ## Screenshots/Videos Optional, but often helpful to have a screenshot or demo-video for new users. ## Quick-Start Instructions Instructions. Details on how to install and launch your application. ## Project Documents Include a link to your Wiki pages, see below. ## Software Releases Include a link to your Wiki pages, see below.
Your GitLab project has a built-in Wiki, where you can store more complex documents and project executables. It should contain the following documents:
- Project proposal
- Meeting minutes
- Anything else you feel would be helpful to document.
3/ Software Releases
Each sprint should produce an installable and runnable version of your project, which should contain the features that were completed during the sprint. The output from a sprint should be a release-quality build of your product, which you will store in this section of your project repository.
README.md file (from above) should include links to the components of each software release. Your software release should include:
Release notes: a markdown or text file, containing at least:
- the release date (which should be the sprint demo date)
- the version of this release (which you increment for each release)
- a list of changes that were included.
Installers: this is a packaged version of your application that a user could use to install your software. You should support and test installation on at least 2 platforms (pick two from Linux, Windows, macOS - whatever you have available for testing).
Acceptable forms of packaging include:
tarfile that, when extracted, contains
lib/directories, and a script that launches the application.
pkgfile that, when executed, installs the application.
4/ Source Code Repository
Source code and other assets required to build your application should be stored in your project’s source code repository. The structure should look something like this by the end of the term.
. ├── .gitignore ├── .gitlab-ci.yml ├── LICENSE.txt ├── README.md ├── application │ ├── build.gradle │ └── src │ ├── main │ │ ├── java │ │ └── kotlin │ └── test │ └── java ├── buildSrc │ ├── build.gradle │ └── src │ └── main │ └── groovy ├── gradle │ └── wrapper │ ├── gradle-wrapper.jar │ └── gradle-wrapper.properties ├── gradlew ├── gradlew.bat ├── releases │ └── v0.1-release-notes.md │ └── v0.1-installer.dmg │ └── v0.1-installer.exe │ └── v0.2-release-notes.md │ └── v0.2-installer.dmg │ └── v0.2-installer.exe ├── server │ ├── build.gradle │ ├── gradle.properties │ └── src │ ├── main │ │ ├── java │ │ ├── kotlin │ │ └── resources │ └── test │ └── kotlin ├── settings.gradle └── shared ├── build.gradle └── src └── main ├── java └── kotlin
Most of your repository contains the source code and related documents for your project. It is recommended that you follow the structure provided above, which will build properly in GitLab CI/CD.