Skip to content
Application Development II
GitLabGitHub

Milestone 2: Project Proposal and Dev Environment

We will begin the semester project by familiarizing ourselves with how Kotlin applications are built and deployed for Android applications. In this milestone, you will build on GitHub skills learned last semester to automatically build and version a basic Android application.
PreviousPDFSlidesNext
Overview
Worth:10%
Due:Sprint 1 (3%): Oct 6
Sprint 2 (7%): Oct 20
Hand-in:A link to your group GitHub repository handed in on Moodle, as well as slides for your presentation. See Requirements for more information.
Notes:Late submissions will not be accepted for either part of this milestone

The course project will see your groups collectively scope, define, implement, and deliver a complete Android application over the course of the semester.

This milestone has two parts:

Sprint 1 (3%, Oct 6): Set up a group repository for developing and releasing Android software

Sprint 2 (7%, Oct 20): Write a technical proposal presenting your Android project.

This repository and proposal will be the foundation of the rest of your project — you will continue to use and update both as your project develops throughout the semester, and along the way, learn and practise important application development and delivery best practises.

The goal of this milestone isn’t to craft a perfect plan that fortells exactly what your app will become from the outset. Rather, this milestone is about setting your team on the best footing possible for accomodating changing requirements and collaborating on a polished final project as you create your application and make continuous progress throughout the semester.

By the end of this milestone, you will have done the following:

  • Sprint 1: Apply repository management practises to maintain throughout the semester:
    • Use branch management techniques to separate developer efforts and separate requirement tasks
    • Enforce pull requests to main branch to enforce clean, linear history (continuous integration)
    • Use Android linting/building tools to enforce each release proven to meet defined build requirements (continuous depoyment)
    • Create releases from passing, approved and reviewed pull requests pushes to main (semantic versioning)
  • Sprint 2: Propose and scope your project:
    • Determine what exactly your project is for and what it will be (requirements analysis).
    • Determine what features to implement, publish a road map for implementing them, and plan for contingencies and how they interact (risk analysis).
    • Document and present the above in a technical presentation.

This milestone kicks off your project by having you complete two discrete tasks. Instructions and specific requirements are given in the sections below.

  • (Oct 6) Create a group repository to track contributions, store documentation, and marshal required project infrastructure for automated CI/CD throughout the semester
  • (Oct 20) Prepare a proposal presentation explaining the major goals of the project, the technical roadmap for attaining those goals, and associated risk analysis/mitigation strategies.

This milestone starts things off by having you set up an automated development environment on GitHub — we will build on this repository as the semester progresses with more sophisticated features.

The basic development environment requirements for Milestone 2 build on skills you learned last semester:

  • Create a repository shared amongst your teammembers
  • Enforce and maintain a clean repository history with your teammembers
  • Write a GitHub actions workflow file to automate compiling and building your project source code
  • Implement and release an initial landing page for your application to prove that your repository infrastructure works.

Marks for this sprint are determined by meeting the above requirements, defined in the sections below.

The first step is to create a github repository. I’ve created a GitHub repository template for you to use: Link to template repository.

  • Click Use this template in the top right corner of the project template screen. (linked in the paragraph above.) Then fill out the following information:
  • Repository name: Either the name of your application (if you have one decided), or 5A6-group-project, or something else similarly descriptive of your project.
  • Make the repository private.
    • After making the repository, add yourself your team members and myself (michaelhaaf) as collaborators to this project.
    • To be clear, you will have just one shared repository in the group.

Project READMEs are the most visible public information about your project. They introduce the purpose of the project, how it is used, and how it is developed. You can read more about the purpose of READMEs in the GitHub Docs.

In GitHub, project READMEs support Markdown which allows you to use images and advanced formatting such as links, lists, and headers — that way, your README can be quite expressive.

Your README can and will be updated throughout the semester. By the Sprint 1 deadline, it should adhere to the following template and the content should be written:

README.md
# PROJECT NAME


## Goal
A brief description of your application. Should answer, as concisely as you can: what is it? what is its purpose?


## Quick-start
How to install and launch your application. These should include instructions for:
- (by Sprint 1) building and running your release from source code (i.e. your github repo)


## Screenshots of application
- (by Sprint 1): Screenshots from each of the main screens of your application.


## Team members
List each person's name and email address.
README.md
# PROJECT NAME


## Goal
A brief description of your application. Should answer, as concisely as you can: what is it? what is its purpose?


## Quick-start
How to install and launch your application. These should include instructions for:
- (by Sprint 1) building and running your release from source code (i.e. your github repo)


## Screenshots of application
- (by Sprint 1): Screenshots from each of the main screens of your application.


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

Once the repository is created:

  • Create a branch protection rule for the default main branch. Read through the document linked and make sure you understand all of the options listed.

Ensure that the following branch protection rules are enabled:

  • “Require deployments to succeed before merging”. We will set up a deployment environment later.
  • “Require status checks to pass before merging”. We will set up status checks later.
  • “Require pull request reviews before merging”
  • “Require linear history”
  • “Do not allow bypassing the above settings” This setting is important, since the creator of the repository will, by-default, bypass the above settings. We want to prevent accidental merges to main.

These steps will allow all group members to freely develop on their own branches, test deployments on their own branches, and then REQUIRE that merges to the main branch are reviewed by team members and pass the CI/CD pipeline steps.

Once the above rules are enforced, you will no longer be able to directly push your commits to the repository from main branch. Instead, you will create branches as needed, and when the work on those branches is complete, you will create pull requests — that is, a request to pull your changes from one branch to the main branch.

The Git and GitHub lecture notes show example workflows in git and GitHub for making changes in git and creating pull requests from feature branches when finished — review those notes for best practises to do in your milestone.

