Adding or updating the confluence pages

confluence/pages/GitHub_Repository_Best_Practices/README.md

@@ -1 +1 @@
-<table class="wrapped"><colgroup><col /><col /></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><h1>Repository Setup</h1><p>The below options are found under settings</p><p><strong>Branch Protection</strong></p><p>Create at least 1 branch protection rule for your &quot;main&quot; branch that;</p><ul><li>Forces an approval before merging to your &quot;main&quot; branch<ul><li>An approver should be someone able to understand the code changes and has the authority to approve code changes and pipeline activities associated with a PR Merge (Eg. Data Custodian and Test/Prod deployments)</li></ul></li></ul><p>Note: Admins can bypass this</p><p><ac:image ac:height="250"><ri:attachment ri:filename="image2023-8-8_9-12-55.png" /></ac:image></p><ul><li>Enforces status checks to be passed before merging, this should include;<br /><ul><li>SonarCloud (vulnerability, code coverage)</li><li>Code scanning (Trivy, Snyk, CodeQL)</li><li>Builds</li><li>Deployments</li><li>Route verification (up/down, penetration testing)</li></ul></li><li>Note: checks need to have been run once to populate the drop-down</li></ul><p>(Ensure you select your options below when enabling the rule)</p><p><ac:image ac:height="97"><ri:attachment ri:filename="image2023-8-8_9-18-27.png" /></ac:image></p><ul><li>Ensures branches are up to date before merging</li></ul><p><ac:image ac:height="72"><ri:attachment ri:filename="image2023-8-8_9-18-42.png" /></ac:image></p><p><strong>Manage Your Administrators</strong></p><ul><li>Have at least 1 backup administrator</li><li>Have as few admins as possible, most developers will not need to be an admin</li></ul><p><strong>Manage Your Team</strong></p><ul><li>Create a Team in GitHub and Manage the permission in the team. (<a href="https://github.com/orgs/bcgov/teams">https://github.com/orgs/bcgov/teams</a>)</li><li>This way if the single team is working on multiple products, authorization will be easier to manage and tracking will be easier.</li></ul><p><strong>Setup Your Pull Request Repository Settings (Very Useful to Help Ensure Guidelines are Followed)</strong></p><ul><li>Use squash merging to keep histories clean<ul><li>We recommend using pull request titles</li></ul></li><li>Suggest updating pull requests<ul><li>Being up to date is required (see above)</li><li>Selecting this will add an easy update button to PRs</li></ul></li><li>Automatically delete head branches, which are merged feature branches<ul><li>Excessive numbers of branches can degrade performance and increase clone times</li><li>Long lived-branches are strongly discouraged</li></ul></li></ul><p><ac:image><ri:attachment ri:filename="prdeets.png" /></ac:image></p><p>For additional PR, Pipeline, and Deployment practices: See <ac:link><ri:page ri:content-title="Coding Patterns &amp; Practices" /></ac:link></p><p><strong>Create Repository Documentation</strong></p><ul><li>Create a meaningful Readme.md, see <a style="text-align: left;" href="https://github.com/bcgov/BC-Policy-Framework-For-GitHub/blob/master/BC-Gov-Org-HowTo/SAMPLE-README.md" rel="nofollow">https://github.com/bcgov/BC-Policy-Framework-For-GitHub/blob/master/BC-Gov-Org-HowTo/SAMPLE-README.md</a></li><li>Add a license and other required documentation, see <a style="text-align: left;" href="https://docs.developer.gov.bc.ca/required-pages-for-github-repository/" rel="nofollow">https://docs.developer.gov.bc.ca/required-pages-for-github-repository/</a></li><li>Make use of the GitHub Wiki<ul><li>The GitHub Wiki provides version controlled documentation that multiple people can edit and does not require technical expertise</li><li>If you're going to use the Wiki make sure you add a reference to it in your Readme.md</li></ul></li><li>Create a reference in confluence to your repository and documentation</li></ul><p><strong>GitHub Wiki - Suggestions of What to Add</strong></p><ul><li>Points of Contact</li><li>How-To's:<ul><li>Running Locally</li><li>Developer Practices</li><li>Coding Practices</li><li>Ticket management</li><li>Backup and restore </li></ul></li><li>Application process flows</li></ul><p><strong>Handle Your Secrets and Environment Variables</strong></p><p>See <ac:link><ri:page ri:content-title="Coding Patterns &amp; Practices" /></ac:link></p><p><br /></p><p><br /></p><p><br /></p><p><br /></p>
+<table class="wrapped"><colgroup><col /><col /></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><h2>Repository Setup</h2><p>The below options are found under settings</p><h3><strong>Branch Protection</strong></h3><p>Create at least 1 branch protection rule for your &quot;main&quot; branch that;</p><ul><li>Forces an approval before merging to your &quot;main&quot; branch<ul><li>An approver should be someone able to understand the code changes and has the authority to approve code changes and pipeline activities associated with a PR Merge (Eg. Data Custodian and Test/Prod deployments)</li></ul></li></ul><p>Note: Admins can bypass this</p><p><ac:image ac:height="250"><ri:attachment ri:filename="image2023-8-8_9-12-55.png" /></ac:image></p><ul><li>Enforces status checks to be passed before merging, this should include;<br /><ul><li>SonarCloud (vulnerability, code coverage)</li><li>Code scanning (Trivy, Snyk, CodeQL)</li><li>Builds</li><li>Deployments</li><li>Route verification (up/down, penetration testing)</li></ul></li><li>Note: checks need to have been run once to populate the drop-down</li></ul><p>(Ensure you select your options below when enabling the rule)</p><p><ac:image ac:height="97"><ri:attachment ri:filename="image2023-8-8_9-18-27.png" /></ac:image></p><ul><li>Ensures branches are up to date before merging</li></ul><p><ac:image ac:height="72"><ri:attachment ri:filename="image2023-8-8_9-18-42.png" /></ac:image></p><h3><strong>Manage Your Administrators</strong></h3><ul><li>Have at least 1 backup administrator</li><li>Have as few admins as possible, most developers will not need to be an admin</li></ul><h3><strong>Manage Your Team</strong></h3><ul><li>Create a Team in GitHub and Manage the permission in the team. (<a href="https://github.com/orgs/bcgov/teams">https://github.com/orgs/bcgov/teams</a>)</li><li>This way if the single team is working on multiple products, authorization will be easier to manage and tracking will be easier.</li></ul><h3><strong>Setup Your Pull Request Repository Settings (Very Useful to Help Ensure Guidelines are Followed)</strong></h3><ul><li>Use squash merging to keep histories clean<ul><li>We recommend using pull request titles</li></ul></li><li>Suggest updating pull requests<ul><li>Being up to date is required (see above)</li><li>Selecting this will add an easy update button to PRs</li></ul></li><li>Automatically delete head branches, which are merged feature branches<ul><li>Excessive numbers of branches can degrade performance and increase clone times</li><li>Long lived-branches are strongly discouraged</li></ul></li></ul><p><ac:image><ri:attachment ri:filename="prdeets.png" /></ac:image></p><p>For additional PR, Pipeline, and Deployment practices: See <ac:link><ri:page ri:content-title="Coding Patterns &amp; Practices" /></ac:link></p><h3><strong>Create Repository Documentation</strong></h3><ul><li>Create a meaningful Readme.md, see <a href="https://github.com/bcgov/BC-Policy-Framework-For-GitHub/blob/master/BC-Gov-Org-HowTo/SAMPLE-README.md" style="text-align: left;" rel="nofollow">https://github.com/bcgov/BC-Policy-Framework-For-GitHub/blob/master/BC-Gov-Org-HowTo/SAMPLE-README.md</a></li><li>Add a license and other required documentation, see <a href="https://docs.developer.gov.bc.ca/required-pages-for-github-repository/" style="text-align: left;" rel="nofollow">https://docs.developer.gov.bc.ca/required-pages-for-github-repository/</a></li><li>Make use of the GitHub Wiki<ul><li>The GitHub Wiki provides version controlled documentation that multiple people can edit and does not require technical expertise</li><li>If you're going to use the Wiki make sure you add a reference to it in your Readme.md</li></ul></li><li>Create a reference in confluence to your repository and documentation</li></ul><h3><strong>GitHub Wiki - Suggestions of What to Add</strong></h3><ul><li>Points of Contact</li><li>How-To's:<ul><li>Running Locally</li><li>Developer Practices</li><li>Coding Practices</li><li>Ticket management</li><li>Backup and restore </li></ul></li><li>Application process flows</li></ul><h3><strong>Handle Your Secrets and Environment Variables</strong></h3><p>See <ac:link><ri:page ri:content-title="Coding Patterns &amp; Practices" /></ac:link></p><p><br /></p><p><br /></p><p><br /></p><p><br /></p>