Skip to content

Changes

Page history
Update Tim's Journal authored by Timothy Catana's avatar Timothy Catana
Hide whitespace changes
Inline Side-by-side
Tim's-Journal.md
View page @ 915c4a8e
...@@ -256,7 +256,7 @@ feedbackTypes: Array ...@@ -256,7 +256,7 @@ feedbackTypes: Array
- Read up on CI/CD best practices - 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 - 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 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. - 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 ## Features
...@@ -271,16 +271,17 @@ _ I'm basically done planning the route for the incorperation of individual repo ...@@ -271,16 +271,17 @@ _ I'm basically done planning the route for the incorperation of individual repo
## Notes ## Notes
### `ProjectId` Vs `RepoId` ### `projectId` Vs `repoId`
- Currently, `repoId` is being used as the param of the links given as routes. - 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. - What we call `repoId` in out project is called `Project ID` in Gitlab.
- <b>To avoid any confusion for future developers</b> - <b>To avoid any confusion for future developers</b>
- it would be best to change all `repoId` variables to a variable called `projectId - it would be best to change all `repoId` variables to a variable called `projectId`
### Gitlab API links ### Gitlab API links
- `https://docs.gitlab.com/ee/api/api_resources.html` should be added to our projects documentation somewhere. - `https://docs.gitlab.com/ee/api/api_resources.html` should be added to our projects documentation somewhere.
- Probably going to fogo into the wiki
### Branching Naming Convention ### Branching Naming Convention
...@@ -291,25 +292,22 @@ _ I'm basically done planning the route for the incorperation of individual repo ...@@ -291,25 +292,22 @@ _ I'm basically done planning the route for the incorperation of individual repo
``` ```
Master A-<name> B-<name> C-<name> D-<name> Master A-<name> B-<name> C-<name> D-<name>
| |
A1-#1-<name> A2-#2-<name> A3-#3-<name> A1-#1-<name> A2-#254-<name> A3-#121-<name>
| |
A1-#1-01 A1-#1-02 A1-#1-03 A1-#1-01-<name> A1-#1-02-<name> A1-#1-03-<name> etc...
``` ```
- A, B, C and D would be the only branches merged into master (once they are funtional) - `A-<name> B-<name> C-<name> D-<name>` would be the only branches merged into master (once they are funtional)
- These represent a full feature (most likely an epic) - 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) - `A1-#1-<name> A2-#254-<name> A3-#121-<name>` 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 - These represent the full feature (epic) divided into chunks
- Should generally be an isssue - Should generally be an isssue
- The #1, #2, #3 etc... is the issue number (issues are given a number when created) - The <b>#1, #254, #121 are the issue numbers</b> (issues are given a number when created) they are <b>not</b> a randomly assigned id incremented upon each new branch creation
- This number will tell us what issue the branch is trying to solve - 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 - 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 - `A1-#1-01-<name> A1-#1-02-<name> A1-#1-03-<name>` would be the only branches merged into A1
- These represent an issue divided into smaller chunks - 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 - 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> - 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/> - <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. - 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) - The above Example should be documented in a readme in the project (I need to talk with Judi first to see what she thinks)
\ No newline at end of file