From 8b3751eb2b9c22b2165f0eac9eb56e93d66e9e15 Mon Sep 17 00:00:00 2001 From: Omprakash Mishra Date: Sat, 26 Oct 2024 00:26:52 +0000 Subject: [PATCH] Adding or updating the confluence pages --- patterns/docs/Agile Team Kickstarter/data.json | 2 +- patterns/docs/Application Hosting Wayfinding/data.json | 2 +- patterns/docs/Coding Patterns & Practices/data.json | 2 +- patterns/docs/Source Code Repositories/data.json | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/patterns/docs/Agile Team Kickstarter/data.json b/patterns/docs/Agile Team Kickstarter/data.json index e041c4e..cb21611 100644 --- a/patterns/docs/Agile Team Kickstarter/data.json +++ b/patterns/docs/Agile Team Kickstarter/data.json @@ -1 +1 @@ -{"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

GreenPublished

Overview

The 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.


Teams can use this page a reference point to assist in locating some key areas of information related to their application. If the information you are using does not exist here please review other guideline pages and/or contact the architecture team.

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 Forestry Digital Services and the 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

QuickStart OpenShift Emerald

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 and HELM:  OpenShift QuickStart targeted for OpenShift Silver or Gold Cluster.

NRM has a modern CI/CD template using GitHub Actions, HELM and Argo: OpenShift QuickStart Emerald targeted for OpenShift Emerald 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.

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

GreenPublished

Overview

The 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.


Teams can use this page a reference point to assist in locating some key areas of information related to their application. If the information you are using does not exist here please review other guideline pages and/or contact the architecture team.

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 Forestry Digital Services and the 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

QuickStart OpenShift Emerald

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 and HELM:  OpenShift QuickStart targeted for OpenShift Silver or Gold Cluster.

NRM has a modern CI/CD template using GitHub Actions, HELM and Argo: OpenShift QuickStart Emerald targeted for OpenShift Emerald 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.

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":"none"},"_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/patterns/docs/Application Hosting Wayfinding/data.json b/patterns/docs/Application Hosting Wayfinding/data.json index 9735db3..2bad01a 100644 --- a/patterns/docs/Application Hosting Wayfinding/data.json +++ b/patterns/docs/Application Hosting Wayfinding/data.json @@ -1 +1 @@ -{"id":"171770103","type":"page","status":"current","title":"Application Hosting Wayfinding","body":{"storage":{"value":"
Status

GreenPublished 

Overview

This page is intended to provide a high level overview of running an application in various environments and provide a basic understanding of the differences between application hosting environments. Please ask a member of our team to review this with you if you are discussing hosting options.

Hosting Options

The below options outline the 4 primary ways to host applications.

Note: Azure and Google are not mentioned below as the Province has not completed agreements with these providers, hence they are currently not recommended for use.

On-Premise

Overview: Running an application on-premise referred to a typical server (VM) hosted through OCIO and managed by the NRIDS Infrastructure Team for general server management.

Please not the below is not a representation about a specific application but a representation of what an on-premise application could be.

trueOnPremfalse400autotoptrue16563

ProsCons

Network access to government services and applications within SPAN

  • In general, firewall rules will be the only blocker but can be mitigated in general via a firewall change request; 

Difficult to deploy

  • Must use Jenkins or manual deployments
  • No native connectivity to connect with github actions
  • locked into relying on the RFD / RFC team and their deployment structure

Network access from government services and applications within SPAN

  • In general, firewall rules will be the only blocker but can be changes via a firewall change request; Note this can be useful when another systems require access to your applications data

Limited control over servers

  • By default a team does not have full control of their servers
  • Security patches are managed external to a team

Access to system databases

  • Applications that do not have internal or external accessible APIs are still accessible via direct database connections; Note this can be useful for integrations with systems that are not under active development or do not have capabilities to develop APIs

Limited Tech Stack

  • Currently, it is limited to Java/Oracle mainly within ISSS stack with BitBucket as the source code repository.

Access to internal APIs

  • Applications that do not have external accessible APIs are still accessible via internal APIs

Limited Scalability

  • Currently, all applications run as a single process without any resiliency or failover.

When this might fit?

  1. Many integration points with government systems that are not externally accessible.
  2. COTS applications that either won't run on Openshift and do not have a cloud based SaaS subscription service.

When this might not fit?

  1. Team requires full control over the deployment, patches, and maintenance of applications and associated servers.
  2. Team requiring separate tech stack(frontend, backend, database, messaging ...)


Openshift

Overview: Running an application in Openshift (Silver/Gold/Emerald) with the platform managed by OCIO

Please note the below is not a representation about a specific application but a representation of what could be.


ProsCons

Control over deployment, patches, updates,

  • Can work with GitHub and GitHub actions; Note this is not platform/cluster updates. Platform updates are still done by OCIO but if your application is configured as Highly-available with appropriate state management this should not affect your application

Database stability

  • Running a single pod can cause your database to go down without notice in a production environment
  • Limited or no DBA support; the development team is ultimately responsible for database management and backup/recovery

Supporting GitHub

  • Open Source Codebase leading to Easier Collaboration and following defacto standard.

Database cluster complexity

  • Since production databases must operate in a cluster, additional expertise is needed to operate a cluster



When this might fit?

  1. Deployment of containerized web applications with limited Database requirements
  2. Your product is comprised of open source technologies

When this might not fit?

  1. Low developer expertise
  2. Your product has an embedded PCI/payment solution

Note: For direct DB access to ZoneB databases Or Storing Protected C data, emerald cluster may be required

AWS

Overview: Running an application in BCGOV AWS tenancy owned by OCIO

Please note the below is not a representation about a specific application but a representation of what could be.

trueAWSfalse600autotoptrue34981

ProsCons

Scalability of resources

  • Provides the ability to increase resources (for a cost)

Steep learning curve

  • Operating in AWS requires extensive knowledge of the platform and infrastructure as well as supporting technologies (eg. Terraform)

Reduced IT management overhead

  • Platform, infrastructure, security overhead are handled by AWS

Limited use for Data Types

  • Not fit for Protected C data

Access to a breadth of services not available on premise

Little or no cost certainty

  • Most components in AWS are billed based on usage; network egress (leaving AWS) is also charged based on data volumes

When this might fit?

  1. Your applications require a volume of resources not available on-premise with large fluctuations in demand
  2. You require tools and services not available on premise or in Openshift

When this might not fit?

  1. Many integration points with government systems are not externally accessible; Note: this may not be a blocker in the future due to a cloud networking interface being implemented by OCIO that is intended to allow network access between SPANBC and our AWS tenancy, however, it is not known the impacts or efforts for teams to implement

SaaS

Overview: A vendor run and managed application hosted outside government networks provided as a "service"

Please not the below is not a representation about a specific application but a representation of what could be.

Red Line: Firewall

Blue Line: SPAN network boarder

trueSaaSfalse400autotoptrue26291

ProsCons

Less responsibility to maintain

  • A vendor is responsible to maintain infrastructure and application; Note SLAs. contracts, and licenses are required

Vendor Managed

  • Infrastructure or application issues will generally be up to the vendor to resolve
  • Changes, bugs, enhancements are likely to be done only by a vendor unless additional training is provided

Vendor and Product lock in

  • Full implement SaaS products generally requires substantial effort to migrate to other platforms
  • Data is locked in with the vendor.


Limited use for Data Types

  • Not fit for Protected C data

Difficult to meet requirements of the Cloud Security Schedule and Cloud Privacy Schedule

  • Each SaaS vendor AND the underlying service provider must be evaluated

When this might fit?

  1. Little to no resources to run and manage your application
  2. Little to no integration points with government systems that are not externally accessible.

When this might not fit?

  1. Many integration points with government systems that are not externally accessible.



","representation":"storage","_expandable":{"content":"/rest/api/content/171770103"}},"_expandable":{"editor":"","view":"","export_view":"","styled_view":"","anonymous_export_view":""}},"extensions":{"position":2},"_links":{"webui":"/display/AR/Application+Hosting+Wayfinding","edit":"/pages/resumedraft.action?draftId=171770103","tinyui":"/x/9wA9Cg","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/171770103"},"_expandable":{"container":"/rest/api/space/AR","metadata":"","operations":"","children":"/rest/api/content/171770103/child","restrictions":"/rest/api/content/171770103/restriction/byOperation","history":"/rest/api/content/171770103/history","ancestors":"","version":"","descendants":"/rest/api/content/171770103/descendant","space":"/rest/api/space/AR"}} \ No newline at end of file +{"id":"171770103","type":"page","status":"current","title":"Application Hosting Wayfinding","body":{"storage":{"value":"
Status

GreenPublished 

Overview

This page is intended to provide a high level overview of running an application in various environments and provide a basic understanding of the differences between application hosting environments. Please ask a member of our team to review this with you if you are discussing hosting options.

Hosting Options

The below options outline the 4 primary ways to host applications.

Note: Azure and Google are not mentioned below as the Province has not completed agreements with these providers, hence they are currently not recommended for use.

On-Premise

Overview: Running an application on-premise referred to a typical server (VM) hosted through OCIO and managed by the NRIDS Infrastructure Team for general server management.

Please not the below is not a representation about a specific application but a representation of what an on-premise application could be.

trueOnPremfalse400autotoptrue16563

ProsCons

Network access to government services and applications within SPAN

  • In general, firewall rules will be the only blocker but can be mitigated in general via a firewall change request; 

Difficult to deploy

  • Must use Jenkins or manual deployments
  • No native connectivity to connect with github actions
  • locked into relying on the RFD / RFC team and their deployment structure

Network access from government services and applications within SPAN

  • In general, firewall rules will be the only blocker but can be changes via a firewall change request; Note this can be useful when another systems require access to your applications data

Limited control over servers

  • By default a team does not have full control of their servers
  • Security patches are managed external to a team

Access to system databases

  • Applications that do not have internal or external accessible APIs are still accessible via direct database connections; Note this can be useful for integrations with systems that are not under active development or do not have capabilities to develop APIs

Limited Tech Stack

  • Currently, it is limited to Java/Oracle mainly within ISSS stack with BitBucket as the source code repository.

Access to internal APIs

  • Applications that do not have external accessible APIs are still accessible via internal APIs

Limited Scalability

  • Currently, all applications run as a single process without any resiliency or failover.

When this might fit?

  1. Many integration points with government systems that are not externally accessible.
  2. COTS applications that either won't run on Openshift and do not have a cloud based SaaS subscription service.

When this might not fit?

  1. Team requires full control over the deployment, patches, and maintenance of applications and associated servers.
  2. Team requiring separate tech stack(frontend, backend, database, messaging ...)


Openshift

Overview: Running an application in Openshift (Silver/Gold/Emerald) with the platform managed by OCIO

Please note the below is not a representation about a specific application but a representation of what could be.


ProsCons

Control over deployment, patches, updates,

  • Can work with GitHub and GitHub actions; Note this is not platform/cluster updates. Platform updates are still done by OCIO but if your application is configured as Highly-available with appropriate state management this should not affect your application

Database stability

  • Running a single pod can cause your database to go down without notice in a production environment
  • Limited or no DBA support; the development team is ultimately responsible for database management and backup/recovery

Supporting GitHub

  • Open Source Codebase leading to Easier Collaboration and following defacto standard.

Database cluster complexity

  • Since production databases must operate in a cluster, additional expertise is needed to operate a cluster



When this might fit?

  1. Deployment of containerized web applications with limited Database requirements
  2. Your product is comprised of open source technologies

When this might not fit?

  1. Low developer expertise
  2. Your product has an embedded PCI/payment solution

Note: For direct DB access to ZoneB databases Or Storing Protected C data, emerald cluster may be required

AWS

Overview: Running an application in BCGOV AWS tenancy owned by OCIO

Please note the below is not a representation about a specific application but a representation of what could be.

trueAWSfalse600autotoptrue34981

ProsCons

Scalability of resources

  • Provides the ability to increase resources (for a cost)

Steep learning curve

  • Operating in AWS requires extensive knowledge of the platform and infrastructure as well as supporting technologies (eg. Terraform)

Reduced IT management overhead

  • Platform, infrastructure, security overhead are handled by AWS

Limited use for Data Types

  • Not fit for Protected C data

Access to a breadth of services not available on premise

Little or no cost certainty

  • Most components in AWS are billed based on usage; network egress (leaving AWS) is also charged based on data volumes

When this might fit?

  1. Your applications require a volume of resources not available on-premise with large fluctuations in demand
  2. You require tools and services not available on premise or in Openshift

When this might not fit?

  1. Many integration points with government systems are not externally accessible; Note: this may not be a blocker in the future due to a cloud networking interface being implemented by OCIO that is intended to allow network access between SPANBC and our AWS tenancy, however, it is not known the impacts or efforts for teams to implement

SaaS

Overview: A vendor run and managed application hosted outside government networks provided as a "service"

Please not the below is not a representation about a specific application but a representation of what could be.

Red Line: Firewall

Blue Line: SPAN network boarder

trueSaaSfalse400autotoptrue26291

ProsCons

Less responsibility to maintain

  • A vendor is responsible to maintain infrastructure and application; Note SLAs. contracts, and licenses are required

Vendor Managed

  • Infrastructure or application issues will generally be up to the vendor to resolve
  • Changes, bugs, enhancements are likely to be done only by a vendor unless additional training is provided

Vendor and Product lock in

  • Full implement SaaS products generally requires substantial effort to migrate to other platforms
  • Data is locked in with the vendor.


Limited use for Data Types

  • Not fit for Protected C data

Difficult to meet requirements of the Cloud Security Schedule and Cloud Privacy Schedule

  • Each SaaS vendor AND the underlying service provider must be evaluated

When this might fit?

  1. Little to no resources to run and manage your application
  2. Little to no integration points with government systems that are not externally accessible.

When this might not fit?

  1. Many integration points with government systems that are not externally accessible.



","representation":"storage","_expandable":{"content":"/rest/api/content/171770103"}},"_expandable":{"editor":"","view":"","export_view":"","styled_view":"","anonymous_export_view":""}},"extensions":{"position":"none"},"_links":{"webui":"/display/AR/Application+Hosting+Wayfinding","edit":"/pages/resumedraft.action?draftId=171770103","tinyui":"/x/9wA9Cg","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/171770103"},"_expandable":{"container":"/rest/api/space/AR","metadata":"","operations":"","children":"/rest/api/content/171770103/child","restrictions":"/rest/api/content/171770103/restriction/byOperation","history":"/rest/api/content/171770103/history","ancestors":"","version":"","descendants":"/rest/api/content/171770103/descendant","space":"/rest/api/space/AR"}} \ No newline at end of file diff --git a/patterns/docs/Coding Patterns & Practices/data.json b/patterns/docs/Coding Patterns & Practices/data.json index c922e6d..40d1fe4 100644 --- a/patterns/docs/Coding Patterns & Practices/data.json +++ b/patterns/docs/Coding Patterns & Practices/data.json @@ -1 +1 @@ -{"id":"160074735","type":"page","status":"current","title":"Coding Patterns & Practices","body":{"storage":{"value":"
Status

GreenPublished 

Overview

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.

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

Align your CI/CD pipeline with your hosting environment (GitHub Actions for Openshift Silver/Gold, GitHub Actions with ArgoCD for Openshift Emerald, GiHub Actions with Terraform for AWS)

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

API framework evaluation factors

The below outlines a few key considerations which would help in the decision-making of language/framework to use for API development for containerized environments.

Details around API Design are outlined here(https://developer.gov.bc.ca/Data-and-APIs/BC-Government-API-Guidelines). The below points are on top of the guidelines provided in the link.

  1. Developer friendly, community support and libraries.
  2. Resource Consumption(memory/CPU) the less the better, supports the move towards green computing.
  3. Automated Open API 3 Specification generation, Swagger UI.
  4. Automated DB schema management (flyway/Liquibase or something similar).
  5. ORM integration for Database, ACID, Transaction support, Nested Transactions, Advanced Query with pagination, filter, sorting support.
  6. Supports TDD(Test Driven Development) out of the box, which supports unit and integration testing.
  7. Easiness of testing for pipelines and other automation.
  8. Easiness of OAUTH2 integration.
  9. Easiness of Circuit breaker integration and Resiliency.
  10. API versioning.
  11. Support for REST, GraphQL and gRPC
  12. Asynchronous REST Client.
  13. API Health checks(for liveness/readiness checks in Kubernetes world) out of the box which includes checking DB Connections and Message Broker connection (If present).
  14. Easiness of writing to log files in different formats.
  15. Switching Between Relational Database should be config only.
  16. Easy Concurrency.
  17. Easiness of Integration with Distributed tracing frameworks.




","representation":"storage","_expandable":{"content":"/rest/api/content/160074735"}},"_expandable":{"editor":"","view":"","export_view":"","styled_view":"","anonymous_export_view":""}},"extensions":{"position":9},"_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

GreenPublished 

Overview

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.

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

Align your CI/CD pipeline with your hosting environment (GitHub Actions for Openshift Silver/Gold, GitHub Actions with ArgoCD for Openshift Emerald, GiHub Actions with Terraform for AWS)

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

API framework evaluation factors

The below outlines a few key considerations which would help in the decision-making of language/framework to use for API development for containerized environments.

Details around API Design are outlined here(https://developer.gov.bc.ca/Data-and-APIs/BC-Government-API-Guidelines). The below points are on top of the guidelines provided in the link.

  1. Developer friendly, community support and libraries.
  2. Resource Consumption(memory/CPU) the less the better, supports the move towards green computing.
  3. Automated Open API 3 Specification generation, Swagger UI.
  4. Automated DB schema management (flyway/Liquibase or something similar).
  5. ORM integration for Database, ACID, Transaction support, Nested Transactions, Advanced Query with pagination, filter, sorting support.
  6. Supports TDD(Test Driven Development) out of the box, which supports unit and integration testing.
  7. Easiness of testing for pipelines and other automation.
  8. Easiness of OAUTH2 integration.
  9. Easiness of Circuit breaker integration and Resiliency.
  10. API versioning.
  11. Support for REST, GraphQL and gRPC
  12. Asynchronous REST Client.
  13. API Health checks(for liveness/readiness checks in Kubernetes world) out of the box which includes checking DB Connections and Message Broker connection (If present).
  14. Easiness of writing to log files in different formats.
  15. Switching Between Relational Database should be config only.
  16. Easy Concurrency.
  17. Easiness of Integration with Distributed tracing frameworks.




","representation":"storage","_expandable":{"content":"/rest/api/content/160074735"}},"_expandable":{"editor":"","view":"","export_view":"","styled_view":"","anonymous_export_view":""}},"extensions":{"position":"none"},"_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/patterns/docs/Source Code Repositories/data.json b/patterns/docs/Source Code Repositories/data.json index 0fa1323..edb7bd8 100644 --- a/patterns/docs/Source Code Repositories/data.json +++ b/patterns/docs/Source Code Repositories/data.json @@ -1 +1 @@ -{"id":"115081594","type":"page","status":"current","title":"Source Code Repositories","body":{"storage":{"value":"
Status

GreenPublished

Overview

This page is general awareness, guidance, and recommendations for source code repositories within the NRM

Repository Type Overview

Repository Type

When to Use

Notes

SubversionNeverSubversion is deprecated, do not create any new repositories.
BitBucketClosed, internalManual, 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:

Beginner Guide: https://github.blog/2024-05-27-what-is-git-our-beginners-guide-to-version-control/

For practices on using GitHub see:


BitBucket:


Subversion (SVN):

Source Code Repository Naming


Folder Naming

Diagrams

Source Code Repository Topics

Mono Repo vs Multi Repo?

As a general recommendation, it is preferred to use product based monorepos.

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":32},"_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

GreenPublished

Overview

This page is general awareness, guidance, and recommendations for source code repositories within the NRM

Repository Type Overview

Repository Type

When to Use

Notes

SubversionNeverSubversion is deprecated, do not create any new repositories.
BitBucketClosed, internalManual, 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:

Beginner Guide: https://github.blog/2024-05-27-what-is-git-our-beginners-guide-to-version-control/

For practices on using GitHub see:


BitBucket:


Subversion (SVN):

Source Code Repository Naming


Folder Naming

Diagrams

Source Code Repository Topics

Mono Repo vs Multi Repo?

As a general recommendation, it is preferred to use product based monorepos.

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":"none"},"_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