Merge pull request #4 from bcgov/update/confluence-content

Updated content from confluence.

patterns/docs/Coding Patterns & Practices/Coding Patterns & Practices.md

@@ -1,45 +1,21 @@
 ---
 sidebar_position: 4
 ---
-Status
+<table class="wrapped"><colgroup></colgroup><tbody><tr><th>Status</th><td><div class="content-wrapper"><p>Document</p></div></td></tr><tr><th>Stakeholders</th><td>NRIDS Architecture, Development &amp; Digital Services, NRM Product Teams</td></tr><tr><th>Description</th><td>The purpose of this page is to outline some coding practices when developing an application. Practices used by a team should be documented in the repository.</td></tr><tr><th>Outcome</th><td>Consistent point of reference for onboarding new product teams into the NRM's.</td></tr><tr><th>Owner</th><td>NRIDS (DDS, Architecture)</td></tr></tbody></table>
 
-Document
-
-Stakeholders
-
-NRIDS Architecture, Development & Digital Services, NRM Product Teams
-
-Description
-
-The purpose of this page is to outline some coding practices when developing an application. Practices used by a team should be documented in the repository.
-
-Outcome
-
-Consistent point of reference for onboarding new product teams into the NRM's.
-
-Owner
-
-NRIDS (DDS, Architecture)
-
-
-
-**Languages Supported**
+### **Languages Supported**
 
 Currently, most agile teams use one of these 4 languages and it is encouraged to stay within these languages, it may expand in the future. ( Typescript/JavaScript, Java On Native, Python, Go)
 
-
-
-**Native Deployments**
+### **Native Deployments**
 
 Some Languages are interpreted by their runtime ex:(java on JVM, python, javascript, etc..) whereas some languages are compiled (Golang, Rust).
 
-Use native(static binary) deployments wherever available. for ex: it is a **MUST** for teams using Java to deploy using GraalVM native image without the overhead of JVM interpreter. 
+Use native(static binary) deployments wherever available. for ex: it is a **MUST** for teams using Java to deploy using GraalVM native image without the overhead of JVM interpreter.
 
 Focus on the scale-out vs scale-up as deployments are into containers or serverless.
 
