Project Submission

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.

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/ Documentation

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.

2.2. Wiki

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.

Your 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:

  • a zip or tar file that, when extracted, contains bin/ and lib/ directories, and a script that launches the application.
  • an exe, dmg or pkg file 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.