Development
Note: Project was originally made using GitLab instead of GitHub
Throughout the project our use of Git and GitLab has been extensive and thorough. We have taken use of many features on Gitlab like milestones, labels, the issue board and pipelines to structure both the project and how we work. Before starting development we created a Google Drive-document containing rules and naming conventions to be used throughout the project. This made us work in a more structured way as we could consult the document whenever we needed to and ultimately led to a better product than we would have been able to achieve without agreeing to some common ground rules before starting development.
Milestones - We have used milestones throughout the project to connect every issue to a clear overarching goal. We created the following milestones throughout the project:
- "MVP Frontend ++" for Submission 1
- "MVP Backend + Finished frontend" for Submission 2
- "Finish Project" for both Submission 3 and final delivery (November 29.)
Labels - We created several labels to categorize issues depending on what part of the project they were connected to. The following labels were created: API, Backend, Bug, Documentation, Feature, Frontend, In Progress, Refactor, Styling, TODO, Testing. This made it easier to identify issues when searching for them in the list of all issues.
Issues - In our Drive-document we agreed that names of issues should be of the following format: "Category: name-of-issue" where the category was one of the following: [hotfix, bugfix, feat, test, fix, style]. This is descriptive yet simple. If an issue contained multiple subtasks, we created checkboxes in the description of the issue which we checked off when the task in question was pushed to Gitlab. This allowed to have a clear visual overview of the progress of these small subtasks without having to make new issues for every single one of them. By creating the status labels "TODO", "In Progress" and "Testing" we were able to make effective use of the Issue Board-feature on Gitlab, which served as a way to visually view the progress we were making.
Branches - The first thing we did before beginning development at the start of the project was to create a Development-branch. This is normal practice in industry when developing large applications, and serves as a sort of main-branch v2, as it always contains the most up-to-date version of the entire app. All changes are merged into Development before being merged into main. This way we can both check that the functionality works before merging it into main, and also have a stable version to roll back to should something go wrong in main.
We made sure to always create branches out from issues, so that these were directly connected to a specific task. This is to avoid "drifter"-branches that have no apparent end-goal, and who's reason for existence eventually becomes unclear as their lifespan prolongs. Our Drive-document also contained a naming convention for branches, which was on the format "Category-issuenumber-nameofbranch".
Commits - To make sure the names of our commits were always in the same format we used a VSCode-extension called "Conventional Commits". This makes sure that each commit message is tied to a category, adds a nice descriptive symbol to make them look nicer, forces us to write both a title and a short description, and encourages connecting commits to issues by adding "#issuenumber" to them. An example of such a commit is shown below:
Merge requests - When setting up a merge request we made sure to always mark ourselves as an assignee, and another group member as a reviewer, which means another person always had to go through our commits and approve them before any changes were made to both Development or main.
Pipeline - At the start of the project we set up a pipeline on Gitlab that runs all the projects' tests. For a merge to be allowed through the pipeline must pass, which means all the tests must pass. This made sure that no app-breaking changes were pushed into either Development or main.
Our group had two weekly work sessions: Wednesday and Friday. Sessions on Wednesday usually lasted about 14 hours, while Friday sessions were 10-12 hours. We also worked individually outside of meetings when this was needed. This amounts to about 15-30 hours of work per person per week. All in all, a considerable amount of time was put into this project, simply because we enjoyed working on it.
Our long physical work sessions allowed us to pair-program almost constantly, which increased the total efficiency and effectiveness of the group considerably. We started all our meetings with a scrum-like "Daily meeting" where we discussed what we had done since last meeting, what needed to be done during the meeting, and asked for help if we had run into problems. We also discussed possible architectural and feature changes that needed to be made. Outside of meetings we communicated extensively through our Facebook Messenger-group and over phone.
Communication was one of our groups strengths, and the long physical meetings helped facilitate this.