-
-
-**Code Design Patterns and Principles**
+### **Code Design Patterns and Principles**
 
 *   Apply SOLID and DRY principles. ([https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english](https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/), [https://www.baeldung.com/cs/dry-software-design-principle](https://www.baeldung.com/cs/dry-software-design-principle))
 *   Use Composition over inheritance as much as possible.
@@ -51,17 +27,17 @@ Focus on the scale-out vs scale-up as deployments are into containers or serverl
     *   The Service Layer MUST have a transactional context.
 *   Use Lazy Loading and Cascading in ORM to avoid fetching child entities unnecessarily and also make sure the mutations are cascaded as well.
 *   Follow the TDD approach and the unit tests become living documentation of code, Stub external services with some sort of code, ex in java :- wiremock or powermock, split test lifecycles, so that UTs and Integration Tests can run independently.
-*   Follow The Twelve-Factor App standards - [https://12factor.net/](https://12factor.net/)
+*   Follow The Twelve-Factor App standards -[https://12factor.net/](https://12factor.net/)
 *   Use testcontainers([https://www.testcontainers.org/](https://www.testcontainers.org/)) or GHA services([https://docs.github.com/en/actions/using-containerized-services/about-service-containers](https://docs.github.com/en/actions/using-containerized-services/about-service-containers)) for integration TESTS which includes, databases, queues, cache etc...
 
-**Folder Structure and Naming Conventions**
+### **Folder Structure and Naming Conventions**
 
 *   Establish and understand your folder structure, if using a template avoid reorganizing (eg. [https://github.com/bcgov/quickstart-openshift](https://github.com/bcgov/quickstart-openshift))
 *   Have a common consistent way when creating names. (eg. for your controllers - The naming of controller APIs should be in line with the pattern of tag definition in swagger - Swagger Tag resource-subresource - URN resource/subresource/pathParameter/subresource)
 
 ### Secret and Environment Variable Handling
 
-*   Exercise the practice of least privilege (eg. Who can and should be able to access secrets) 
+*   Exercise the practice of least privilege (eg. Who can and should be able to access secrets)
 *   Do not put sensitive information in the code, use a secret
 *   Use environment variables when they may not be sensitive but change between environments (eg. Dev, Test, Prod)
 *   Do not create secrets manually in Openshift.
@@ -77,9 +53,7 @@ Focus on the scale-out vs scale-up as deployments are into containers or serverl
 *   Use plain language when reporting an error. (example. If an error requires a user to do an action they should be able to follow the direction from the error)
 *   Avoid generic language (eg. Error, review logs)
 
-
-
-**Code Formatters and Plugins**
+### **Code Formatters and Plugins**
 
 *   Use common plugins and common formatters across team members to avoid flagging code as changed when it was just the format that was changed. (eg. Prettier, SQL Formatter, ESLint)
 *   Share the IDE specific formatter in the GitHub to avoid conflicts
@@ -97,27 +71,27 @@ The below was created using the [QuickStart OpenShift](https://github.com/bcgov/
 
 trueBranching Strategyfalseautotoptrue10111
 
-**GitHub PRs - Commits**
+### **GitHub PRs - Commits**
 
-*   Follow the Conventional Commits for a better understanding - [https://www.conventionalcommits.org/en/v1.0.0/](https://www.conventionalcommits.org/en/v1.0.0/)
+*   Follow the Conventional Commits for a better understanding -[https://www.conventionalcommits.org/en/v1.0.0/](https://www.conventionalcommits.org/en/v1.0.0/)
 
 ### PR Review and Practices
 
 *   PR titles should follow a pattern (eg. "#Ticket Number - Nice Description (#)")
 *   A single PR should be for a single Feature/bug/hotfix/patch/etc and kept as small as possible and reasonable
 *   Add appropriate labels established by your team. (eg. Adding labels to also indicate the applications being impacted by the PR, for instance, "web" or "API")
-*   Connect the issue using the button "Connect Issue", if not available install the Chrome Extension [ZenHub for GitHub](https://chrome.google.com/webstore/detail/zenhub-for-github/ogcgkffhplmphkaahpmffcafajaocjbd) or similar (this will help trace a completed task to the code modified)
+*   Connect the issue using the button "Connect Issue", if not available install the Chrome Extension[ZenHub for GitHub](https://chrome.google.com/webstore/detail/zenhub-for-github/ogcgkffhplmphkaahpmffcafajaocjbd)or similar (this will help trace a completed task to the code modified)
 *   If you are the author of the PR avoid resolving the comments, instead reply to them to let the reviewer be aware of your thoughts.
 *   If you are a reviewer try to mark the comments as resolved to help the PR author to identify easily what is still missing.
 *   Comments and conversations on the PR are good to let everyone be aware of what is happening but a quick call can also save a lot of time.
 *   Once a review is raised, a reviewer should do the best effort to try to find a good moment to start. (eg. in the next 3 business hours. It does not mean finishing it in the 3 hours, just try to start providing some feedback. If multiple PRs are open at the same time the delays will be completely acceptable)
 *   Review according to best practices for the code and application. PRs are about code review (**not people review**)
 *   Have a merging practice. (eg. Squash the commits before merging to keep the main timeline clean)
-*   Clean up your branches (eg. Delete the branch after the merge is done (after merging do not reuse the branch))
+*   Clean up your branches (eg. Delete the branch after the merge is done (after mergingdo not reuse the branch))
 
-**Dependency Management**
+### **Dependency Management**
 
 *   It is **strongly recommended to keep dependencies updated** with automated pull requests from tools like **Renovate, Snyk or Dependabot**.
 *   This introduces new features, fix bugs, address vulnerabilities or improve performance, affecting the quality, security, and functionality of a project.
 *   Regular dependency pull requests help to keep changes small, up to date and, of course, manageable.
-*   These pull requests should not be closed without careful consideration.  Unmerged updates should be written into an issue with reasoning and details to follow up in future.
+*   These pull requests should not be closed without careful consideration. Unmerged updates should be written into an issue with reasoning and details to follow up in future.

patterns/docs/GitHub Repository Best Practices/GitHub Repository Best Practices.md

@@ -1,32 +1,14 @@
 ---
 sidebar_position: 3
 ---
-Status
-
-Document
-
-Stakeholders
-
-NRIDS Architecture, Development & Digital Services, NRM Product Teams
-
-Description
-
-The purpose of this page is to outline practices when using GitHub as your source code repository
-
-Outcome
-
-Consistent point of reference for onboarding new product teams into the NRM's.
-
-Owner
-
-NRIDS (DDS, Architecture)
+<table class="wrapped"><colgroup></colgroup><tbody><tr><th>Status</th><td><div class="content-wrapper"><p>Document</p></div></td></tr><tr><th>Stakeholders</th><td>NRIDS Architecture, Development &amp; Digital Services, NRM Product Teams</td></tr><tr><th>Description</th><td>The purpose of this page is to outline practices when using GitHub as your source code repository</td></tr><tr><th>Outcome</th><td>Consistent point of reference for onboarding new product teams into the NRM's.</td></tr><tr><th>Owner</th><td>NRIDS (DDS, Architecture)</td></tr></tbody></table>
 
 Repository Setup
-================
+----------------
 
 The below options are found under settings
 
-**Branch Protection**
+### **Branch Protection**
 
 Create at least 1 branch protection rule for your "main" branch that;
 
@@ -35,7 +17,7 @@ Create at least 1 branch protection rule for your "main" branch that;
 
 Note: Admins can bypass this
 
-*   Enforces status checks to be passed before merging, this should include;  
+*   Enforces status checks to be passed before merging, this should include;
     *   SonarCloud (vulnerability, code coverage)
     *   Code scanning (Trivy, Snyk, CodeQL)
     *   Builds
@@ -47,17 +29,17 @@ Note: Admins can bypass this
 
 *   Ensures branches are up to date before merging
 
-**Manage Your Administrators**
+### **Manage Your Administrators**
 
 *   Have at least 1 backup administrator
 *   Have as few admins as possible, most developers will not need to be an admin
 
-**Manage Your Team**
+### **Manage Your Team**
 
 *   Create a Team in GitHub and Manage the permission in the team. ([https://github.com/orgs/bcgov/teams](https://github.com/orgs/bcgov/teams))
 *   This way if the single team is working on multiple products, authorization will be easier to manage and tracking will be easier.
 
-**Setup Your Pull Request Repository Settings (Very Useful to Help Ensure Guidelines are Followed)**
+### **Setup Your Pull Request Repository Settings (Very Useful to Help Ensure Guidelines are Followed)**
 
 *   Use squash merging to keep histories clean
     *   We recommend using pull request titles
@@ -70,7 +52,7 @@ Note: Admins can bypass this
 
 For additional PR, Pipeline, and Deployment practices: See
 
-**Create Repository Documentation**
+### **Create Repository Documentation**
 
 *   Create a meaningful Readme.md, see [https://github.com/bcgov/BC-Policy-Framework-For-GitHub/blob/master/BC-Gov-Org-HowTo/SAMPLE-README.md](https://github.com/bcgov/BC-Policy-Framework-For-GitHub/blob/master/BC-Gov-Org-HowTo/SAMPLE-README.md)
 *   Add a license and other required documentation, see [https://docs.developer.gov.bc.ca/required-pages-for-github-repository/](https://docs.developer.gov.bc.ca/required-pages-for-github-repository/)
@@ -79,17 +61,17 @@ For additional PR, Pipeline, and Deployment practices: See
     *   If you're going to use the Wiki make sure you add a reference to it in your Readme.md
 *   Create a reference in confluence to your repository and documentation
 
-**GitHub Wiki - Suggestions of What to Add**
+### **GitHub Wiki - Suggestions of What to Add**
 
 *   Points of Contact
 *   How-To's:
     *   Running Locally
     *   Developer Practices
     *   Coding Practices
     *   Ticket management
-    *   Backup and restore 
+    *   Backup and restore
 *   Application process flows
 
-**Handle Your Secrets and Environment Variables**
+### **Handle Your Secrets and Environment Variables**
 
 See