From 2aff76517e858fcf4db5d6f40f933d33577993f3 Mon Sep 17 00:00:00 2001 From: mishraomp Date: Fri, 19 Jan 2024 00:33:14 +0000 Subject: [PATCH] Adding or updating the confluence pages --- confluence/pages/Agile_Team_Kickstarter/README.md | 2 +- confluence/pages/Agile_Team_Kickstarter/data.json | 2 +- confluence/pages/Coding_Patterns_&_Practices/README.md | 2 +- confluence/pages/Coding_Patterns_&_Practices/data.json | 2 +- confluence/pages/GitHub_Repository_Best_Practices/README.md | 2 +- confluence/pages/GitHub_Repository_Best_Practices/data.json | 2 +- confluence/pages/Source_Code_Repositories/README.md | 2 +- confluence/pages/Source_Code_Repositories/data.json | 2 +- 8 files changed, 8 insertions(+), 8 deletions(-) diff --git a/confluence/pages/Agile_Team_Kickstarter/README.md b/confluence/pages/Agile_Team_Kickstarter/README.md index 74f032d..b90ad46 100644 --- a/confluence/pages/Agile_Team_Kickstarter/README.md +++ b/confluence/pages/Agile_Team_Kickstarter/README.md @@ -1 +1 @@ -
Status

Document

StakeholdersNRIDS Architecture, Development & Digital Services, NRM Product Teams
DescriptionThe purpose of this page is to outline some of the key information and connections that product teams should be made aware of as part of team inception.  This is a living and collaborative document.
OutcomeConsistent point of reference for onboarding new product teams into the NRM's.
OwnerNRIDS (DDS, Architecture)

Partnership Agreement

NRM teams that work within our Development and Digital Services (DDS) branch start with a partnership agreement to ensure alignment between NRIDS and the program area.

NRM Digital Service Delivery Partnership Agreement 

Team Agreement

Before starting development, or when new team members begin contributing, ensure everyone on the team has the same understanding about coding practices, technology choices, and roles within your team. This is typically done during sprint 0.

Coding Patterns and Practices

Product Lifecycle

Is your team replacing, re-architecting or re-platforming an existing application?  If so, it's the Product Owner's responsibility to ensure the existing application is retired and the data is transitioned or preserved to ensure data quality, accuracy and currency as well as overall portfolio sustainability. Product Owners may reach out to their assigned Ministry Portfolio Manager (MPM) for assistance with the Application Retirement process.

Ensure you allocate time and budget in your backlog to manage the overall lifecycle of the business processes, data and associated products.

Helpful links on Application Retirement:

Private Cloud

The BC Government has invested heavily in the Red Hat OpenShift platform to provide self service private cloud capabilities.  Training is available through the exchange lab to get teams acquainted with the platform; a good primer is here.

https://developer.gov.bc.ca/ExchangeLab-Course:-OpenShift-101

The landing page for the private cloud service is here: https://cloud.gov.bc.ca/private-cloud/

Namespace provisioning can be found here: https://registry.developer.gov.bc.ca/public-landing

Information on resource tuning for OpenShift Namespaces can be found here: https://beta-docs.developer.gov.bc.ca/application-resource-tuning/

The RedHat learning portal is a great resource to learn more about the platform, and they also provide a sandbox to 'learn by doing'.

Some of the more important concepts to understand up front are:

OpenShift QuickStart Application

Our friends and collaborators in the Forestry Suite of Applications Modernization Program and Architecture team have created an application template that includes pluggable API backends (Node/Nest, Python/FastAPI, Go/Fiber, Java/Quarkus) and frontend(React, Vite), with a deployment pipeline to the OpenShift platform with an option to include a PostgreSQL/PostGIS database and leveraging the backup container provided by the BC DevExchange.  This is a great resource to get product teams up and running.

QuickStart OpenShift

Public Cloud

BC Government has endorsed several public cloud services and provides quickstart guides and sample applications!

https://www2.gov.bc.ca/gov/content/governments/services-for-government/cloud-computing-in-the-bc-government#explore

Approved AWS services can be found here: https://developer.gov.bc.ca/AWS-Services

GitHub

Source code should be stored in a GitHub repository in the "bcgov" tenancy.

Access management for the bcgov GitHub tenancy can be found here: https://just-ask.developer.gov.bc.ca/

NRM specific guidance on Github is here: Source Code Repositories

Authentication and Identity

Most NRM digital products leverage the OCIO SSO service that is backed by Keycloak.

https://bcgov.github.io/sso-requests

https://oidc.gov.bc.ca/auth/

Secrets Management

The platform services team operates a Vault service. 

It is described here:  https://beta-docs.developer.gov.bc.ca/vault-secrets-management-service/

Access to the service is here: https://vault.developer.gov.bc.ca/ui/vault/auth?with=token

Security and Privacy

