COMP30022: IT Project Getting Started Guide
===

## Introduction

The aim of this document is to help you get to grips with what is involved in a practical software development project. Let this be a guide to help inform your decisions and give you direction for setting yourself up for success. Aim to complete the tasks listed below **by the end of week 2** to give yourself the best platform to start your projects and stay on track.

### Topics Covered

- Version Control
- Workflow Management
- Team Communication
- Documentation
- Technologies
- Team Document
- Bonus: CI/CD

## Quick List

Here's a quick list to keep track of what you need to have completed by end of week 2. These include my recommendations in () - please however use whatever you feel comfortable with out of the topics below.

- [ ] **Code Repository (Github)**
- [ ] **Communication (Slack)**
- [ ] **Workflow Board (Trello)**
- [ ] **Documentation (Google Docs)**
- [ ] **Technologies Picked ( React | Firebase)**
- [ ] **Team Document**
- [ ] **Meeting Times**

## Version Control

Hopefully you have had a crack at git some time during uni - if not don't worry because you will use it so much that everyone will be an expert at the basic workflow by the end of this subject.

This topic is further divided into sections on **local** and **remote** version control. The **remote** version control section also includes information on pull requests and branching for your project repo.

:::info
If you are new to version contorl or just need a refresher I highly recommend using the guide and cheat sheet provided by [Atlassian](https://www.atlassian.com/git/tutorials/what-is-version-control).
:::

---
### Local

You have a choice between using a client (GUI) or just terminal with git (installed by default on most linux distributions). For my first entry into version control *(VC)* I used my *IDE's (Atom)* GUI based intigration which was extremely helpful in helping me wrap my head around how it all worked, so feel free to use one if it comes with your editor of choice (I know VS Code has good VC built in). However, I recommend that you work towards getting familiar with command line based VC.

#### Clients

- [Linux/Mac/Windows](https://git-scm.com/download/gui/windows)

---
### Remote

[Github](https://github.com/), [Bitbucket](https://bitbucket.org/) or [Gitlab](https://about.gitlab.com/) are the only ones I would recommend. Out of those 90% of the time Github is the best option. All of them provide pull request, issues and CI/CD support. (note that bitbucket and gitlab have arguably better CI/CD but for this project Github will do more than enough)

---
### Standard Workflow

So here is the normal workflow for starting to work on a new feature/component of your project:

- First you need to make your own branch called a feature branch (we will merge this branch back to master later on a pull request).

git fetch && git pull
git checkout -b "your_username/feature"

:::info
Note that I like the branch convention of using your git username then a delimeter with the feature name - this way its easy to see who's branch is doing what (also `git blame`)
:::

- After you have finished your feature, done some testing locally and think its ready for review you will add all your uncomitted changes (if you haven't been comitting incrementally, which you should be as it is good practice) and push to remote.

git add . (or if you've muddied your working dirrectory then add them individually)
git commit -m "what this commit does e.g. Add login button on main page"
git push -u origin "branch_name"

- After this just hop over to the website, select the branch and open a pull request for review. Your team mates can review this and once they are satisfied with the changes they can approve the pull request and your branch merges into master (or whatever parent branch it belongs to).

:::warning
Please add me to your repo - `hfarooqui98` is my github tag.
:::

---

## Workflow Management

This is how your team tracks what work is being done, by who and when. If you're making something solo then usually it's still a good idea to break your work up into logical units and track your progress so you can reduce some mental overhead. In a team, unless you are psychics it's a must and for this subject it is also a requirement.

Here is a link to a helpful blog post on standard board layouts on [Trello](https://blog.trello.com/engineering-teams-sample-trello-boards) that I reccomend you checkout. Below is the board that I believe best fulfils the needs for this subject.


:::danger
Make sure you use the board whenever your work is updated! It directly affects my perception of your teams progress
:::

---

## Team Communication

What will your team use for messages, notifications for pull requests, builds and deployments? Please **DO NOT USE:** `facebook messenger, email, telegram, whatsapp, wechat, hackchat`. Unless you can setup webhooks/bots for notification integrations.

### Options

- **Slack:** What everyone uses, its free for under 10k messages and has every possible plugin and webhook support. This is a great choice.

- **Discord:** Actually has pretty good support for what we're doing but probably need a good reason to justify this one.

- **Microsoft Teams:** I dont know why but it's certainly an option

### Plan

It is absolutely vital that your team sets out and agrees to how the channels should be used, when you will check it so everyone can set their expectations. e.g. I won't check your slack unless you @ me or when I want to see on how everything going. This should go in your Team Document.

## Documentation

Any software project is incomplete without proper documentation. These documents include architecture diagrams, team meeting minutes, motivational modelling, specification documents, client meeting minutes and much more. I recommend that you try and document all key aspects of your project, it does not have to be massive but it should be there.

I recommend HackMD, Confluence, Google Docs or Dropbox.

:::warning
Again, I would like you to add me to any such repository of documents you create. Feel free to use my university email: [e-mail]
:::

## Technologies

This is a CRUD app so it involves creating and managing a database, database wrapper (API/backend) and front end. This will be covered more in depth by Austen in week 3's lecture.

## Team Document

A document that outlines who's in your team, what tools/technologies you plan on using and agreements around the expectations set by the team.

This could also be called a team contract. It tries to give some foundation to your teamwork as each memeber agrees on their preferred "role", where they will invest more time in than other areas. This usually aligns to each team members strengths, experience and interests. It sets out how you will communicate, set meeting times (outside of our standup) and anything else important your team agrees upon.

## Bonus: CI/CD

Please only do this if everything else is finished already in the checklist. Continuous Integration and Deployment is the process of how your code is tested, built and deployed (automatically). I'm not going to recommend anything here yet but eventually I would really like every time to have an automated integration testing, builds and deployment setup. It is what the industry uses, it makes your life easier for a bit of upfront investment.

## Contact Info

Github: hfarooqui98
Slack: [e-mail]
Google Docs/Drive: [e-mail]
Atlassian: [e-mail]