- 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. You can add team members after it’s setup.
- Initialize with a README file, and see below for suggestions on formatting.
- Once it’s created, add your Team Members and course staff as Developers on the project.
- Finally, email the instructor with a list of team members and your repository URL! We can’t grade your project if we can’t access it…
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. Keeping your project up-to-date is a requirement for your sprint demo grade!
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. If there is a dependency (e.g. "requires a network connection to operate") list it here. ## Screenshots/videos Optional, but often helpful to have a screenshot or demo-video for new users. ## Releases Each sprint should produce a software release. Your README should include a list of each release, with a link to the release-notes. * see ![release page](assets/release-page.png)
You are expected to use the GitLab project-tracking features to manage your project. These include:
- 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.
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:1:
. ├── .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
We will build this project structure up through the term, so do not panic about creating everything right away! ↩︎