It's important that teams engage with the NRM Security and Privacy teams early and often.  They can support you with general advice as well as Security Threat Risk Assessments (STRA's) and Privacy Impact Assessments (PIA's).

NRM Security Knowledge Base: NRM Information Security Home

NRM Privacy Knowledge Base: NRM Privacy Knowledge Base

OWASP (Open Web Application Security Project) is another great reference for security best practices for development teams: https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/migrated_content

CI/CD

The deployment pipeline is a key component for your application.  For visibility, collaboration and maintainability modern teams are moving away from Jenkins towards GitHub actions.

It is strongly recommended that code be submitted using a Pull Request.  Automated testing can and should replace manual UAT wherever practical.

NRM has a modern CI/CD template using GitHub Actions:  OpenShift QuickStart . This offering is currently limited OpenShift Silver or Gold Cluster.

Application Programming Interfaces (API's)

We recommend adopting an "API First" philosophy for application development, where teams both build and consume their API's. Providing API specification with proper metadata is mandatory irrespective of the underlying implementation(REST, graphql, grpc etc..)

Along with API first approach the Architecture team highly recommends looking at Domain Driven Design(DDD) where each micro-service API is bounded by its business domain(https://martinfowler.com/bliki/DomainDrivenDesign.html)

Also look at Event-Driven Architecture (Event Sourcing and CQRS) when building micro-services as it promotes highly decoupled APIS, communicating over an event streaming platform (https://microservices.io/patterns/data/event-sourcing.html, https://microservices.io/patterns/data/cqrs.html)

We recommend a Test Driven Development (TDD) approach to API development, as it makes the application code more reliable and efficient along with easier maintenance in the future.

There are several ways to name test methods/functions but we recommend using the pattern test<method_name>_<given_condition>_<expected_behavior>, it makes the tests more readable, predictable and becomes living documentation of the codebase.

BC Government has published a set of API Guidelines here: https://developer.gov.bc.ca/Data-and-APIs/BC-Government-API-Guidelines

Information on the corporate API gateway can be found here:  https://bcgov.github.io/aps-infra-platform/


Database and Data Design

Most of the teams working on OpenShift are choosing a flavor of PostgreSQL to persist data for their application.

Some points of consideration are:

For NRM guidance specific to data and database design, please visit this space: NRM Data and Database Development Guidelines

Database backups can be setup using the backup container image; information can be found here: https://developer.gov.bc.ca/Backup-Container

Indigenous Languages: the BC Government is committed to including Indigenous languages in government records, systems and services.  The BC Sans font is an open-source "living" typeface developed for government to improve the readability and delivery of digital services.  It was designed to support special characters and syllabics found in Indigenous Languages in B.C.  When designing and building your product, ensure it has the ability to collect, store, manage and display BC Sans characters.  Connect with your architects for more details and references.

Document Storage

BC Government has an on premise object storage solution that delivers low cost storage for unstructured and semi-structured data.  The service is billed monthly to the highwatermark of the storage your team consumes in their S3 bucket at $0.07/GB/Month.  To get an S3 object storage bucket, contact the Optimize team.

COMS (Common Object Management Service) is an emerging common component that leverages the object storage solution.  The advantage of this component is that it includes the ability to tag and add metadata, and integrates with BC Government's standard identity providers (IDIR, BCeID).  To learn more, attend the Common Services Showcase team sprint reviews or contact the team via email.

An emerging companion to the Common Object Management Service being built by the Common Services team is BCBox, which is a hosted solution that uses the COMS API to allow users to upload, tag and share files using any OIDC compliant authentication mechanism.  The code repository for BCBox can be found here.

Design Guidance

General resources for Agile designers at Digital Government (BC Visual Identity, Official BC Design System, Web Style Guide, Content Design Guidance, UX Research Guidance, Service Design Playbook) can be found here:

https://digital.gov.bc.ca/resources#:~:text=Read%20the%20playbook-,For%20Designers,-B.C.%20Visual

Additional design system guidance: https://developer.gov.bc.ca/Design-System/About-the-Design-System

BC Parks has extended their Design Guide to include the use of the BC Sans font and other additions specific to their program:

https://bcgov.github.io/bcparks/design-guides

Front End Frameworks

Many agile teams are using a flavor of Javascript framework for their front end development (Angular, Vue, React etc).  We recommend you pick the framework that works best for the team, and if you are developing a suite of applications for your program area, harmonize across the suite where that makes sense.  This will minimize risk associated with changes to the team and enable other developers to work with your code.

Web Mapping Frameworks

A comparison of web mapping frameworks in use in BC Government can found here: https://bcgov.github.io/bcwebmaps-options/

Back End Languages

Similar to front end frameworks, we recommend you choose a development language that best suits the team and the business challenge you are working on.  If you are developing a suite of applications for your program area, harmonize across the suite where that makes sense.  This will minimize risk associated with changes to the team and enable other developers to work with your code. 

There are many languages in use by agile teams across government, the most popular being Go, Python, Java, Javascript and Typescript.  The Technology Radar is a great reference to see where the momentum is around languages and frameworks.

Web Domains and Certificates

Information on NRM Web Domains can be found here: Web-Application domains

An example of a public facing URL is https://fom.nrs.gov.bc.ca/public/projects

Information on how to obtain an SSL certificate can be found here: Automation of TLS Certificates for Websites

Further information on security certificates can be found here: Security Certificates

Information on certbot can be found here: https://github.com/BCDevOps/certbot

Common Components

BC Government has a selection of mature common components and common services.

Digital Government reference: https://digital.gov.bc.ca/common-components

NRM Specific Guidance: Common Components and Common Services

Community Tip!  If you are looking for a common component you think should exist, but doesn't, consider adding some extra design thinking such that other teams can reuse your great work!

Reporting and Analytics

Many teams require reporting and analytics capabilities for their application data.  Metabase is an easy-to-use open-source dashboarding and business intelligence tool that has broad usage in the NRM.  Architecture has created a packaged install of Metabase tailored to teams wanting secure access to Zone B Oracle databases.

https://github.com/bcgov/nr-arch-templates/tree/main/Metabase

I need help from the Community!

There are many teams working across the NRM and beyond.  To connect with your NRM colleagues, see the team directory here NRIDS Development and Digital Services

The community uses Rocket.Chat to solicit help from other teams on all sorts of subjects.  Users can authenticate with IDIR or their GitHub ID.

https://chat.developer.gov.bc.ca/

Channels of interest might include #general #devops-alerts #devops-operations #nr-iitd-agile-teams and any channel prefixed with "#nr-"

The NRM teams have a DevOps Guild to facilitate connections and collaboration between teams: https://apps.nrs.gov.bc.ca/int/confluence/display/DEVGUILD

You can also reach out to the NRM Architecture team, who can help connect your team with the right resources.

Key References:

BC DevHub: https://developer.gov.bc.ca, https://docs.developer.gov.bc.ca/

Common Components: https://digital.gov.bc.ca/common-components

Communities of Practice: https://digital.gov.bc.ca/communities

BC Gov StackOverflow: https://stackoverflow.developer.gov.bc.ca/

FAQ

Q. Do I need my application and data architecture to be formally approved?

A. No, there is no formal approval process for your architecture.  We recommend collaborating with the architecture team during any architectural spikes or any significant architectural decisions.  Our collective experience and connectedness across the community can typically provide value for the team.


Q. Do I have to use OpenShift to host my application?

A. No.  We would generally like new applications to be running in a containerized or serverless hosting architecture.  OpenShift is a strong option for teams starting out given the maturity of the platform and the surrounding community, as is the AWS Public Cloud Service, both operated by BC Government teams.  Following cloud native design principles will help ensure that your application workload is portable between hosting platforms.


Q. Can I pass my application off to an ops team so the team can work on new apps?

A. We generally follow the "you build it, you run it" philosophy, and therefore recommend you build a sustainment plan into your application roadmap.  Adhering as closely as possible to the 12 Factor principles is a great way to promote a sustainable, cloud native build.



\ No newline at end of file +

This page has been replicated to a publicly accessible website located here


Status

Document

StakeholdersNRIDS Architecture, Development & Digital Services, NRM Product Teams
DescriptionThe purpose of this page is to outline some of the key information and connections that product teams should be made aware of as part of team inception.  This is a living and collaborative document.
OutcomeConsistent point of reference for onboarding new product teams into the NRM's.
OwnerNRIDS (DDS, Architecture)


Partnership Agreement

NRM teams that work within our Development and Digital Services (DDS) branch start with a partnership agreement to ensure alignment between NRIDS and the program area.

NRM Digital Service Delivery Partnership Agreement 

Team Agreement

Before starting development, or when new team members begin contributing, ensure everyone on the team has the same understanding about coding practices, technology choices, and roles within your team. This is typically done during sprint 0.

Coding Patterns and Practices

Product Lifecycle

Is your team replacing, re-architecting or re-platforming an existing application?  If so, it's the Product Owner's responsibility to ensure the existing application is retired and the data is transitioned or preserved to ensure data quality, accuracy and currency as well as overall portfolio sustainability. Product Owners may reach out to their assigned Ministry Portfolio Manager (MPM) for assistance with the Application Retirement process.

Ensure you allocate time and budget in your backlog to manage the overall lifecycle of the business processes, data and associated products.

Helpful links on Application Retirement:

Private Cloud

The BC Government has invested heavily in the Red Hat OpenShift platform to provide self service private cloud capabilities.  Training is available through the exchange lab to get teams acquainted with the platform; a good primer is here.

https://developer.gov.bc.ca/ExchangeLab-Course:-OpenShift-101

The landing page for the private cloud service is here: https://cloud.gov.bc.ca/private-cloud/

Namespace provisioning can be found here: https://registry.developer.gov.bc.ca/public-landing

Information on resource tuning for OpenShift Namespaces can be found here: https://beta-docs.developer.gov.bc.ca/application-resource-tuning/

The RedHat learning portal is a great resource to learn more about the platform, and they also provide a sandbox to 'learn by doing'.

Some of the more important concepts to understand up front are:

OpenShift QuickStart Application

Our friends and collaborators in the Forestry Suite of Applications Modernization Program and Architecture team have created an application template that includes pluggable API backends (Node/Nest, Python/FastAPI, Go/Fiber, Java/Quarkus) and frontend(React, Vite), with a deployment pipeline to the OpenShift platform with an option to include a PostgreSQL/PostGIS database and leveraging the backup container provided by the BC DevExchange.  This is a great resource to get product teams up and running.

QuickStart OpenShift

Public Cloud

BC Government has endorsed several public cloud services and provides quickstart guides and sample applications!

https://www2.gov.bc.ca/gov/content/governments/services-for-government/cloud-computing-in-the-bc-government#explore

Approved AWS services can be found here: https://developer.gov.bc.ca/AWS-Services

GitHub

Source code should be stored in a GitHub repository in the "bcgov" tenancy.

Access management for the bcgov GitHub tenancy can be found here: https://just-ask.developer.gov.bc.ca/

NRM specific guidance on Github is here: Source Code Repositories

Authentication and Identity

Most NRM digital products leverage the OCIO SSO service that is backed by Keycloak.

https://bcgov.github.io/sso-requests

https://oidc.gov.bc.ca/auth/

Secrets Management

The platform services team operates a Vault service. 

It is described here:  https://beta-docs.developer.gov.bc.ca/vault-secrets-management-service/

Access to the service is here: https://vault.developer.gov.bc.ca/ui/vault/auth?with=token

Security and Privacy

It's important that teams engage with the NRM Security and Privacy teams early and often.  They can support you with general advice as well as Security Threat Risk Assessments (STRA's) and Privacy Impact Assessments (PIA's).

NRM Security Knowledge Base: NRM Information Security Home

NRM Privacy Knowledge Base: NRM Privacy Knowledge Base

OWASP (Open Web Application Security Project) is another great reference for security best practices for development teams: https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/migrated_content

CI/CD

The deployment pipeline is a key component for your application.  For visibility, collaboration and maintainability modern teams are moving away from Jenkins towards GitHub actions.

It is strongly recommended that code be submitted using a Pull Request.  Automated testing can and should replace manual UAT wherever practical.

NRM has a modern CI/CD template using GitHub Actions:  OpenShift QuickStart . This offering is currently limited OpenShift Silver or Gold Cluster.

Application Programming Interfaces (API's)

We recommend adopting an "API First" philosophy for application development, where teams both build and consume their API's. Providing API specification with proper metadata is mandatory irrespective of the underlying implementation(REST, graphql, grpc etc..)

Along with API first approach the Architecture team highly recommends looking at Domain Driven Design(DDD) where each micro-service API is bounded by its business domain(https://martinfowler.com/bliki/DomainDrivenDesign.html)

Also look at Event-Driven Architecture (Event Sourcing and CQRS) when building micro-services as it promotes highly decoupled APIS, communicating over an event streaming platform (https://microservices.io/patterns/data/event-sourcing.html, https://microservices.io/patterns/data/cqrs.html)

We recommend a Test Driven Development (TDD) approach to API development, as it makes the application code more reliable and efficient along with easier maintenance in the future.

There are several ways to name test methods/functions but we recommend using the pattern test<method_name>_<given_condition>_<expected_behavior>, it makes the tests more readable, predictable and becomes living documentation of the codebase.

BC Government has published a set of API Guidelines here: https://developer.gov.bc.ca/Data-and-APIs/BC-Government-API-Guidelines

Information on the corporate API gateway can be found here:  https://bcgov.github.io/aps-infra-platform/


Database and Data Design

Most of the teams working on OpenShift are choosing a flavor of PostgreSQL to persist data for their application.

Some points of consideration are:

For NRM guidance specific to data and database design, please visit this space: NRM Data and Database Development Guidelines

Database backups can be setup using the backup container image; information can be found here: https://developer.gov.bc.ca/Backup-Container

Indigenous Languages: the BC Government is committed to including Indigenous languages in government records, systems and services.  The BC Sans font is an open-source "living" typeface developed for government to improve the readability and delivery of digital services.  It was designed to support special characters and syllabics found in Indigenous Languages in B.C.  When designing and building your product, ensure it has the ability to collect, store, manage and display BC Sans characters.  Connect with your architects for more details and references.

Document Storage

BC Government has an on premise object storage solution that delivers low cost storage for unstructured and semi-structured data.  The service is billed monthly to the highwatermark of the storage your team consumes in their S3 bucket at $0.07/GB/Month.  To get an S3 object storage bucket, contact the Optimize team.

COMS (Common Object Management Service) is an emerging common component that leverages the object storage solution.  The advantage of this component is that it includes the ability to tag and add metadata, and integrates with BC Government's standard identity providers (IDIR, BCeID).  To learn more, attend the Common Services Showcase team sprint reviews or contact the team via email.

An emerging companion to the Common Object Management Service being built by the Common Services team is BCBox, which is a hosted solution that uses the COMS API to allow users to upload, tag and share files using any OIDC compliant authentication mechanism.  The code repository for BCBox can be found here.

Design Guidance

General resources for Agile designers at Digital Government (BC Visual Identity, Official BC Design System, Web Style Guide, Content Design Guidance, UX Research Guidance, Service Design Playbook) can be found here:

https://digital.gov.bc.ca/resources#:~:text=Read%20the%20playbook-,For%20Designers,-B.C.%20Visual

Additional design system guidance: https://developer.gov.bc.ca/Design-System/About-the-Design-System

BC Parks has extended their Design Guide to include the use of the BC Sans font and other additions specific to their program:

https://bcgov.github.io/bcparks/design-guides

Front End Frameworks

Many agile teams are using a flavor of Javascript framework for their front end development (Angular, Vue, React etc).  We recommend you pick the framework that works best for the team, and if you are developing a suite of applications for your program area, harmonize across the suite where that makes sense.  This will minimize risk associated with changes to the team and enable other developers to work with your code.

Web Mapping Frameworks

A comparison of web mapping frameworks in use in BC Government can found here: https://bcgov.github.io/bcwebmaps-options/

Back End Languages

Similar to front end frameworks, we recommend you choose a development language that best suits the team and the business challenge you are working on.  If you are developing a suite of applications for your program area, harmonize across the suite where that makes sense.  This will minimize risk associated with changes to the team and enable other developers to work with your code. 

There are many languages in use by agile teams across government, the most popular being Go, Python, Java, Javascript and Typescript.  The Technology Radar is a great reference to see where the momentum is around languages and frameworks.

Web Domains and Certificates

Information on NRM Web Domains can be found here: Web-Application domains

An example of a public facing URL is https://fom.nrs.gov.bc.ca/public/projects

Information on how to obtain an SSL certificate can be found here: Automation of TLS Certificates for Websites

Further information on security certificates can be found here: Security Certificates

Information on certbot can be found here: https://github.com/BCDevOps/certbot

Common Components

BC Government has a selection of mature common components and common services.

Digital Government reference: https://digital.gov.bc.ca/common-components

NRM Specific Guidance: Common Components and Common Services

Community Tip!  If you are looking for a common component you think should exist, but doesn't, consider adding some extra design thinking such that other teams can reuse your great work!

Reporting and Analytics

Many teams require reporting and analytics capabilities for their application data.  Metabase is an easy-to-use open-source dashboarding and business intelligence tool that has broad usage in the NRM.  Architecture has created a packaged install of Metabase tailored to teams wanting secure access to Zone B Oracle databases.

https://github.com/bcgov/nr-arch-templates/tree/main/Metabase

I need help from the Community!

There are many teams working across the NRM and beyond.  To connect with your NRM colleagues, see the team directory here NRIDS Development and Digital Services

The community uses Rocket.Chat to solicit help from other teams on all sorts of subjects.  Users can authenticate with IDIR or their GitHub ID.

https://chat.developer.gov.bc.ca/

Channels of interest might include #general #devops-alerts #devops-operations #nr-iitd-agile-teams and any channel prefixed with "#nr-"

The NRM teams have a DevOps Guild to facilitate connections and collaboration between teams: https://apps.nrs.gov.bc.ca/int/confluence/display/DEVGUILD

You can also reach out to the NRM Architecture team, who can help connect your team with the right resources.

Key References:

BC DevHub: https://developer.gov.bc.ca, https://docs.developer.gov.bc.ca/

Common Components: https://digital.gov.bc.ca/common-components

Communities of Practice: https://digital.gov.bc.ca/communities

BC Gov StackOverflow: https://stackoverflow.developer.gov.bc.ca/

FAQ

Q. Do I need my application and data architecture to be formally approved?

A. No, there is no formal approval process for your architecture.  We recommend collaborating with the architecture team during any architectural spikes or any significant architectural decisions.  Our collective experience and connectedness across the community can typically provide value for the team.


Q. Do I have to use OpenShift to host my application?

A. No.  We would generally like new applications to be running in a containerized or serverless hosting architecture.  OpenShift is a strong option for teams starting out given the maturity of the platform and the surrounding community, as is the AWS Public Cloud Service, both operated by BC Government teams.  Following cloud native design principles will help ensure that your application workload is portable between hosting platforms.


Q. Can I pass my application off to an ops team so the team can work on new apps?

A. We generally follow the "you build it, you run it" philosophy, and therefore recommend you build a sustainment plan into your application roadmap.  Adhering as closely as possible to the 12 Factor principles is a great way to promote a sustainable, cloud native build.



\ No newline at end of file diff --git a/confluence/pages/Agile_Team_Kickstarter/data.json b/confluence/pages/Agile_Team_Kickstarter/data.json index 027829f..25826ca 100644 --- a/confluence/pages/Agile_Team_Kickstarter/data.json +++ b/confluence/pages/Agile_Team_Kickstarter/data.json @@ -1 +1 @@ -{"id":"120392107","type":"page","status":"current","title":"Agile Team Kickstarter","body":{"storage":{"value":"
Status

Document

StakeholdersNRIDS Architecture, Development & Digital Services, NRM Product Teams
DescriptionThe purpose of this page is to outline some of the key information and connections that product teams should be made aware of as part of team inception.  This is a living and collaborative document.
OutcomeConsistent point of reference for onboarding new product teams into the NRM's.
OwnerNRIDS (DDS, Architecture)

Partnership Agreement

NRM teams that work within our Development and Digital Services (DDS) branch start with a partnership agreement to ensure alignment between NRIDS and the program area.

NRM Digital Service Delivery Partnership Agreement 

Team Agreement

Before starting development, or when new team members begin contributing, ensure everyone on the team has the same understanding about coding practices, technology choices, and roles within your team. This is typically done during sprint 0.

Coding Patterns and Practices

Product Lifecycle

Is your team replacing, re-architecting or re-platforming an existing application?  If so, it's the Product Owner's responsibility to ensure the existing application is retired and the data is transitioned or preserved to ensure data quality, accuracy and currency as well as overall portfolio sustainability. Product Owners may reach out to their assigned Ministry Portfolio Manager (MPM) for assistance with the Application Retirement process.

Ensure you allocate time and budget in your backlog to manage the overall lifecycle of the business processes, data and associated products.

Helpful links on Application Retirement:

Private Cloud

The BC Government has invested heavily in the Red Hat OpenShift platform to provide self service private cloud capabilities.  Training is available through the exchange lab to get teams acquainted with the platform; a good primer is here.

https://developer.gov.bc.ca/ExchangeLab-Course:-OpenShift-101

The landing page for the private cloud service is here: https://cloud.gov.bc.ca/private-cloud/

Namespace provisioning can be found here: https://registry.developer.gov.bc.ca/public-landing

Information on resource tuning for OpenShift Namespaces can be found here: https://beta-docs.developer.gov.bc.ca/application-resource-tuning/

The RedHat learning portal is a great resource to learn more about the platform, and they also provide a sandbox to 'learn by doing'.

Some of the more important concepts to understand up front are:

OpenShift QuickStart Application

Our friends and collaborators in the Forestry Suite of Applications Modernization Program and Architecture team have created an application template that includes pluggable API backends (Node/Nest, Python/FastAPI, Go/Fiber, Java/Quarkus) and frontend(React, Vite), with a deployment pipeline to the OpenShift platform with an option to include a PostgreSQL/PostGIS database and leveraging the backup container provided by the BC DevExchange.  This is a great resource to get product teams up and running.

QuickStart OpenShift

Public Cloud

BC Government has endorsed several public cloud services and provides quickstart guides and sample applications!

https://www2.gov.bc.ca/gov/content/governments/services-for-government/cloud-computing-in-the-bc-government#explore

Approved AWS services can be found here: https://developer.gov.bc.ca/AWS-Services

GitHub

Source code should be stored in a GitHub repository in the "bcgov" tenancy.

Access management for the bcgov GitHub tenancy can be found here: https://just-ask.developer.gov.bc.ca/

NRM specific guidance on Github is here: Source Code Repositories

Authentication and Identity

Most NRM digital products leverage the OCIO SSO service that is backed by Keycloak.

https://bcgov.github.io/sso-requests

https://oidc.gov.bc.ca/auth/

Secrets Management

The platform services team operates a Vault service. 

It is described here:  https://beta-docs.developer.gov.bc.ca/vault-secrets-management-service/

Access to the service is here: https://vault.developer.gov.bc.ca/ui/vault/auth?with=token

Security and Privacy

It's important that teams engage with the NRM Security and Privacy teams early and often.  They can support you with general advice as well as Security Threat Risk Assessments (STRA's) and Privacy Impact Assessments (PIA's).

NRM Security Knowledge Base: NRM Information Security Home

NRM Privacy Knowledge Base: NRM Privacy Knowledge Base

OWASP (Open Web Application Security Project) is another great reference for security best practices for development teams: https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/migrated_content

CI/CD

The deployment pipeline is a key component for your application.  For visibility, collaboration and maintainability modern teams are moving away from Jenkins towards GitHub actions.

It is strongly recommended that code be submitted using a Pull Request.  Automated testing can and should replace manual UAT wherever practical.

NRM has a modern CI/CD template using GitHub Actions:  OpenShift QuickStart . This offering is currently limited OpenShift Silver or Gold Cluster.

Application Programming Interfaces (API's)

We recommend adopting an "API First" philosophy for application development, where teams both build and consume their API's. Providing API specification with proper metadata is mandatory irrespective of the underlying implementation(REST, graphql, grpc etc..)

Along with API first approach the Architecture team highly recommends looking at Domain Driven Design(DDD) where each micro-service API is bounded by its business domain(https://martinfowler.com/bliki/DomainDrivenDesign.html)

Also look at Event-Driven Architecture (Event Sourcing and CQRS) when building micro-services as it promotes highly decoupled APIS, communicating over an event streaming platform (https://microservices.io/patterns/data/event-sourcing.html, https://microservices.io/patterns/data/cqrs.html)

We recommend a Test Driven Development (TDD) approach to API development, as it makes the application code more reliable and efficient along with easier maintenance in the future.

There are several ways to name test methods/functions but we recommend using the pattern test<method_name>_<given_condition>_<expected_behavior>, it makes the tests more readable, predictable and becomes living documentation of the codebase.

BC Government has published a set of API Guidelines here: https://developer.gov.bc.ca/Data-and-APIs/BC-Government-API-Guidelines

Information on the corporate API gateway can be found here:  https://bcgov.github.io/aps-infra-platform/


Database and Data Design

Most of the teams working on OpenShift are choosing a flavor of PostgreSQL to persist data for their application.

Some points of consideration are:

For NRM guidance specific to data and database design, please visit this space: NRM Data and Database Development Guidelines

Database backups can be setup using the backup container image; information can be found here: https://developer.gov.bc.ca/Backup-Container

Indigenous Languages: the BC Government is committed to including Indigenous languages in government records, systems and services.  The BC Sans font is an open-source "living" typeface developed for government to improve the readability and delivery of digital services.  It was designed to support special characters and syllabics found in Indigenous Languages in B.C.  When designing and building your product, ensure it has the ability to collect, store, manage and display BC Sans characters.  Connect with your architects for more details and references.

Document Storage

BC Government has an on premise object storage solution that delivers low cost storage for unstructured and semi-structured data.  The service is billed monthly to the highwatermark of the storage your team consumes in their S3 bucket at $0.07/GB/Month.  To get an S3 object storage bucket, contact the Optimize team.

COMS (Common Object Management Service) is an emerging common component that leverages the object storage solution.  The advantage of this component is that it includes the ability to tag and add metadata, and integrates with BC Government's standard identity providers (IDIR, BCeID).  To learn more, attend the Common Services Showcase team sprint reviews or contact the team via email.

An emerging companion to the Common Object Management Service being built by the Common Services team is BCBox, which is a hosted solution that uses the COMS API to allow users to upload, tag and share files using any OIDC compliant authentication mechanism.  The code repository for BCBox can be found here.

Design Guidance

General resources for Agile designers at Digital Government (BC Visual Identity, Official BC Design System, Web Style Guide, Content Design Guidance, UX Research Guidance, Service Design Playbook) can be found here:

https://digital.gov.bc.ca/resources#:~:text=Read%20the%20playbook-,For%20Designers,-B.C.%20Visual

Additional design system guidance: https://developer.gov.bc.ca/Design-System/About-the-Design-System

BC Parks has extended their Design Guide to include the use of the BC Sans font and other additions specific to their program:

https://bcgov.github.io/bcparks/design-guides

Front End Frameworks

Many agile teams are using a flavor of Javascript framework for their front end development (Angular, Vue, React etc).  We recommend you pick the framework that works best for the team, and if you are developing a suite of applications for your program area, harmonize across the suite where that makes sense.  This will minimize risk associated with changes to the team and enable other developers to work with your code.

Web Mapping Frameworks

A comparison of web mapping frameworks in use in BC Government can found here: https://bcgov.github.io/bcwebmaps-options/

Back End Languages

Similar to front end frameworks, we recommend you choose a development language that best suits the team and the business challenge you are working on.  If you are developing a suite of applications for your program area, harmonize across the suite where that makes sense.  This will minimize risk associated with changes to the team and enable other developers to work with your code. 

There are many languages in use by agile teams across government, the most popular being Go, Python, Java, Javascript and Typescript.  The Technology Radar is a great reference to see where the momentum is around languages and frameworks.

Web Domains and Certificates

Information on NRM Web Domains can be found here: Web-Application domains

An example of a public facing URL is https://fom.nrs.gov.bc.ca/public/projects

Information on how to obtain an SSL certificate can be found here: Automation of TLS Certificates for Websites

Further information on security certificates can be found here: Security Certificates

Information on certbot can be found here: https://github.com/BCDevOps/certbot

Common Components

BC Government has a selection of mature common components and common services.

Digital Government reference: https://digital.gov.bc.ca/common-components

NRM Specific Guidance: Common Components and Common Services

Community Tip!  If you are looking for a common component you think should exist, but doesn't, consider adding some extra design thinking such that other teams can reuse your great work!

Reporting and Analytics

Many teams require reporting and analytics capabilities for their application data.  Metabase is an easy-to-use open-source dashboarding and business intelligence tool that has broad usage in the NRM.  Architecture has created a packaged install of Metabase tailored to teams wanting secure access to Zone B Oracle databases.

https://github.com/bcgov/nr-arch-templates/tree/main/Metabase

I need help from the Community!

There are many teams working across the NRM and beyond.  To connect with your NRM colleagues, see the team directory here NRIDS Development and Digital Services

The community uses Rocket.Chat to solicit help from other teams on all sorts of subjects.  Users can authenticate with IDIR or their GitHub ID.

https://chat.developer.gov.bc.ca/

Channels of interest might include #general #devops-alerts #devops-operations #nr-iitd-agile-teams and any channel prefixed with "#nr-"

The NRM teams have a DevOps Guild to facilitate connections and collaboration between teams: https://apps.nrs.gov.bc.ca/int/confluence/display/DEVGUILD

You can also reach out to the NRM Architecture team, who can help connect your team with the right resources.

Key References:

BC DevHub: https://developer.gov.bc.ca, https://docs.developer.gov.bc.ca/

Common Components: https://digital.gov.bc.ca/common-components

Communities of Practice: https://digital.gov.bc.ca/communities

BC Gov StackOverflow: https://stackoverflow.developer.gov.bc.ca/

FAQ

Q. Do I need my application and data architecture to be formally approved?

A. No, there is no formal approval process for your architecture.  We recommend collaborating with the architecture team during any architectural spikes or any significant architectural decisions.  Our collective experience and connectedness across the community can typically provide value for the team.


Q. Do I have to use OpenShift to host my application?

A. No.  We would generally like new applications to be running in a containerized or serverless hosting architecture.  OpenShift is a strong option for teams starting out given the maturity of the platform and the surrounding community, as is the AWS Public Cloud Service, both operated by BC Government teams.  Following cloud native design principles will help ensure that your application workload is portable between hosting platforms.


Q. Can I pass my application off to an ops team so the team can work on new apps?

A. We generally follow the "you build it, you run it" philosophy, and therefore recommend you build a sustainment plan into your application roadmap.  Adhering as closely as possible to the 12 Factor principles is a great way to promote a sustainable, cloud native build.



","representation":"storage","_expandable":{"content":"/rest/api/content/120392107"}},"_expandable":{"editor":"","view":"","export_view":"","styled_view":"","anonymous_export_view":""}},"extensions":{"position":0},"_links":{"webui":"/display/AR/Agile+Team+Kickstarter","edit":"/pages/resumedraft.action?draftId=120392107","tinyui":"/x/qwktBw","collection":"/rest/api/content","base":"https://apps.nrs.gov.bc.ca/int/confluence","context":"/int/confluence","self":"https://apps.nrs.gov.bc.ca/int/confluence/rest/api/content/120392107"},"_expandable":{"container":"/rest/api/space/AR","metadata":"","operations":"","children":"/rest/api/content/120392107/child","restrictions":"/rest/api/content/120392107/restriction/byOperation","history":"/rest/api/content/120392107/history","ancestors":"","version":"","descendants":"/rest/api/content/120392107/descendant","space":"/rest/api/space/AR"}} \ No newline at end of file +{"id":"120392107","type":"page","status":"current","title":"Agile Team Kickstarter","body":{"storage":{"value":"

This page has been replicated to a publicly accessible website located here


Status

Document

StakeholdersNRIDS Architecture, Development & Digital Services, NRM Product Teams
DescriptionThe purpose of this page is to outline some of the key information and connections that product teams should be made aware of as part of team inception.  This is a living and collaborative document.
OutcomeConsistent point of reference for onboarding new product teams into the NRM's.
OwnerNRIDS (DDS, Architecture)


Partnership Agreement

NRM teams that work within our Development and Digital Services (DDS) branch start with a partnership agreement to ensure alignment between NRIDS and the program area.

NRM Digital Service Delivery Partnership Agreement 

Team Agreement

Before starting development, or when new team members begin contributing, ensure everyone on the team has the same understanding about coding practices, technology choices, and roles within your team. This is typically done during sprint 0.

Coding Patterns and Practices

Product Lifecycle

Is your team replacing, re-architecting or re-platforming an existing application?  If so, it's the Product Owner's responsibility to ensure the existing application is retired and the data is transitioned or preserved to ensure data quality, accuracy and currency as well as overall portfolio sustainability. Product Owners may reach out to their assigned Ministry Portfolio Manager (MPM) for assistance with the Application Retirement process.

Ensure you allocate time and budget in your backlog to manage the overall lifecycle of the business processes, data and associated products.

Helpful links on Application Retirement:

Private Cloud

The BC Government has invested heavily in the Red Hat OpenShift platform to provide self service private cloud capabilities.  Training is available through the exchange lab to get teams acquainted with the platform; a good primer is here.

https://developer.gov.bc.ca/ExchangeLab-Course:-OpenShift-101

The landing page for the private cloud service is here: https://cloud.gov.bc.ca/private-cloud/

Namespace provisioning can be found here: https://registry.developer.gov.bc.ca/public-landing

Information on resource tuning for OpenShift Namespaces can be found here: https://beta-docs.developer.gov.bc.ca/application-resource-tuning/

The RedHat learning portal is a great resource to learn more about the platform, and they also provide a sandbox to 'learn by doing'.

Some of the more important concepts to understand up front are:

OpenShift QuickStart Application

Our friends and collaborators in the Forestry Suite of Applications Modernization Program and Architecture team have created an application template that includes pluggable API backends (Node/Nest, Python/FastAPI, Go/Fiber, Java/Quarkus) and frontend(React, Vite), with a deployment pipeline to the OpenShift platform with an option to include a PostgreSQL/PostGIS database and leveraging the backup container provided by the BC DevExchange.  This is a great resource to get product teams up and running.

QuickStart OpenShift

Public Cloud

BC Government has endorsed several public cloud services and provides quickstart guides and sample applications!

https://www2.gov.bc.ca/gov/content/governments/services-for-government/cloud-computing-in-the-bc-government#explore

Approved AWS services can be found here: https://developer.gov.bc.ca/AWS-Services

GitHub

Source code should be stored in a GitHub repository in the "bcgov" tenancy.

Access management for the bcgov GitHub tenancy can be found here: https://just-ask.developer.gov.bc.ca/

NRM specific guidance on Github is here: Source Code Repositories

Authentication and Identity

Most NRM digital products leverage the OCIO SSO service that is backed by Keycloak.

https://bcgov.github.io/sso-requests

https://oidc.gov.bc.ca/auth/

Secrets Management

The platform services team operates a Vault service. 

It is described here:  https://beta-docs.developer.gov.bc.ca/vault-secrets-management-service/

Access to the service is here: https://vault.developer.gov.bc.ca/ui/vault/auth?with=token

Security and Privacy

It's important that teams engage with the NRM Security and Privacy teams early and often.  They can support you with general advice as well as Security Threat Risk Assessments (STRA's) and Privacy Impact Assessments (PIA's).

NRM Security Knowledge Base: NRM Information Security Home

NRM Privacy Knowledge Base: NRM Privacy Knowledge Base

OWASP (Open Web Application Security Project) is another great reference for security best practices for development teams: https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/migrated_content

CI/CD

The deployment pipeline is a key component for your application.  For visibility, collaboration and maintainability modern teams are moving away from Jenkins towards GitHub actions.

It is strongly recommended that code be submitted using a Pull Request.  Automated testing can and should replace manual UAT wherever practical.

NRM has a modern CI/CD template using GitHub Actions:  OpenShift QuickStart . This offering is currently limited OpenShift Silver or Gold Cluster.

Application Programming Interfaces (API's)

We recommend adopting an "API First" philosophy for application development, where teams both build and consume their API's. Providing API specification with proper metadata is mandatory irrespective of the underlying implementation(REST, graphql, grpc etc..)

Along with API first approach the Architecture team highly recommends looking at Domain Driven Design(DDD) where each micro-service API is bounded by its business domain(https://martinfowler.com/bliki/DomainDrivenDesign.html)

Also look at Event-Driven Architecture (Event Sourcing and CQRS) when building micro-services as it promotes highly decoupled APIS, communicating over an event streaming platform (https://microservices.io/patterns/data/event-sourcing.html, https://microservices.io/patterns/data/cqrs.html)

We recommend a Test Driven Development (TDD) approach to API development, as it makes the application code more reliable and efficient along with easier maintenance in the future.

There are several ways to name test methods/functions but we recommend using the pattern test<method_name>_<given_condition>_<expected_behavior>, it makes the tests more readable, predictable and becomes living documentation of the codebase.

BC Government has published a set of API Guidelines here: https://developer.gov.bc.ca/Data-and-APIs/BC-Government-API-Guidelines

Information on the corporate API gateway can be found here:  https://bcgov.github.io/aps-infra-platform/


Database and Data Design

Most of the teams working on OpenShift are choosing a flavor of PostgreSQL to persist data for their application.

Some points of consideration are:

For NRM guidance specific to data and database design, please visit this space: NRM Data and Database Development Guidelines

Database backups can be setup using the backup container image; information can be found here: https://developer.gov.bc.ca/Backup-Container

Indigenous Languages: the BC Government is committed to including Indigenous languages in government records, systems and services.  The BC Sans font is an open-source "living" typeface developed for government to improve the readability and delivery of digital services.  It was designed to support special characters and syllabics found in Indigenous Languages in B.C.  When designing and building your product, ensure it has the ability to collect, store, manage and display BC Sans characters.  Connect with your architects for more details and references.

Document Storage

BC Government has an on premise object storage solution that delivers low cost storage for unstructured and semi-structured data.  The service is billed monthly to the highwatermark of the storage your team consumes in their S3 bucket at $0.07/GB/Month.  To get an S3 object storage bucket, contact the Optimize team.

COMS (Common Object Management Service) is an emerging common component that leverages the object storage solution.  The advantage of this component is that it includes the ability to tag and add metadata, and integrates with BC Government's standard identity providers (IDIR, BCeID).  To learn more, attend the Common Services Showcase team sprint reviews or contact the team via email.

An emerging companion to the Common Object Management Service being built by the Common Services team is BCBox, which is a hosted solution that uses the COMS API to allow users to upload, tag and share files using any OIDC compliant authentication mechanism.  The code repository for BCBox can be found here.

Design Guidance

General resources for Agile designers at Digital Government (BC Visual Identity, Official BC Design System, Web Style Guide, Content Design Guidance, UX Research Guidance, Service Design Playbook) can be found here:

https://digital.gov.bc.ca/resources#:~:text=Read%20the%20playbook-,For%20Designers,-B.C.%20Visual

Additional design system guidance: https://developer.gov.bc.ca/Design-System/About-the-Design-System

BC Parks has extended their Design Guide to include the use of the BC Sans font and other additions specific to their program:

https://bcgov.github.io/bcparks/design-guides

Front End Frameworks

Many agile teams are using a flavor of Javascript framework for their front end development (Angular, Vue, React etc).  We recommend you pick the framework that works best for the team, and if you are developing a suite of applications for your program area, harmonize across the suite where that makes sense.  This will minimize risk associated with changes to the team and enable other developers to work with your code.

Web Mapping Frameworks

A comparison of web mapping frameworks in use in BC Government can found here: https://bcgov.github.io/bcwebmaps-options/

Back End Languages

Similar to front end frameworks, we recommend you choose a development language that best suits the team and the business challenge you are working on.  If you are developing a suite of applications for your program area, harmonize across the suite where that makes sense.  This will minimize risk associated with changes to the team and enable other developers to work with your code. 

There are many languages in use by agile teams across government, the most popular being Go, Python, Java, Javascript and Typescript.  The Technology Radar is a great reference to see where the momentum is around languages and frameworks.

Web Domains and Certificates

Information on NRM Web Domains can be found here: Web-Application domains

An example of a public facing URL is https://fom.nrs.gov.bc.ca/public/projects

Information on how to obtain an SSL certificate can be found here: Automation of TLS Certificates for Websites

Further information on security certificates can be found here: Security Certificates

Information on certbot can be found here: https://github.com/BCDevOps/certbot

Common Components

BC Government has a selection of mature common components and common services.

Digital Government reference: https://digital.gov.bc.ca/common-components

NRM Specific Guidance: Common Components and Common Services

Community Tip!  If you are looking for a common component you think should exist, but doesn't, consider adding some extra design thinking such that other teams can reuse your great work!

Reporting and Analytics

Many teams require reporting and analytics capabilities for their application data.  Metabase is an easy-to-use open-source dashboarding and business intelligence tool that has broad usage in the NRM.  Architecture has created a packaged install of Metabase tailored to teams wanting secure access to Zone B Oracle databases.

https://github.com/bcgov/nr-arch-templates/tree/main/Metabase

I need help from the Community!

There are many teams working across the NRM and beyond.  To connect with your NRM colleagues, see the team directory here NRIDS Development and Digital Services

The community uses Rocket.Chat to solicit help from other teams on all sorts of subjects.  Users can authenticate with IDIR or their GitHub ID.

https://chat.developer.gov.bc.ca/

Channels of interest might include #general #devops-alerts #devops-operations #nr-iitd-agile-teams and any channel prefixed with "#nr-"

The NRM teams have a DevOps Guild to facilitate connections and collaboration between teams: https://apps.nrs.gov.bc.ca/int/confluence/display/DEVGUILD

You can also reach out to the NRM Architecture team, who can help connect your team with the right resources.

Key References:

BC DevHub: https://developer.gov.bc.ca, https://docs.developer.gov.bc.ca/

Common Components: https://digital.gov.bc.ca/common-components

Communities of Practice: https://digital.gov.bc.ca/communities

BC Gov StackOverflow: https://stackoverflow.developer.gov.bc.ca/

FAQ

Q. Do I need my application and data architecture to be formally approved?

A. No, there is no formal approval process for your architecture.  We recommend collaborating with the architecture team during any architectural spikes or any significant architectural decisions.  Our collective experience and connectedness across the community can typically provide value for the team.


Q. Do I have to use OpenShift to host my application?

A. No.  We would generally like new applications to be running in a containerized or serverless hosting architecture.  OpenShift is a strong option for teams starting out given the maturity of the platform and the surrounding community, as is the AWS Public Cloud Service, both operated by BC Government teams.  Following cloud native design principles will help ensure that your application workload is portable between hosting platforms.


Q. Can I pass my application off to an ops team so the team can work on new apps?

A. We generally follow the "you build it, you run it" philosophy, and therefore recommend you build a sustainment plan into your application roadmap.  Adhering as closely as possible to the 12 Factor principles is a great way to promote a sustainable, cloud native build.



","representation":"storage","_expandable":{"content":"/rest/api/content/120392107"}},"_expandable":{"editor":"","view":"","export_view":"","styled_view":"","anonymous_export_view":""}},"extensions":{"position":0},"_links":{"webui":"/display/AR/Agile+Team+Kickstarter","edit":"/pages/resumedraft.action?draftId=120392107","tinyui":"/x/qwktBw","collection":"/rest/api/content","base":"https://apps.nrs.gov.bc.ca/int/confluence","context":"/int/confluence","self":"https://apps.nrs.gov.bc.ca/int/confluence/rest/api/content/120392107"},"_expandable":{"container":"/rest/api/space/AR","metadata":"","operations":"","children":"/rest/api/content/120392107/child","restrictions":"/rest/api/content/120392107/restriction/byOperation","history":"/rest/api/content/120392107/history","ancestors":"","version":"","descendants":"/rest/api/content/120392107/descendant","space":"/rest/api/space/AR"}} \ No newline at end of file diff --git a/confluence/pages/Coding_Patterns_&_Practices/README.md b/confluence/pages/Coding_Patterns_&_Practices/README.md index 2025137..690bf5a 100644 --- a/confluence/pages/Coding_Patterns_&_Practices/README.md +++ b/confluence/pages/Coding_Patterns_&_Practices/README.md @@ -1 +1 @@ -
Status

Document

StakeholdersNRIDS Architecture, Development & Digital Services, NRM Product Teams
DescriptionThe 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.
OutcomeConsistent point of reference for onboarding new product teams into the NRM's.
OwnerNRIDS (DDS, Architecture)


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

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. 

Focus on the scale-out vs scale-up as deployments are into containers or serverless.


Code Design Patterns and Principles

Folder Structure and Naming Conventions

Secret and Environment Variable Handling

Secure APIs

Error Handling


Code Formatters and Plugins

Infrastructure as Code

Pipeline

The below was created using the QuickStart OpenShift as a reference. Please refer to the repo for the most up to date information.

trueBranching Strategyfalseautotoptrue10111

GitHub PRs - Commits

PR Review and Practices

Dependency Management


\ No newline at end of file +
Status

Document

StakeholdersNRIDS Architecture, Development & Digital Services, NRM Product Teams
DescriptionThe 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.
OutcomeConsistent point of reference for onboarding new product teams into the NRM's.
OwnerNRIDS (DDS, Architecture)


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

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. 

Focus on the scale-out vs scale-up as deployments are into containers or serverless.

Code Design Patterns and Principles

Folder Structure and Naming Conventions

Secret and Environment Variable Handling

Secure APIs

Error Handling


Code Formatters and Plugins

Infrastructure as Code

Pipeline

The below was created using the QuickStart OpenShift as a reference. Please refer to the repo for the most up to date information.

trueBranching Strategyfalseautotoptrue10111

GitHub PRs - Commits

PR Review and Practices

Dependency Management


\ No newline at end of file diff --git a/confluence/pages/Coding_Patterns_&_Practices/data.json b/confluence/pages/Coding_Patterns_&_Practices/data.json index 0ac416c..0c1a154 100644 --- a/confluence/pages/Coding_Patterns_&_Practices/data.json +++ b/confluence/pages/Coding_Patterns_&_Practices/data.json @@ -1 +1 @@ -{"id":"160074735","type":"page","status":"current","title":"Coding Patterns & Practices","body":{"storage":{"value":"
Status

Document

StakeholdersNRIDS Architecture, Development & Digital Services, NRM Product Teams
DescriptionThe 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.
OutcomeConsistent point of reference for onboarding new product teams into the NRM's.
OwnerNRIDS (DDS, Architecture)


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

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. 

Focus on the scale-out vs scale-up as deployments are into containers or serverless.


Code Design Patterns and Principles

Folder Structure and Naming Conventions

Secret and Environment Variable Handling

Secure APIs

Error Handling


Code Formatters and Plugins

Infrastructure as Code

Pipeline

The below was created using the QuickStart OpenShift as a reference. Please refer to the repo for the most up to date information.

trueBranching Strategyfalseautotoptrue10111

GitHub PRs - Commits

PR Review and Practices

Dependency Management


","representation":"storage","_expandable":{"content":"/rest/api/content/160074735"}},"_expandable":{"editor":"","view":"","export_view":"","styled_view":"","anonymous_export_view":""}},"extensions":{"position":10},"_links":{"webui":"/pages/viewpage.action?pageId=160074735","edit":"/pages/resumedraft.action?draftId=160074735","tinyui":"/x/74uKCQ","collection":"/rest/api/content","base":"https://apps.nrs.gov.bc.ca/int/confluence","context":"/int/confluence","self":"https://apps.nrs.gov.bc.ca/int/confluence/rest/api/content/160074735"},"_expandable":{"container":"/rest/api/space/AR","metadata":"","operations":"","children":"/rest/api/content/160074735/child","restrictions":"/rest/api/content/160074735/restriction/byOperation","history":"/rest/api/content/160074735/history","ancestors":"","version":"","descendants":"/rest/api/content/160074735/descendant","space":"/rest/api/space/AR"}} \ No newline at end of file +{"id":"160074735","type":"page","status":"current","title":"Coding Patterns & Practices","body":{"storage":{"value":"
Status

Document

StakeholdersNRIDS Architecture, Development & Digital Services, NRM Product Teams
DescriptionThe 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.
OutcomeConsistent point of reference for onboarding new product teams into the NRM's.
OwnerNRIDS (DDS, Architecture)


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

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. 

Focus on the scale-out vs scale-up as deployments are into containers or serverless.

Code Design Patterns and Principles

Folder Structure and Naming Conventions

Secret and Environment Variable Handling

Secure APIs

Error Handling


Code Formatters and Plugins

Infrastructure as Code

Pipeline

The below was created using the QuickStart OpenShift as a reference. Please refer to the repo for the most up to date information.

trueBranching Strategyfalseautotoptrue10111

GitHub PRs - Commits

PR Review and Practices

Dependency Management


","representation":"storage","_expandable":{"content":"/rest/api/content/160074735"}},"_expandable":{"editor":"","view":"","export_view":"","styled_view":"","anonymous_export_view":""}},"extensions":{"position":10},"_links":{"webui":"/pages/viewpage.action?pageId=160074735","edit":"/pages/resumedraft.action?draftId=160074735","tinyui":"/x/74uKCQ","collection":"/rest/api/content","base":"https://apps.nrs.gov.bc.ca/int/confluence","context":"/int/confluence","self":"https://apps.nrs.gov.bc.ca/int/confluence/rest/api/content/160074735"},"_expandable":{"container":"/rest/api/space/AR","metadata":"","operations":"","children":"/rest/api/content/160074735/child","restrictions":"/rest/api/content/160074735/restriction/byOperation","history":"/rest/api/content/160074735/history","ancestors":"","version":"","descendants":"/rest/api/content/160074735/descendant","space":"/rest/api/space/AR"}} \ No newline at end of file diff --git a/confluence/pages/GitHub_Repository_Best_Practices/README.md b/confluence/pages/GitHub_Repository_Best_Practices/README.md index c60ff35..20505a5 100644 --- a/confluence/pages/GitHub_Repository_Best_Practices/README.md +++ b/confluence/pages/GitHub_Repository_Best_Practices/README.md @@ -1 +1 @@ -
Status

Document

StakeholdersNRIDS Architecture, Development & Digital Services, NRM Product Teams
DescriptionThe purpose of this page is to outline practices when using GitHub as your source code repository
OutcomeConsistent point of reference for onboarding new product teams into the NRM's.
OwnerNRIDS (DDS, Architecture)

Repository Setup

The below options are found under settings

Branch Protection

Create at least 1 branch protection rule for your "main" branch that;

Note: Admins can bypass this

(Ensure you select your options below when enabling the rule)

Manage Your Administrators

Manage Your Team

Setup Your Pull Request Repository Settings (Very Useful to Help Ensure Guidelines are Followed)

For additional PR, Pipeline, and Deployment practices: See

Create Repository Documentation

GitHub Wiki - Suggestions of What to Add

Handle Your Secrets and Environment Variables

See





\ No newline at end of file +
Status

Document

StakeholdersNRIDS Architecture, Development & Digital Services, NRM Product Teams
DescriptionThe purpose of this page is to outline practices when using GitHub as your source code repository
OutcomeConsistent point of reference for onboarding new product teams into the NRM's.
OwnerNRIDS (DDS, Architecture)

Repository Setup

The below options are found under settings

Branch Protection

Create at least 1 branch protection rule for your "main" branch that;

Note: Admins can bypass this

(Ensure you select your options below when enabling the rule)

Manage Your Administrators

Manage Your Team

Setup Your Pull Request Repository Settings (Very Useful to Help Ensure Guidelines are Followed)

For additional PR, Pipeline, and Deployment practices: See

Create Repository Documentation

GitHub Wiki - Suggestions of What to Add

Handle Your Secrets and Environment Variables

See





\ No newline at end of file diff --git a/confluence/pages/GitHub_Repository_Best_Practices/data.json b/confluence/pages/GitHub_Repository_Best_Practices/data.json index 44e4542..f2b814b 100644 --- a/confluence/pages/GitHub_Repository_Best_Practices/data.json +++ b/confluence/pages/GitHub_Repository_Best_Practices/data.json @@ -1 +1 @@ -{"id":"163422029","type":"page","status":"current","title":"GitHub Repository Best Practices","body":{"storage":{"value":"
Status

Document

StakeholdersNRIDS Architecture, Development & Digital Services, NRM Product Teams
DescriptionThe purpose of this page is to outline practices when using GitHub as your source code repository
OutcomeConsistent point of reference for onboarding new product teams into the NRM's.
OwnerNRIDS (DDS, Architecture)

Repository Setup

The below options are found under settings

Branch Protection

Create at least 1 branch protection rule for your "main" branch that;

Note: Admins can bypass this

(Ensure you select your options below when enabling the rule)

Manage Your Administrators

Manage Your Team

Setup Your Pull Request Repository Settings (Very Useful to Help Ensure Guidelines are Followed)

For additional PR, Pipeline, and Deployment practices: See

Create Repository Documentation

GitHub Wiki - Suggestions of What to Add

Handle Your Secrets and Environment Variables

See





","representation":"storage","_expandable":{"content":"/rest/api/content/163422029"}},"_expandable":{"editor":"","view":"","export_view":"","styled_view":"","anonymous_export_view":""}},"extensions":{"position":"none"},"_links":{"webui":"/display/AR/GitHub+Repository+Best+Practices","edit":"/pages/resumedraft.action?draftId=163422029","tinyui":"/x/TZ_9CQ","collection":"/rest/api/content","base":"https://apps.nrs.gov.bc.ca/int/confluence","context":"/int/confluence","self":"https://apps.nrs.gov.bc.ca/int/confluence/rest/api/content/163422029"},"_expandable":{"container":"/rest/api/space/AR","metadata":"","operations":"","children":"/rest/api/content/163422029/child","restrictions":"/rest/api/content/163422029/restriction/byOperation","history":"/rest/api/content/163422029/history","ancestors":"","version":"","descendants":"/rest/api/content/163422029/descendant","space":"/rest/api/space/AR"}} \ No newline at end of file +{"id":"163422029","type":"page","status":"current","title":"GitHub Repository Best Practices","body":{"storage":{"value":"
Status

Document

StakeholdersNRIDS Architecture, Development & Digital Services, NRM Product Teams
DescriptionThe purpose of this page is to outline practices when using GitHub as your source code repository
OutcomeConsistent point of reference for onboarding new product teams into the NRM's.
OwnerNRIDS (DDS, Architecture)

Repository Setup

The below options are found under settings

Branch Protection

Create at least 1 branch protection rule for your "main" branch that;

Note: Admins can bypass this

(Ensure you select your options below when enabling the rule)

Manage Your Administrators

Manage Your Team

Setup Your Pull Request Repository Settings (Very Useful to Help Ensure Guidelines are Followed)

For additional PR, Pipeline, and Deployment practices: See

Create Repository Documentation

GitHub Wiki - Suggestions of What to Add

Handle Your Secrets and Environment Variables

See





","representation":"storage","_expandable":{"content":"/rest/api/content/163422029"}},"_expandable":{"editor":"","view":"","export_view":"","styled_view":"","anonymous_export_view":""}},"extensions":{"position":"none"},"_links":{"webui":"/display/AR/GitHub+Repository+Best+Practices","edit":"/pages/resumedraft.action?draftId=163422029","tinyui":"/x/TZ_9CQ","collection":"/rest/api/content","base":"https://apps.nrs.gov.bc.ca/int/confluence","context":"/int/confluence","self":"https://apps.nrs.gov.bc.ca/int/confluence/rest/api/content/163422029"},"_expandable":{"container":"/rest/api/space/AR","metadata":"","operations":"","children":"/rest/api/content/163422029/child","restrictions":"/rest/api/content/163422029/restriction/byOperation","history":"/rest/api/content/163422029/history","ancestors":"","version":"","descendants":"/rest/api/content/163422029/descendant","space":"/rest/api/space/AR"}} \ No newline at end of file diff --git a/confluence/pages/Source_Code_Repositories/README.md b/confluence/pages/Source_Code_Repositories/README.md index ba31d2e..a84034d 100644 --- a/confluence/pages/Source_Code_Repositories/README.md +++ b/confluence/pages/Source_Code_Repositories/README.md @@ -1 +1 @@ -
Status

GreenDocument

Stakeholders

 

DescriptionGeneral guidance and recommendations for source code repositories
Outcome
OwnerIITD Architecture

Source Code Repository Types

Repository Type

When to Use

Key Contacts

Notes

SubversionNever
Subversion is deprecated, do not create any new repositories.
BitBucketClosed, internal
Manual, complex, (currently) in-house.  Works with RFC/RFD process and JIRA.  Very customizable.
GithubWhenever possible

Ideal for automation, open source.  Industry leader in most significant areas.  Very unconstrained. 

see https://github.com/bcgov/BC-Policy-Framework-For-GitHub


GitHub:

For practices on using GitHub see:


BitBucket:


Subversion (SVN):

Source Code Repository Naming

Diagrams

Source Code Repository Topics

Mono Repo vs Multi Repo?

Source Code Repository License & Ownership

\ No newline at end of file +
Status

Document

StakeholdersNRIDS Architecture
DescriptionGeneral guidance and recommendations for source code repositories
OwnerNRIDS (Architecture)

Source Code Repository Types

Repository Type

When to Use

Key Contacts

Notes

SubversionNever
Subversion is deprecated, do not create any new repositories.
BitBucketClosed, internal
Manual, complex, (currently) in-house.  Works with RFC/RFD process and JIRA.  Very customizable.
GithubWhenever possible

Ideal for automation, open source.  Industry leader in most significant areas.  Very unconstrained. 

see https://github.com/bcgov/BC-Policy-Framework-For-GitHub


GitHub:

For practices on using GitHub see:


BitBucket:


Subversion (SVN):

Source Code Repository Naming

Diagrams

Source Code Repository Topics

Mono Repo vs Multi Repo?

Source Code Repository License & Ownership

\ No newline at end of file diff --git a/confluence/pages/Source_Code_Repositories/data.json b/confluence/pages/Source_Code_Repositories/data.json index 86adf0d..d6440f3 100644 --- a/confluence/pages/Source_Code_Repositories/data.json +++ b/confluence/pages/Source_Code_Repositories/data.json @@ -1 +1 @@ -{"id":"115081594","type":"page","status":"current","title":"Source Code Repositories","body":{"storage":{"value":"
Status

GreenDocument

Stakeholders

 

DescriptionGeneral guidance and recommendations for source code repositories
Outcome
OwnerIITD Architecture

Source Code Repository Types

Repository Type

When to Use

Key Contacts

Notes

SubversionNever
Subversion is deprecated, do not create any new repositories.
BitBucketClosed, internal
Manual, complex, (currently) in-house.  Works with RFC/RFD process and JIRA.  Very customizable.
GithubWhenever possible

Ideal for automation, open source.  Industry leader in most significant areas.  Very unconstrained. 

see https://github.com/bcgov/BC-Policy-Framework-For-GitHub


GitHub:

For practices on using GitHub see:


BitBucket:


Subversion (SVN):

Source Code Repository Naming

Diagrams

Source Code Repository Topics

Mono Repo vs Multi Repo?

Source Code Repository License & Ownership

","representation":"storage","_expandable":{"content":"/rest/api/content/115081594"}},"_expandable":{"editor":"","view":"","export_view":"","styled_view":"","anonymous_export_view":""}},"extensions":{"position":35},"_links":{"webui":"/display/AR/Source+Code+Repositories","edit":"/pages/resumedraft.action?draftId=115081594","tinyui":"/x/egHcBg","collection":"/rest/api/content","base":"https://apps.nrs.gov.bc.ca/int/confluence","context":"/int/confluence","self":"https://apps.nrs.gov.bc.ca/int/confluence/rest/api/content/115081594"},"_expandable":{"container":"/rest/api/space/AR","metadata":"","operations":"","children":"/rest/api/content/115081594/child","restrictions":"/rest/api/content/115081594/restriction/byOperation","history":"/rest/api/content/115081594/history","ancestors":"","version":"","descendants":"/rest/api/content/115081594/descendant","space":"/rest/api/space/AR"}} \ No newline at end of file +{"id":"115081594","type":"page","status":"current","title":"Source Code Repositories","body":{"storage":{"value":"
Status

Document

StakeholdersNRIDS Architecture
DescriptionGeneral guidance and recommendations for source code repositories
OwnerNRIDS (Architecture)

Source Code Repository Types

Repository Type

When to Use

Key Contacts

Notes

SubversionNever
Subversion is deprecated, do not create any new repositories.
BitBucketClosed, internal
Manual, complex, (currently) in-house.  Works with RFC/RFD process and JIRA.  Very customizable.
GithubWhenever possible

Ideal for automation, open source.  Industry leader in most significant areas.  Very unconstrained. 

see https://github.com/bcgov/BC-Policy-Framework-For-GitHub


GitHub:

For practices on using GitHub see:


BitBucket:


Subversion (SVN):

Source Code Repository Naming

Diagrams

Source Code Repository Topics

Mono Repo vs Multi Repo?

Source Code Repository License & Ownership

","representation":"storage","_expandable":{"content":"/rest/api/content/115081594"}},"_expandable":{"editor":"","view":"","export_view":"","styled_view":"","anonymous_export_view":""}},"extensions":{"position":35},"_links":{"webui":"/display/AR/Source+Code+Repositories","edit":"/pages/resumedraft.action?draftId=115081594","tinyui":"/x/egHcBg","collection":"/rest/api/content","base":"https://apps.nrs.gov.bc.ca/int/confluence","context":"/int/confluence","self":"https://apps.nrs.gov.bc.ca/int/confluence/rest/api/content/115081594"},"_expandable":{"container":"/rest/api/space/AR","metadata":"","operations":"","children":"/rest/api/content/115081594/child","restrictions":"/rest/api/content/115081594/restriction/byOperation","history":"/rest/api/content/115081594/history","ancestors":"","version":"","descendants":"/rest/api/content/115081594/descendant","space":"/rest/api/space/AR"}} \ No newline at end of file