UNCLASSIFIED - NO CUI

Skip to content
Snippets Groups Projects
Commit 097b97b6 authored by Ryan Thompson's avatar Ryan Thompson Committed by Gabe Scarberry
Browse files

Charter Updates and Cleanup

parent d6629ada
No related branches found
No related tags found
2 merge requests!1658Draft: Merge branch 'tempo_tracing_updates' into 'master',!1389Charter Updates and Cleanup
Hide whitespace changes
Inline Side-by-side
Showing
with 160 additions and 245 deletions
charter/BigBangPackages.md
+ 30
− 98
View file @ 097b97b6
......@@ -2,7 +2,7 @@
Each Big Bang Package is present in the [Big Bang Package](https://repo1.dso.mil/platform-one/big-bang/apps) repository and broken up into several sub-groupings.
Each package has _at least_ two `CODEOWNERS`. Responsibilities are outlined [here](PackageOwner.md).
Each package has _at least_ two `CODEOWNERS`. Responsibilities are outlined [here](ApplicationOwners.md).
[[_TOC_]]
......@@ -12,9 +12,9 @@ Each package has _at least_ two `CODEOWNERS`. Responsibilities are outlined [he
graph TB
subgraph "Core"
subgraph "Logging"
LoggingElastic(Elasticsearch)
LoggingKibana(Kibana)
LoggingECK(ECK)
LoggingElastic[Elasticsearch]
LoggingKibana[Kibana]
LoggingECK[ECK]
LoggingElastic --> LoggingECK
LoggingKibana --> LoggingECK
LoggingKibana --> LoggingElastic
......@@ -27,23 +27,23 @@ graph TB
ServiceMesh
ClusterAuditor --> LoggingECK
ClusterAuditor --> OPA(Policy Enforcement)
ClusterAuditor --> OPA[Policy Enforcement]
end
subgraph "Package Utilities"
Postgres
MinIO(S3 Compatible Storage)
Redis
Postgres[DB]
MinIO[S3 Compatible Storage]
Redis[Cache Server]
end
subgraph "Security"
Keycloak --> Postgres
Anchore(Anchore Enterprise) --> Postgres
Anchore[Anchore Enterprise] --> Postgres
Twistlock
end
subgraph "Developer Tools"
GitLab --> GitLabRunners(GitLab Runners)
GitLab --> GitLabRunners[GitLab Runners]
GitLab --> MinIO
GitLab --> Redis
GitLab --> Postgres
......@@ -64,9 +64,9 @@ Core packages are supported Big Bang packages that have to be enabled and are lo
graph TB
subgraph "Core"
subgraph "Logging"
LoggingElastic(Elasticsearch)
LoggingKibana(Kibana)
LoggingECK(ECK)
LoggingElastic[Elasticsearch]
LoggingKibana[Kibana]
LoggingECK[ECK]
LoggingElastic --> LoggingECK
LoggingKibana --> LoggingECK
LoggingKibana --> LoggingElastic
......@@ -80,7 +80,7 @@ graph TB
Twistlock
ClusterAuditor --> LoggingECK
ClusterAuditor --> OPA(Policy Enforcement)
ClusterAuditor --> OPA[Policy Enforcement]
end
```
......@@ -100,6 +100,7 @@ Repository:
Dependency: None
Owners:
* [CODEOWNERS](https://repo1.dso.mil/platform-one/big-bang/apps/core/istio-operator/-/blob/main/CODEOWNERS)
### Auth Service
......@@ -117,6 +118,7 @@ Repository:
Dependency: None
Owners:
* [CODEOWNERS](https://repo1.dso.mil/platform-one/big-bang/apps/core/authservice/-/blob/main/CODEOWNERS)
### Logging
......@@ -142,6 +144,7 @@ Dependencies:
* RWO StorageClass
Owners:
* [Elasticsearch-kibana CODEOWNERS](https://repo1.dso.mil/platform-one/big-bang/apps/core/elasticsearch-kibana/-/blob/main/CODEOWNERS)
* [Fluentbit CODEOWNERS](https://repo1.dso.mil/platform-one/big-bang/apps/core/fluentbit/-/blob/main/CODEOWNERS)
* [Eck-operator CODEOWNERS](https://repo1.dso.mil/platform-one/big-bang/apps/core/eck-operator/-/blob/main/CODEOWNERS)
......@@ -236,12 +239,12 @@ Security Tools are hosted here: [Security Tools](https://repo1.dso.mil/platform-
graph TB
subgraph "Package Utilities"
Postgres
Postgres(DB)
end
subgraph "Security"
Keycloak --> Postgres
Anchore(Anchore Enterprise) --> Postgres
Anchore[Anchore Enterprise] --> Postgres
end
```
......@@ -288,14 +291,14 @@ Developer Tools are hosted here: [Developer Tools](https://repo1.dso.mil/platfor
graph TB
subgraph "Application Utilities"
Postgres
MinIO(S3 Compatible Storage)
Redis
Postgres[DB]
MinIO[S3 Compatible Storage]
Redis[Cache Server]
end
subgraph "Package Tools"
GitLab --> GitLabRunners(GitLab Runners)
GitLab --> GitLabRunners[GitLab Runners]
GitLab --> MinIO
GitLab --> Redis
GitLab --> Postgres
......@@ -395,13 +398,11 @@ Collaboration tools are hosted here: [Collaboration Tools](https://repo1.dso.mil
```mermaid
graph TB
subgraph "Package Utilities"
Postgres
MinIO(S3 Compatible Storage)
Postgres[DB]
MinIO[S3 Compatible Storage]
end
subgraph "Collaboration Tools"
Jira --> Postgres
Confluence --> Postgres
MatterMost --> MinIO
end
......@@ -480,30 +481,13 @@ A clear an obvious example of this is PostgreSQL.
```mermaid
graph TB
subgraph "Package Utilities"
Postgres
MinIO(S3 Compatible Storage)
Redis
MySQL
MongoDB
Postgres[DB]
MinIO[S3 Compatible Storage]
Redis[Cache Server]
end
```
#### PostgreSQL
Product:
* [PostgreSQL](https://www.postgresql.org/)
Repository:
* TBD
Owners:
* TBD
* TBD
#### Minio
Minio provides S3 compatible object storage
......@@ -512,7 +496,7 @@ Product:
* [MinIO](https://min.io/)
Repository:
Repository:
* [Minio Package](https://repo1.dso.mil/platform-one/big-bang/apps/application-utilities/minio/)
......@@ -522,50 +506,6 @@ Owners:
* [CODEOWNERS](https://repo1.dso.mil/platform-one/big-bang/apps/application-utilities/minio/-/blob/main/CODEOWNERS)
#### MySQL
Product:
* [MySQL](https://www.mysql.com/)
Repository:
* TBD
Owners:
* TBD
* TBD
#### MongoDB
Product:
* [MongoDB](https://www.mongodb.com/)
Repository:
* TBD
Owners:
* TBD
* TBD
#### Redis
Redis is an open source, in-memory data structure store, used as a database, cache, and message broker.
* [Redis](https://redis.io/)
Repository:
* [Redis Package](https://repo1.dso.mil/platform-one/big-bang/apps/sandbox/redis)
Owners:
* [CODEOWNERS](https://repo1.dso.mil/platform-one/big-bang/apps/sandbox/redis/-/blob/main/CODEOWNERS)
### Cluster Utilities
Packages that provider cluster level utility, such as RWX storage or generic backup capabilities.
......@@ -600,14 +540,6 @@ Owners:
* [CODEOWNERS](https://repo1.dso.mil/platform-one/big-bang/apps/cluster-utilities/velero/-/blob/main/CODEOWNERS)
### BB Technical Oversight Committee (BB TOC)
### BB Technical Oversight Committee (BB TOC)
[Process](https://repo1.dso.mil/platform-one/bbtoc/-/tree/master/process)
#### BB TOC Repos
[Graduated](https://repo1.dso.mil/platform-one/big-bang/apps/graduated)
[Incubating](https://repo1.dso.mil/platform-one/big-bang/apps/incubating)
[Sandbox](https://repo1.dso.mil/platform-one/big-bang/apps/sandbox)
\ No newline at end of file
charter/DocumentationLocations.md
+ 12
− 6
View file @ 097b97b6
# Note: This charter doc represents the future state we are working toward
# Documentation Locations
> This charter doc represents the future state we are working toward
## BigBang Docs:
### Where is the best place to look for documentation on BigBang?
# BigBang Docs:
## Where is the best place to look for documentation on BigBang?
- https://repo1.dso.mil/platform-one/big-bang/bigbang/-/tree/master/docs/
- Our goal is to have near 100% of publicly sharable docs in this centralized location to act as a single source of truth where all documentation can be found and help move docs out of IL2 Confluence and Private Repos to better support the open source community.
## What types of documentation can be found in the docs folder?
### What types of documentation can be found in the docs folder?
- Developer Contribution Docs
- Docs to help understand BigBang (At a concrete level, what the value add is, and Architecture Diagrams)
- Deployment Prerequisites
- Deployment Docs for Internet Connected and Disconnected deployments
# BigBang Package Docs:
## Where is the best place to look for documentation on BigBang Packages?
## BigBang Package Docs:
### Where is the best place to look for documentation on BigBang Packages?
- Our goal is to have these docs available on a webpage hosted on the BigBang Cluster using Hugo
(https://docs.bigbang.dev by default) (look [here](https://repo1.dso.mil/platform-one/big-bang/bigbang/-/blob/master/charter/PackageDocumentation.md) for more info)
- This allows us to support a centralized location for package configuration documentation, while allowing support for dynamically added versions of distributed packages in a maintainable way.
charter/GitlabLabels.md
+ 69
− 83
View file @ 097b97b6
# Gitlab Labels
# GitLab Labels
## Issues
Issues are required to have `status`, `priority` and `kind` labels.
Generally, all issues derived from an epic should have a `priority` value set to the `priority` of the epic its a part of.
Issues that are not part of an epic will need to be determined by a package owner or maintainer.
### `kind`
The kind label shows the type of work that needs to be accomplished
#### `kind::bug`
Issues related to Big Bang not functioning as expected
#### `kind::chore`
Catch all kind that captures administrative tasking for the Big Bang project
#### `kind:ci`
[[_TOC_]]
Issues related to the CI/CD, developer workflows and/or the release process
#### `kind::docs`
Issues related to documentation
## Epics
#### `kind::feature`
Epics are required to have `priority`, `size` and `status` labels.
Creation of a new capability for Big Bang and/or one of its packages
### Epic Label `status`
#### `kind::enhancement`
Status captures the state of the Epic
Improvement of an existing capability to work more efficiently in specific environments
`status::to-do`
: This Epic is being identified and worked on by the Maintainers.
#### `kind::test`
`status::review`
: The Epic is ready for review by the engineering team. Team can re-assign to `status::to-do` when more detail is needed.
Improvements on testing for individual packages or Big Bang. Does not change the actual CI/CD pipelines, just enhances the test suite.
`status::ready`
: The epic is accepted by the team and ready for breakdown of work as priority dictates.
### priority
`status::doing`
: Work has been broken out from this epic and is assigned to milestones for completion
#### `priority::1`
......@@ -61,80 +42,78 @@ Improvements on testing for individual packages or Big Bang. Does not change th
`priority::5` issues are superficial and do not have any impact on the functioning of production systems
### Status
Status captures the state of the issue
#### `status::blocked`
Blocked issues have an external dependency that needs to be solved before work can be completed. This may be other Big Bang issues or hardening of IronBank images. If blocked by an IronBank issue, the `ironbank` label should also be applied
#### `status::doing`
Work is actively being done on this issue. At this point it should have an assignee
#### `status::review`
The `size` label helps identify the scope of work needed as part of the epic
The issue is ready to be reviewed by a Maintainer
`size::small`
: Sufficiently small enough to be completed by an engineer in a two week period
#### `status::to-do`
`size::medium`
: A small number of engineers could complete this in a two week period
This Issue has not been started.
`size::large`
: This epic should be broken down further into consumable sub-epics
### Packages
`size::xl`
: This epic needs to be broken down further to be able to be tackled in a sprint
Package labels are identified by their package name and serve two purposes.
## Issues
1. Packages owners subscribe to the package labels for their packages and will be notified when a new issue or merge request is created with the label
Issues are required to have `status`, `priority` and `kind` labels.
## Merge Requests
Generally, all issues derived from an Epic should have a `priority` value set to the `priority` of the epic its a part of. The priority of issues that are not part of an Epic will need to be determined by a package owner or maintainer.
Merge Requests are required to have `status` and `kind` labels.
### Issue Label `kind`
### Status
The `kind` label shows the type of work that needs to be accomplished.
Status captures the state of the Merge Request
`kind::bug`
: Issues related to BigBang not functioning as expected.
#### `status::blocked`
`kind::maintenance`
: Catch all kind that captures administrative tasking for the BigBang project
Blocked merge requests and issues have an external dependency that needs to be solved before work can be completed. This may be other Big Bang issues or hardening of IronBank images.
`kind::ci`
: Issues related to the CI/CD, developer workflows and/or the release process.
#### `status::doing`
`kind::docs`
: Issues related to documentation.
Work is actively being done on this Merge Request
`kind::feature`
: Creation of a new capability for BigBang and/or one of its packages
#### `status::review`
`kind::enhancement`
: Improvement of an existing capability to work more efficiently in specific environments
The Merge Request is ready to be reviewed by a Maintainer
`kind::test`
: Improvements on testing for individual packages or Big Bang. Does not change the actual CI/CD pipelines, just enhances the test suite.
#### `status::to-do`
### Issue Label `status`
This Merge Request has been assigned, but work as not been started.
Status captures the state of the issue
### Packages
`status::blocked`
: Blocked issues have an external dependency that needs to be solved before work can be completed. This may be other Big Bang issues or hardening of IronBank images. If blocked by an IronBank issue, the `ironbank` label should also be applied
The package label controls which addons are deployed as part of CI. If a label is present for an addon, the Gitlab testing framework will enable this addon and ensure its tested as part
`status::doing`
: Work is actively being done on this issue. At this point it should have an assignee
### `ci::test-infra`
`status::review`
: The issue is ready to be reviewed by a Maintainer
The CI label for a Merge Request causes the full e2e CI job to run, which includes provisioning Kubernetes clusters in AWS.
### Issue Package Labels
### `charter`
Package labels are identified by their package name and serve two purposes.
This Merge Request has a proposed change to the Charter
> Packages owners subscribe to the package labels for their packages and will be notified when a new issue or merge request is created with the label.
## Epics
## Merge Requests
Epics are required to have `priority`, `size` and `status` labels.
Merge Requests are required to have `status` and `kind` labels.
### Status
### Merge Requests Label `status`
Status captures the state of the Merge Request
#### `status::to-do`
This Epic is being identified and worked on by the Maintainers.
#### `status::review`
The Epic is ready for review by the engineering team. Team can re-assign to `status::to-do` when more detail is needed.
......@@ -181,14 +160,21 @@ The `size` label helps identify the scope of work needed as part of the epic
Sufficiently small enough to be completed by an engineer in a two week period
#### `size::medium`
`status::doing`
: Work is actively being done on this Merge Request
`status::review`
: The Merge Request is ready to be reviewed by a Maintainer
A small number of engineers could complete this in a two week period
### Merge Requests Packages Label
#### `size::large`
The package label controls which addons are deployed as part of CI. If a label is present for an addon, the GitLab testing framework will enable this addon and ensure its tested as part
This epic should be broken down further into consumable sub-epics
`test-ci::infra`
: The test CI `infra` label for a Merge Request causes the full e2e CI job to run, which includes provisioning Kubernetes clusters in AWS.
#### `size::xl`
`test-ci::release`
: The test CI `release` label for a Merge Request causes all release CI jobs to run, including bundling of airgap artifacts.
This epic needs to be broken down further to be able to be tackled in a sprint
`charter`
: This Merge Request has a proposed change to the Charter
charter/Glossary.md
+ 4
− 2
View file @ 097b97b6
# Glossary
**Big Bang Application**: Is an application deployable onto Kubernetes using manifests inside the Big Bang Application Repository that meets all the requirements of [Package Requirements](PackageRequirements.md).
Big Bang Application
: Is an application deployable onto Kubernetes using manifests inside the Big Bang Application Repository that meets all the requirements of [Package Requirements](PackageRequirements.md).
**Release**: A release is any change to the manifests that would be installed when referencing this application. It includes a change in Image tag, as well as modifications to the structure of any manifests that define the application deployment.
Release
: A release is any change to the manifests that would be installed when referencing this application. It includes a change in Image tag, as well as modifications to the structure of any manifests that define the application deployment.
charter/HelmStandards.md
+ 7
− 3
View file @ 097b97b6
......@@ -10,13 +10,13 @@ For example, for the upstream [`istio-operator`](https://github.com/istio/istio/
For another example in using the [`kube-prometheus-stack`](https://github.com/prometheus-community/helm-charts/tree/kube-prometheus-stack-12.2.2/charts/kube-prometheus-stack), the upstream is versioned at `12.2.2`, meaning BigBang's initial fork will be `12.2.2-bb.0`. Future additions, such as adding `VirtualServices` for the ingresses, bumps to the `-bb.#` will happen in sequence every time BigBang updates the chart within the same version.
## Big Bang Values File
* In the values.yaml file [here](../chart/values.yaml), each package should have its own region at `.package_name` if its in Core or `.addons.package_name`.
* User Interface:
* If there exists need for ingress traffic into the package, the package should create a VirtualService conditional on the existance of `istio.enabled` being set to true. This value should default to false. The BigBang chart should set this true for all packages
* If there exists need for ingress traffic into the package, the package should create a VirtualService conditional on the existence of `istio.enabled` being set to true. This value should default to false. The BigBang chart should set this true for all packages
* There should be a region under the package for configuring SSO that looks like this when there are multiple packages
```yaml
sso:
enabled: false
......@@ -27,17 +27,21 @@ For another example in using the [`kube-prometheus-stack`](https://github.com/pr
client_id: jaeger
client_secret: "change_me"
```
or like this if there is a single user interface:
```yaml
sso:
enabled: false
client_id: twistlock_id
client_secret: "change_me"
```
* If sso is enabled and a value is not provided in the SSO configuration of the package, it should default to the top level SSO configuration
* Database Connections:
* The BigBang chart should prevent the use of a database bundled as part of the package chart by default, and warn if an end user uses one anyways.
* There should be a database section under the package configuration that matches the following section
```yaml
database:
# Entering connection info will enable external database and will auto-create any required secrets.
......@@ -48,6 +52,7 @@ For another example in using the [`kube-prometheus-stack`](https://github.com/pr
database: ""
type: "" # Optional. One of mysql, mssql, postgres, mongo if ther
```
* Monitoring
* Charts should expect a value `monitoring.enabled` to be set by the BigBang chart to conditionally create monitoring components (`ServiceMonitors`, `PodMonitors`, etc). This value should default to false
......@@ -92,7 +97,6 @@ commonLabels:
## Kubernetes Objects
These requirements for the kubernetes components come from the Kubernetes STIG, Kubesec.io and other best practices
* Resource Limits and Requests set for cpu and memory and they are [Guaranteed QoS](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#create-a-pod-that-gets-assigned-a-qos-class-of-guaranteed)
......
charter/New GitLab Epic Checklist Template
+ 34
− 49
View file @ 097b97b6
#New Epic Checklist Template
# New Epic Checklist Template
# Feature Request
## Why
*insert the purpose of the Epic or sub-epic here*
> Insert the purpose of the Epic or sub-epic here*
## Proposed Solution
*insert proposed solution, with relevant links here*
> Insert proposed solution, with relevant links here*
## Definition of Done Checklist
**Package:**
- [ ] Do you have a 'main' branch that is default and protected?
- [ ] Are all other branches merged or deleted? For master and dev branches, tag the branch commit before deleting the branch
so we can retrieve it if necessary. Exception: branches labeled release
- [ ] Are all other branches merged or deleted? For master and dev branches, tag the branch commit before deleting the branch so we can retrieve it if necessary. Exception: branches labeled release
- [ ] Does the repo contain only the following directories: chart, docs, tests? All other directories should be deleted.
- [ ] Is there a CODEOWNERS file containing some code owners?
- [ ] Is there a CHANGELOG.md file with initial changes?
- [ ] Is there a README.md file documenting basic use?
- [ ] Is there a CONTRIBUTING.md file outlining how a new person can contribute?
- [ ] Is there a .gitlab-ci.yml pipeline setup pointing to a pipeline template?
- [ ] Is there a tests/test-values.yaml file setup to provide default values for the pipeline? This must include image pull
secret references.
- [ ] Is there a chart/Kptfile that points to the upstream chart used in the repo? Exception: Not needed if upstream chart is
not used.
- [ ] Does the upstream chart version deploy the application version used in Iron Bank (or as close as possible)? This will
help avoid incompatible configuration settings.
- [ ] Have you run helm dep up and added all .tgz file dependencies in chart/charts to the repo?
- [ ] Have you updated chart/requirements.yaml or chart/Chart.yaml to point to the file://./charts/<file>.tgz dependencies?
- [ ] If the chart has a web interface, have you added a VirtualService using hostname that is conditionally added if
istio.enabled is true? Verify this works using the web address.
- [ ] If the chart integrates with Prometheus monitoring, have you added a Service and ServiceMonitor that are conditionally
added if monitoring.enabled is true? Verify this using Prometheus to check targets.
- [ ] Is there a 'CODEOWNERS' file containing some code owners?
- [ ] Is there a 'CHANGELOG.md' file with initial changes?
- [ ] Is there a 'README.md' file documenting basic use?
- [ ] Is there a 'CONTRIBUTING.md' file outlining how a new person can contribute?
- [ ] Is there a '.gitlab-ci.yml' pipeline setup pointing to a pipeline template?
- [ ] Is there a 'tests/test-values.yaml' file setup to provide default values for the pipeline? This must include image pull secret references.
- [ ] Is there a 'chart/Kptfile' that points to the upstream chart used in the repo? Exception: Not needed if upstream chart is not used.
- [ ] Does the upstream chart version deploy the application version used in Iron Bank (or as close as possible)? This will help avoid incompatible configuration settings.
- [ ] Have you run helm dep up and added all .tgz file dependencies in 'chart/charts' to the repo?
- [ ] Have you updated 'chart/requirements.yaml' or 'chart/Chart.yaml' to point to the 'file://./charts/<file>.tgz' dependencies?
- [ ] If the chart has a web interface, have you added a VirtualService using hostname that is conditionally added if istio.enabled is true? Verify this works using the web address.
- [ ] If the chart integrates with Prometheus monitoring, have you added a Service and ServiceMonitor that are conditionally added if monitoring.enabled is true? Verify this using Prometheus to check targets.
- [ ] Does your package have resource requests and limits set and equal to each other?
- [ ] Do you have a tag on your main branch for the Big Bang release version of the package?
- [ ] Have all of your images been updated to pull from registry1.dso.mil. Exception: If there is no Iron Bank image, are you
pulling from registry.dso.mil?
- [ ] Have all of your images been updated to pull from registry1.dso.mil. Exception: If there is no Iron Bank image, are you pulling from registry.dso.mil?
- [ ] If the package supports SSO, have you integrated SSO settings? Needs clarification
- [ ] If the package requires a database, have you integrated external database settings? Needs clarification
- [ ] If the package requires storage, have you integrated external storage (e.g. MinIO) settings? Needs clarification
- [ ] Are all secrets and certificates removed from the repo? All secrets should be references or randomly generated during
deployment.
- [ ] Are all secrets and certificates removed from the repo? All secrets should be references or randomly generated during deployment.
**Big Bang:**
- [ ] Have you added a namespace.yaml in chart/templates that sets up the package's namespace
- [ ] Have you added pull secret creation to a resource? This may be in the namespace.yaml file.
- [ ] Have you added a gitrepository.yaml in chart/templates that sets up a flux GitRepository resource pointing to the
package's git repository?
- [ ] Have you added a helmrelease.yaml in chart/templates that sets up a flux HelmRelease resource pointing to the package's
helm chart?
- [ ] Have you added default values to the HelmRelease that need to be passed downstream to the package? For example:
hostname, istio.enabled, monitoring.enabled.
- [ ] Have you added a 'namespace.yaml' in 'chart/template's that sets up the package's namespace
- [ ] Have you added pull secret creation to a resource? This may be in the 'namespace.yaml' file.
- [ ] Have you added a 'gitrepository.yaml' in 'chart/templates' that sets up a flux GitRepository resource pointing to the package's git repository?
- [ ] Have you added a 'helmrelease.yaml' in 'chart/templates' that sets up a flux HelmRelease resource pointing to the package's helm chart?
- [ ] Have you added default values to the HelmRelease that need to be passed downstream to the package? For example: hostname, istio.enabled, monitoring.enabled.
- [ ] Have you added image pull secret references to the HelmRelease to be passed downstream to the package?
- [ ] Have you added other package dependencies to the HelmRelease to insure deployment order?
- [ ] Have you added a key for <package>.yaml into chart/templates/values.yaml so override values can be passed downstream to
the package?
- [ ] Have you added a valuesFrom configuration in the HelmRelease pointing to the values secret with a valuesKey equal to
<package>.yaml?
- [ ] Have you added the package into chart/values.yaml under addons? Exception: core apps do not go under addons.
- [ ] Have you added enabled: false to your chart/values.yaml and conditional statements on enabled: true for your namespace,
pull secret, git repository, and helm release?
- [ ] Have you added git repo configuration to chart/values.yaml pointing to the packages git repo, helm chart path, and tag.
- [ ] Have you added a values: {} placeholder for you package in chart/values.yaml?
- [ ] Have you added any applicable default values from Fences and Party Bus to the package? Exception: Infrastructure
specific implementations (e.g. AWS)
- [ ] Have you verified that
Additional details on definition of done need to be added for:
- [ ] Have you added a key for '<package>.yaml' into 'chart/templates/values.yaml' so override values can be passed downstream to the package?
- [ ] Have you added a valuesFrom configuration in the HelmRelease pointing to the values secret with a valuesKey equal to '<package>.yaml'?
- [ ] Have you added the package into 'chart/values.yaml' under addons? Exception: core apps do not go under addons.
- [ ] Have you added enabled: false to your 'chart/values.yaml' and conditional statements on enabled: true for your namespace, pull secret, git repository, and helm release?
- [ ] Have you added git repo configuration to 'chart/values.yaml' pointing to the packages git repo, helm chart path, and tag.
- [ ] Have you added a values: {} placeholder for you package in 'chart/values.yaml'?
- [ ] Have you added any applicable default values from Fences and Party Bus to the package? Exception: Infrastructure specific implementations (e.g. AWS)
- [ ] Have you verified that additional details on definition of done need to be added for:
- Database integration
- Storage (minio) integration
- Certificates?
- SSO integration
**Testing:**
- [ ] Have you verified the CI/CD pipeline passes?
- [ ] Have you verified the application is available via web URL (if applicable)?
- [ ] Have you verified you can login via SSO with your Platform One account (if applicable)?
......
charter/NewPackageRequests.md
+ 1
− 1
View file @ 097b97b6
# New Big Bang Packages
This is the process for adding a new package into Big Bang
This is the process for adding a package into Big Bang.
## Submit New Big Bang Package Proposal to the BB Technical Oversite Committee
......
charter/PackageRequirements.md
+ 1
− 1
View file @ 097b97b6
......@@ -4,7 +4,7 @@ All Big Bang Packages shall adhere to the following requirements. Where possibl
[[_TOC_]]
## Gitlab Project Settings
## GitLab Project Settings
* The `main` branch should be default in each project
* Merge Requests should require 1 approver
......
charter/SprintPlanning.md
+ 2
− 2
View file @ 097b97b6
......@@ -6,13 +6,13 @@ Responsible for building the COMMON Big Bang product.
### Normal Rhythm
* One week sprints ( Tuesday noon to Tuesday noon )
* Two week sprints starting on a Tuesday
* Continue to improve planning every week
* All team members who have capacity to work on the PRODUCT backlog should attend the planning session
### Work Breakdown
* The Big Bang PRODUCT work will be continuously updated within Jira by the BB PMs, Anchors, and Epic Leads
* The Big Bang PRODUCT work will be continuously updated within GitLab by the Big Bang Product Manager, Anchors, and Anchor Shanks
* The pre-planning activity will execute the following planning steps:
1. Review current team objectives
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment

UNCLASSIFIED - NO CUI