One of the main positive outcomes of managing branch history intentionally is producing readable and maintainable code history. You can read more detailed about that in the Git and GitHub.

Your grade for this section will be determined based on the following criteria:

  • commit message and content quality
  • branches used appropriately
  • all pull requests to main are reviewed by team members, pass basic build tests, and use automatic versioning

As mentioned in the previous section, the expectation for this project is that your main branch maintains a linear history while contributions are made by all project members, and that each commit in the main branch corresponds to valid release of your project that can be built and compiled, allowing your project to support rollbacks and version pinning.

You might wonder — with such strict requirements about your main branch and CI/CD, what happens if you accidentally push code to main that does not build?

The answer: we are building repositories that do not allow you to do this. See the enforce branch management requirements above.

Some of the branch management abilities we enabled allow us to enforce certain building steps, or test results have taken place before accepting the pull request.

We’ll use these abilities to define two distinct GitHub workflows that you can improve upon throughout the semester:

Workflow Requirements:

  1. (Sprint 1) A pull request workflow that lints Kotlin and Android code for style — this pull request workflow should be incorporated in every pull request.
  2. (Sprint 2) A release workflow that ensures Gradle can build your source code and create . The release workflow should trigger AFTER a pull request from main has been accepted.

You will find the following resources helpful in this task:

Your grade will be based on finishing a pull_request workflow that builds your code and checks for kotlin/android style or code issues automatically with each pull request.

This part of the milestone should be the easiest — you are welcome (in fact, encouraged) to adapt code from Assignment 2 work for your initial landing page.

The requirements for this follow:

  • Your code passes the Grade Build defined in your GitHub Actions (you should NOT accept a pull request that fails this build!)
  • One different “screens” per developer on the project (2 or 3). The requirements for these are loose, but should be something you actually anticipate being a part of your project; some suggestions:
    • a landing page
    • a help page
    • a contact page
    • etc.

For this part of the project, you will be using GitHub Projects to set up a self-documenting GitHub repository that tracks your changes for the rest of the semester, and contains your project proposal documentation.

The lecture notes on Application Development contain slides that will be a useful reference point for this part of the project — particularly, how to turn project requirements into user stories and trackable issues.

If you are struggling to come up with an application idea, or if you want to see the how the documentation techniques we are using are applied in the real world, I recommend checking out existing open source Android projects:

For these resources, it may not be obvious where to look — generally, the Issue Tracker and the Source Code are helpful places to start looking when trying to learn things about someone else’s project.

For this part of the milestone, you will use prepare a presentation for the rest of class introducing your application idea and your plan for implementing it over the course of the semester.

Update Oct 18: The requirements that were listed here before are now included in a GitHub Wiki that your team should use a template for their own GitHub wiki: link to template wiki

Your group should aim to fill the above wiki for your own project. The presentation should be a summary of the content of the above wiki.

To document the tasks needed to meet the requirements of your project proposal, there are two important tools to learn:

These are the public-facing requirement trackers for your project that are kept up to date while you maintain the project.

The repository template I have provided you comes with two Issue types to use for writing risk assessments for each of your tickets:

  • Requirement: used to define high-level project requirements that are broken up into tasks using Work Breakdown Structure WBS
  • Task: used to define Requirement subtasks using Level of Effort (LOE) estimations

Part C of your proposal documentation is all about the Tasking Plan— this Tasking plan should be completed with Issues and Milestones that you have defined using the GitHub Project interface.

Your mark for this portion of the assessment will be determined on:

  • how well you document your requirements and subtasks
  • how much your requirements and substask analysis actually makes sense.

You will find the following resources helpful:

Part of this milestone is to convert the goals, requirements, and risk analysis you’ve performed in the previous sections into a GitHub Roadmap.

Roadmaps are relatively common features in open-source projects for keeping-in-the-loop your community of developers, contributers, and users of your software — the “roadmap” project is a recent attempt by GitHub to provide a GUI for automating some of this effort.

To adapt your proposal to a GitHub roadmap, see the links below for documentation and tutorials:

You will also find the following helpful:

NOTE: we haven’t had time to cover this in class — I will not expect this to be completed by the end of Sprint 2b (Oct 20). We will cover this in the next milestone

See Milestone 3a

This may seem like a lot of work! In fact, we are covering quite a bit of ground but the actual effort required for each component of this milestone should be light (and you can delegate these tasks amongst your group members).

The big picture is: As the project continues beyond this milestone, you will have:

  • a plan for what features you are going to implement
  • defined acceptance requirements for considering those features completed
  • a structure to accomodate changes to those requirements and to budget time/risk associated with those changes
  • semantic versioning and releases associated with each feature implementation
  • automated communication of feature implementations among your contributers developers and those who can view the repository
  • automated history tracking so that all contributers can clearly understand the course of the development of the software, and rollback changes as required.

These efforts will make the final efforts of releasing a testable beta application Milestone 3 and a polished final release Milestone 4 that much easier and lighten you load in the later semester, allowing you to focus on code and making cool things without hassling about infrastructure, plans, and communication.

The marks for each sprint will be assessed based on meeting the requirements outlined in each section.

Sprint 1: Repository and CI/CD

  • 30%: README and repository setup requirements
  • 30%: Repository branch management best practises
  • 40%: Working GitHub Actions, initial release requirements met

Sprint 2: Project Design & Risk Analysis

  • 80%: Proposal Documentation
    • PDF and/or GitHub Wiki created answering all of the prompts from the template proposal
    • Github Issues created that track progress on functional requirements defined in proposal
  • 20%: Presentation
    • all teammembers contribute and explain the above documentation in class on Oct 20