Project Artifacts

This section describes the project artifacts that you will create and use through the term. In general, each of these represents something that you will iterate over through the course of the term.

It also represents what we will grade at the end of the term, for your final submission grade.

1. GitLab Project

You and your team must create a project in the UW GitLab instance at the start of the term. Visit git.uwaterloo.ca and use the New Project wizard.

  • Give it a meaningful name; a “project slug” is just a version of the name with no spaces (and typically lowercase).

  • Make the repository private so that it’s not visible to the rest of the class.

    • Add your Team Members and course staff as Developers on the project.
  • Initialize with a README.md file, and see below for suggestions on formatting and contents.

  • Finally, email the instructor with a list of team members and your repository URL.

GitLab New Project wizard GitLab New Project wizard

Info

This is where you should keep track of everything that you do in this course! This includes meeting minutes, source code, scripts etc. Your completed projects with all of the contents below constitute your final submission (see assessment for details).

The following sections of the project should be developed for the first sprint and updated during successive sprints.

  • Issue tracking, where each issue represents a requirement that you wish to implement or a task/issue that needs to be resolved. You should document your progress in the issue, and close it when the work is complete.
  • Milestones, where each Sprint is tracked as a milestone with a due date. This helps you keep track of what you have assigned in each sprint.
  • Continuous integration (CI/CD) to create builds and run tests automatically from your repository.

2. Source Code Repository

All assets (source code, documents, diagrams, images, scripts) 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
├── console
│   ├── build.gradle
│   └── src
│       └── main
│           ├── java
│           └── kotlin
├── 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

Your repository should contain the following contents:

README.md

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.

# PROJECT NAME

## Goal
A brief description of your product. What is it? What does it do?

## Team members
List each person's name and email address.

## Quick-start
How to install and launch your application. 

## Screenshots/videos
Optional, but often helpful to have a screenshot or demo-video for new users.

## Releases
Each sprint should produce a software release. Provide a list of releases, 
including links to release notes and installers. For example:

version 0.1: released Feb 17, 2023
	* release-notes (txt)
	* installers (linux, macos, windows)
	
version 0.2: released Mar 10, 2023
	* release-notes (txt)
	* installers (linux, macos, windows)

Source code

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.

Your entire project, and all related code and resources, must reside in this repository.

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 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 installation on at least 2 platforms (pick two from Linux, Windows, macOS - whatever you have available).

    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 (produced from distZip or distTar tasks in Gradle).

    • an exe, dmg or pkg file that, when executed, installs the application (produced from JPackage task in Gradle ).