Tim's-Journal.md

@@ -244,4 +244,72 @@ feedbackTypes: Array
 	- Keep in mind that not all projects have groups, therefore some items in the student DB will have NULL groupId's and groupName's
 		- this can be validated at: `https://gitlab.socs.uoguelph.ca/api/v4/projects/`
 		
-1:47 PM - Finished Work
+1:47 PM - Finished Work
\ No newline at end of file
+
+# Sept 20, 2021
+
+9:42 AM - Started Work
+
+## General
+
+- Worked on some coop learning goals (not done yet)
+- Read up on CI/CD best practices
+- Going to be doing an in depth in Gitlab API, after which, I should have enough knowledge to think of a solution for the branching feature which I see is wanted to be incorperated
+- I'm going to link the GitLab API somewhere in our readme. It's necessary to be able to understand the code and how Projects and Groups work
+_ I'm basically done planning the route for the incorperation of individual repos into IFS, I just need to finish a rough sketch of the code and begin assigning issues to each necessary function so that development is modular.
+
+## Features
+
+### CI/CD Refurbish
+
+- The current CI/CD process set up for the project is not using best practices. 
+- We need to modiy out gitlab-ci.yml file.
+	- All build jobs should be under a `build` stage. 
+	- All test jobs should be under a `test` stage and run only after build stage is successful.
+	- A deploy stage can be added later for continuous deployment, I just don't know how we would integrate that.
+- Tests should be split up into smaller chunks so that we can pinpoint the kind of bugs and errors that may occur.
+
+## Notes
+
+### `ProjectId` Vs `RepoId`
+
+- Currently, `repoId` is being used as the param of the links given as routes.
+- What we call `repoId` in out project is called `Project ID` in Gitlab.
+- <b>To avoid any confusion for future developers</b> 
+	- it would be best to change all `repoId` variables to a variable called `projectId 
+
+### Gitlab API links
+
+- `https://docs.gitlab.com/ee/api/api_resources.html` should be added to our projects documentation somewhere.
+
+### Branching Naming Convention
+
+- We need to develope a branching naming convention that will allow to know what the branch is solving, and maybe even potentaiall what its current state is.
+- Master branch should always be production ready.
+- Only fully functional branches should be merged into master.
+- A branching convention idea?
+```
+Master  A-<name>  B-<name>  C-<name>  D-<name>
+        |
+	A1-#1-<name>  A2-#2-<name>  A3-#3-<name>  
+	    |	
+	    A1-#1  A2B  A2C	
+```
+- A, B, C and D would be the only branches merged into master (once they are funtional)
+	- These represent a full feature (most likely an epic)  
+- A1-#1, A2-#2, A3-#3 would be the only branches merged into A (The same goes for B, C and D)
+	- These represent the full feature (epic) divided into chunks
+	- Should generally be an isssue
+	- The #1, #2, #3 etc... is the issue number (issues are given a number when created)
+		- This number will tell us what issue the branch is trying to solve
+		- This will ensure that all developers know what issue this branch is trying to solve in case it gets lost in a swamp of created branches by multiple developers
+- A2A, A2B, A2C would be the only branches merged into A2
+	- These represent an issue divided into smaller chunks
+	- Useful if the issue is devently large and requires multiple functions to be created, then each of these branches can be 
+	- Thesse should <b>only ever be individual tasks that that can be completed with little code</b>
+- <b>At no time should there ever be more than 3 layers of branches for a given feature/epic <b/>
+- All branches will go through the CI/CD pipe, and, only if they pass build, test and deploy pipes will they be merged.
+- The above Example should be documented in a readme in the project (I need to talk with Judi first to see what she thinks)
+
+
+