Merge branch 'charter-design-updates' into 'master'

BB Docs Design Update

See merge request platform-one/big-bang/bigbang!1729

.gitlab/README.md.gotmpl → .gitlab/base_config.md.gotmpl

@@ -5,18 +5,6 @@
 
 {{ template "chart.description" . }}
 
-{{ template "chart.homepageLine" . }}
-
-> _This is a mirror of a government repo hosted on [Repo1](https://repo1.dso.mil/) by [DoD Platform One](http://p1.dso.mil/).  Please direct all code changes, issues and comments to https://repo1.dso.mil/platform-one/big-bang/bigbang_
-
-Big Bang follows a [GitOps](#gitops) approach to configuration management, using [Flux v2](#flux-v2) to reconcile Git with the cluster.  Environments (e.g. dev, prod) and packages (e.g. istio) can be fully configured to suit the deployment needs.
-
-## Usage
-
-Big Bang is intended to be used for deploying and maintaining a DoD hardened and approved set of packages into a Kubernetes cluster.  Deployment and configuration of ingress/egress, load balancing, policy auditing, logging, monitoring, etc. are handled via Big Bang.   Additional packages (e.g. ArgoCD, GitLab) can also be enabled and customized to extend Big Bang's baseline.  Once deployed, the customer can use the Kubernetes cluster to add mission specific applications.
-
-Additional information can be found in [Big Bang Docs](./docs/README.md).
-
 ## Getting Started
 
 To start using Big Bang, you will need to create your own Big Bang environment tailored to your needs.  The [Big Bang customer template](https://repo1.dso.mil/platform-one/big-bang/customers/template/) is provided for you to copy into your own Git repository and begin modifications.
@@ -28,7 +16,3 @@ To start using Big Bang, you will need to create your own Big Bang environment t
 {{ template "chart.requirementsSection" . }}
 
 {{ template "chart.valuesSection" . }}
-
-## Contributing
-
-Please see the [contributing guide](./CONTRIBUTING.md) if you are interested in contributing to Big Bang.

charter/BigBang.md

-# Big Bang
-
-The end consumable of the Big Bang team is a single consumable that allows the installation of all supported [Big Bang Packages](BigBangPackages.md).  

charter/DevCIWorkflow.md

-# Big Bang Developer / CI Workflow
-
-This diagram overviews the BigBang workflow that Developers will use in the processes of feature development, merge request submission, and subsequent release merges.
-
-This diagram also overviews the specific CI pipelines that currently exist to assist and accelerate these general processes.
-
-![Developer / CI Workflow](imgs/dev_ci_workflow.png)
-
-[Link to draw.io diagram file](diagrams/dev_ci_workflow.drawio). This diagram file should be modified on draw.io and exported into this repository when the developer / ci workflow changes. It is provided here for ease of use.

charter/DocumentationLocations.md

-# 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? 
-
-- 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? 
-
-- 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? 
-
-- 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](./PackageDocumentation.md) for more info)
-- Currently the docs are hosted for consumption on https://docs-bigbang.dso.mil/
-- 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

-# GitLab Labels
-
-[[_TOC_]]
-
-## Epics
-
-Epics are required to have `priority`, `size` and `status` labels.
-
-### Epic Label `status`
-
-Status captures the state of the Epic
-
-`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.
-
-`status::ready`
-: The epic is accepted by the team and ready for breakdown of work as priority dictates.
-
-`status::doing`
-: Work has been broken out from this epic and is assigned to milestones for completion
-
-#### `priority::1`
-
-`priority::1` issues are causing runtime issues in production environments. These issues justify a patch of a release.
-
-#### `priority::2`
-
-`priority::2` TBD
-
-#### `priority::3`
-
-`priority:: 3` issues are defined by bugs that degrade system performance, but workarounds are available.
-
-#### `priority::4`
-
-`priority:: 4` TBD
-
-#### `priority::5`
-
-`priority::5` issues are superficial and do not have any impact on the functioning of production systems
-
-The `size` label helps identify the scope of work needed as part of the epic
-
-`size::small`
-: Sufficiently small enough to be completed by an engineer in a two week period
-
-`size::medium`
-: A small number of engineers could complete this in a two week period
-
-`size::large`
-: This epic should be broken down further into consumable sub-epics
-
-`size::xl`
-: This epic needs to be broken down further to be able to be tackled in a sprint
-
-## 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. The priority of issues that are not part of an Epic will need to be determined by a package owner or maintainer.
-
-### Issue Label `kind`
-
-The `kind` label shows the type of work that needs to be accomplished.
-
-`kind::bug`
-: Issues related to BigBang not functioning as expected.
-
-`kind::maintenance`
-: Catch all kind that captures administrative tasking for the BigBang project
-
-`kind::ci`
-: Issues related to the CI/CD, developer workflows and/or the release process.
-
-`kind::docs`
-: Issues related to documentation.
-
-`kind::feature`
-: Creation of a new capability for BigBang and/or one of its packages
-
-`kind::enhancement`
-: Improvement of an existing capability to work more efficiently in specific environments
-
-`kind::test`
-: Improvements on testing for individual packages or Big Bang.  Does not change the actual CI/CD pipelines, just enhances the test suite.
-
-### Issue Label `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 issue is ready to be reviewed by a Maintainer
-
-### Issue Package Labels
-
-Package labels are identified by their package name and serve two purposes.
-
-> 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.
-
-## Merge Requests
-
-Merge Requests are required to have `status` and `kind` labels.
-
-### Merge Requests Label `status`
-
-Status captures the state of the Merge Request
-
-#### `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.
-
-#### `status::ready`
-
-The epic is accepted by the team and ready for breakdown of work as priority dictates.
-
-#### `status::doing`
-
-Work has been broken out from this epic and is assigned to milestones for completion
-
-#### `status::blocked`
-
-Epic is blocked by an external dependency that needs to be solved before work can be completed.  This may be other Big Bang Epic or an Epic from another ValueStream.
-
-### Priority
-
-#### `priority::1`
-
-Top of the backlog and should be broken down and worked on when cycles become available.
-
-#### `priority::2`
-
-TBD
-
-#### `priority::3`
-
-Medium term delivery providing long term value.
-
-#### `priority::4`
-
-TBD
-
-#### `priority::5`
-
-A nice to have, but not needed to advance the product.
-
-### Size
-
-The `size` label helps identify the scope of work needed as part of the epic
-
-#### `size::small`
-
-Sufficiently small enough to be completed by an engineer in a two week period
-
-`status::doing`
-: Work is actively being done on this Merge Request
-
-`status::review`
-: The Merge Request is ready to be reviewed by a Maintainer
-
-### Merge Requests Packages Label
-
-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
-
-`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.
-
-`test-ci::release`
-: The test CI `release` label for a Merge Request causes all release CI jobs to run, including bundling of airgap artifacts.
-
-`charter`
-: This Merge Request has a proposed change to the Charter

charter/Glossary.md

-# 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).
-
-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/New GitLab Epic Checklist Template

-# New Epic Checklist Template
-
-# Feature Request
-
-## Why
-
-> Insert the purpose of the Epic or sub-epic here*
-
-## Proposed Solution
-
-> 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
-- [ ] 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.
-- [ ] 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?
-- [ ] 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.
-
-**Big Bang:**
-
-- [ ] 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:
-- 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)?
-- [ ] Have you verified you Prometheus is scraping data from monitoring endpoints on the application (if applicable)?
-- [ ] Have you verified the application has database connectivity to the external database (if applicable)?
-- [ ] Have you verified the application has storage connectivity to the external storage (if applicable)?
-
-## Future Work (as separate issues)
-
-- [ ] SSO is integrated as BigBang values

charter/NewPackageRequests.md

-# New Big Bang Packages
-
-This is the process for adding a package into Big Bang.
-
-## Submit New Big Bang Package Proposal to the BB Technical Oversite Committee
-
-[BB TOC New Package Proposal](https://repo1.dso.mil/platform-one/p1toc/-/issues/new?issue%5Bassignee_id%5D=&issue%5Bmilestone_id%5D=)
-
-A shepherd will be assigned to the project to create a repo in the [BB sandbox](https://repo1.dso.mil/platform-one/big-bang/apps/sandbox)
-
-### Process
-
-New packages packages will follow the [BBTOC process](https://repo1.dso.mil/platform-one/bbtoc/-/tree/master/process) from Sandbox -> Incubating -> Graduated

charter/PackageDocumentation.md

-# Package Documentation
-
-## Documentation Needed
-
-For every package, we need to inform users how to configure the application.
-This includes:
-
-* Pre-installation configuration parameters
-* Post-installation package configuration
-* SSO Integration
-
-## Delivery Method
-
-The documentation should be versioned along-side the package as it is released. The end user also needs a consistent way to view this documentation when BigBang and addons are installed into a Kubernetes Cluster. This should over time have parity with features that are offered on Party Bus.
-
-## Tooling
-
-### Needs
-
-* Documentation should be easily accessible to an end user when BigBang is installed
-* Needs to be air-gapped friendly for those in disconnected environments
-* Links should be clickable within the documentation. i.e. sonarqube.bigbang.dev might be sonarqube.customer.mil
-
-### What is Hugo
-
-Hugo is a website template engine. It can take a group of files and create a static website from them. Input can be a variety of formats including markdown.
-
-### BigBang Usage of Hugo
-
-Since we already write documentation in markdown, little work will be needed to convert these markdown files into something Hugo can render. The idea is to enforce a directory structure for the documentation so that Hugo can pull in relevant documentation and render it once installed.
-
-The documentation should include:
-
-* Purpose of the tool or add-on
-* Recommended post-installation configuration
-* Optional post-installation configuration
-* Additional configuration that can be done on the tool through automation
-
-## Hugo Specifics
-
-### How it works
-
-1. Each package contains a docs folder with the file structure below.
-2. When the documentation package spins up, it reaches out to all the relevant repos and downloads the docs folder into the hugo container.
-3. The container than does a hugo compile with all the documentation to give us our static site.
-
-### Directory Structure
-
-```text
-package
-|--docs
-   |  index.html [landing page for application within hugo]
-   |  overview.md [Overview of application, purpose, and default config options]
-   |  keycloak.md [Manual or automated steps to configure sso]
-   |  example-optional-config.md [Additional files for optional configuration for the app]
-```
-
-### Formatting Needed
-
-Each file should start with a block that looks as follows:
-
-```text
-+++
-draft = false
-
-title = "ArgoCD Overview"
-author = "Big Bang Team"
-
-virtualServices = ["argocd"]
-+++
-```
-
-By including this at the top of a markdown file, hugo can now render this page.
-
-### CI/CD pipeline additions
-
-* Ensure that docs meet the standards when changes occur

charter/PackageRequirements.md

-# Package Requirements
-
-All Big Bang Packages shall adhere to the following requirements.  Where possible, each package shall validate these requirements in their CI/CD processes
-
-[[_TOC_]]
-
-## GitLab Project Settings
-
-* The `main` branch should be default in each project
-* Merge Requests should require 1 approver
-* The `main` branch should be protected:
-  * Developers + Maintainers should be allowed to merge.  
-  * No one should be allowed to push and it should allow
-  * CODEOWNERs approval should be allowed
-* There should exist a protected tag with the wildcard `*-bb*`
-
-## PR-X. Kubernetes Cluster Requirements
-
-Each package will work with any cluster under the following criteria.
-
-* Kubernetes Versions "Latest -2".  Current latest is 1.20, so also supports 1.19 and 1.18.
-* [Cloud Native Computing Federation Kubernetes Certified Distribution](https://www.cncf.io/certification/software-conformance/).
-* Default Storage Class with RWO
-
-## PR-X. Iron Bank Images
-
-Big Bang Package shall be configured to use Iron Bank images.  The images used from Iron Bank __must__ be _fully_ approved and _functional_ to be in compliance with the Big Bang baseline security posture.
-
-Please see [New Package Requests](NewPackageRequests.md) and the [BBTOC process](https://repo1.dso.mil/platform-one/bbtoc/-/tree/master/process) for additional pre-requisites. 
-
-## PR-X. Packages are Helm Charts
-
-All packages that the Big Bang product consume are helm charts.  This decision is explored in depth in the ADR [here](http://about:blank).  The quick summary is that helm provides the best tools for the problem statement that Big Bang is built to address: an opinionated yet configurable deployment of the Platform One baseline.
-
-### Helm Chart Types
-
-Baselining off of the assumption that all packages are helm charts, we can identify _two_ different types of packages:
-
-#### Upstream Helm Charts
-
-Many of the tools and applications that BigBang deploys have actively maintained helm charts, rather than re-inventing the wheel, it is encouraged to leverage charts maintained by vendors or the community.  
-
-The unfortunate downside to helm is the lack of chart customization _without_ forking from upstream.  While there are several options out there (post-rendering, etc...) that are slowly becoming more widespread, the unfortunate reality is upstream charts that BigBang consumes must be forked into repo1 and the appropriate changes must be made.
-
-Forked upstream helm charts will be configured with the appropriate BigBang _additions_, and in rare cases, _modifications_.  They will be versioned in accordance with BigBangs [package versioning scheme](#pr-x.-package-versioning-scheme).
-
-#### Custom Helm Charts
-
-In the case where an accepted upstream helm chart does not exist, BigBang will create and maintain it's own custom helm chart for the package in question.  The helm chart will be in conformance with the [Package Standards](#pr-x.-package-standards).
-
-### Documentation for how to upgrade the Package helm charts
-
-The Package chart should include maintenance documentation that describes
-1. The process for upgrading
-2. How to test the upgrade
-3. Documentation for changes made to the upstream chart.
-
-This documentation will be located in each Package repo and named `/docs/DEVELOPMENT_MAINTENANCE.md`. The document should be linked from the top level `/CONTRIBUTING.md` in the "To contribute a change" section item #2.
-
-## PR-X. Package Standards
-
-The common components that each package will have are defined in the following folder layout:
-
-```shell
-├── CODEOWNERS              # GitLab Code Owners for Package Owners/Understudies.
-├── README.md               # top level summary of package
-├── docs/                   # detailed documentation folder describing package consumption details and assumptions
-├── tests/
-    ├── cypress             # folder containing e2e tests using the cypress test framework
-├── chart/                  # Folder containing helm chart
-    ├── templates           # folder helm chart templates
-      ├── tests             # folder containing helm chart tests 
-```
-
-## PR-X. CI/CD pipeline is required for each Big Bang Package
-
-Each package shall contain a .gitlab-ci.yml file at the top of the package repo.   This file shall reference the pipeline CI/CD infrastructure
-files and include the following contents:
-
-```shell
-include:
-  - project: 'platform-one/big-bang/pipeline-templates/pipeline-templates'
-    ref: master
-    file: '/templates/package-tests.yaml'
-```
-
-## PR-X. Dependencies must be a Big Bang Package
-
-If a Package has a dependency on another Package to function, the dependency shall also be a Big Bang Package
-
-## PR-X. Dependency Matrix
-
-Each Package will clearly articulate in documentation any dependent Big Bang Package and versions.
-
-## Branching
-
-Each package will have a default branch of `main`.  Immutable tags will be used to identify releases and will follow a semver versioning scheme.  For more information, see the [versioning](#pr-x.-package-versioning-scheme) section.
-
-## Package Standards
-
-* Helm Packages contain one kubernetes object definition
-
-* Helm dependency manage charts dependencies in Chart.yaml and the dependency chart can be enabled or disabled using condition.
-* All Chart names are lower case letters and numbers, separated with dashes. No dots, uppercase or underscores.
-* Helm Chart values variable names should begin with a lowercase letter and words should be separated with Camel case
-* Helm chart dependency version,use version ranges instead of pinning to an exact version.
-    version: ~1.2.3
-* There should be a Helm values file located at `tests/test-values.yaml` used for pipeline testing.
-* Charts should support `affinity` and `nodeSelector` configuration for all components.  If there is only one type of `Pods`, then a single, top level value shall be provided, otherwise there should be `affinity` and `nodeSelector` regions for each component.  See [the Kubernetes Docs](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) for more information

charter/README.md

-# Big Bang
-
-## Scope
-
-Big Bang's scope is to provide publicly available installation manifests for:
-
-* a specific set of packages that adhere to the [DevSecOps Reference Architecture](https://software.af.mil/dsop/documents/#documents).  The set of packages are listed here: [Big Bang Application List](BigBangPackages.md)
-* packages that facilitate development of applications that adhere to the DevSecOps Reference Architecture
-
-Big Bang also builds tooling around the testing and validation of Big Bang packages.  These tools are provided as is, without support.
-
-## Big Bang Packages
-
-A Big Bang Package (BBP) is manifests that adhere to the requirements outlined in [Application Requirements](PackageRequirements.md).  
-
-Each BBP has a set of Owners whose responsibility is outlined in [Package Owners](PackageOwner.md).
-
-Each BBP follows its own release cycle adhering to at least the requirements outlined in [Release Process](ReleaseProcess.md).
-
-## Change to the Charter
-
-All changes to the charter must be requested via Merge Request into the master branch.
-
-## Bi-weekly Meetings
-
-The Big Bang project will have a bi-weekly meeting to discuss global issues that are occurring across applications.  Meeting minutes/notes will be kept and posted in a separate repository, and all meetings will be recorded and hosted for public availability.  All policy decisions can be talked about during these meetings, but nothing is final until merged into this repository, following the requirements for updating the charter.

charter/Scratch.md

-# Scratch
-
-Comments from meetings
-
-## Apps
-
-* Should any product need to be licence (e.g. why Anchore Enterprise and not Anchore)
-* Should everything used by apps be internal?  E.g. Postgres required for Keycloak
-* Which of Anchore vs Anchore Enterprise
-
-* Consistent Interface.  Only "supported" BigBang configuration
-
-Testing stuff
-
-## Kubernetes Tools E2E Testing Frameworks
-
-### Each Applications E2E tests
-
-Is there a way to get each application to run its own e2e tests against the deployed version?
-
-e.g. for Argo:
-<https://github.com/argoproj/argo-cd/blob/master/.github/workflows/ci-build.yaml>
-
-### Istio
-
-Istio uses Prow: <https://github.com/istio/test-infra>
-
-### KUTTL
-
-KUTTL allows for the verification of Kubernetes objects (and status) based on application of various kubernetes yaml objects.
-This easily allows for testing the health of all the objects (per status fields), but doesn't provide integration tests unless we
-build all the integration tests into CRDs or into Kubernetes Jobs:
-
-APP
-
-* manifests/linting
-* k3d healthy"
-* smoke tests
-
-Integration Tests
-*
-
-Single release of all app versions in single place.  Tested by BB
-
-Customer extensions need to be tested in their own moc environment
-
-Common Integration:
-
-* "App of Apps"
-
-Mock Integration environments
-
-* sample implementation of customer
-
-## Keycloak
-
-Table discussion
-
-API:*
-
-* can't change image tags
-* can change repo to allow for airgapped repos

charter/SprintPlanning.md

-# Product Team
-
-Responsible for building the COMMON Big Bang product.
-
-## Product Team Sprint Planning
-
-### Normal Rhythm
-
-* 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 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
-1. (Re-)prioritize work at the Epic level
-1. Assess ( ballpark ) amount of the work the team can accomplish within the next week
-
-* The planning activity will execute the following planning steps per planning "team":
-
-1. Review/update the currently OPEN and prioritized Epics provided by the pre-planning activity
-1. Decompose the Epic work into stories by writing new or updating existing stories in Jira to accomplish the Epic objectives
-1. Identify and capture any intra-story dependencies in Jira
-1. Prioritize the stories to be accomplished
-1. Add stories to the sprint backlog roughly equivalent to the team's capacity
-
-### Sprint Execution
-
-* Daily PRODUCT team standup -
-Should discuss EPIC level issues ( dependencies, issues,etc) and be less than 15 minutes
-* Daily EPIC team scrums - team members brief based on Jira Story or Task
-
-1. Review accomplishments in the last 24 hours
-1. Planned work in the next 24 hours
-1. Any blockers or helps required
-1. Individual Stories will be accepted
-1. Sprint retro ( bi-weekly to start on Thursday to inform Tues planning)
-1. Sprint DEMO - working software
-1. [FUTURE] Team capacity planning
-
-### Core Concepts
-
-* Succeed or fail as a team
-* Work pairing is highly encouraged
-* Collaboration/Communication will be key to team success
-* Look for ways to improve the PRODUCT and the process

charter/Support.md

-# Support
-
-Big Bang will provide support for all Big Bang Applications.  This document outlines the support model from the Big Bang team:

charter/TeamRhythm.md

-# Team Rhythm
-
-## Internal Team meetings
-
-|Title| Purpose |Attendees | Frequency|Days|
-|:---|:----- |:----------|:--------------|:-------------------|
-|PM Tagup|Discuss Cross team issues and priorities for the week|Integration PM & Product PM|Weekly|M|
-|Team Tagup|Discuss overall team issues|BB Team|Weekly|T|
-|Sprint Planning|Plan sprint work|Epic Teams|Weekly|T|
-|T3|Team technical collab|BB Team|Weekly|R|
-|Charter Review|Charter pull request review|BB Team|Weekly|R|
-|JETT Tagup|PM & Anchor tagup & alignment|JETT|Daily|M-F|
-|Integration Standup|Discuss priorities & issues|Integration Team|Daily|M-F|
-|Product Standup|Discuss priorities & issues|Product Team|Daily|M-F|
-|Product Epic Teams Scrum|Previous Planned Issues|Product Epic Scrum Teams|Daily|M-F|
-|Integration Epic Teams Scrum|Previous Planned Issues|Integration Epic Scrum Teams|Daily|M-F|
-
-## External Team meetings
-
-|Title| Purpose |Attendees | Frequency|Days|
-|:---|:----- |:----------|:--------------|:-------------------|
-| P1 PM Tagup|Agenda driven P1 PM mtg|P1 PMs|Weekly|M|
-| P1 PM Tagup|Non-Agenda driven P1 PM mtg|P1 PMs|Weekly|F|
-| CSO/P1 Leads|Discuss xyz|P1 PMs|Bi-Weekly|F-A|
-| CSO/P1/C1/Other Leads|Discuss xyz|P1 PMs|Bi-Weekly|F-B|
-| P1 Daily|Discuss BB Current SOA|Daily crowd|Bi-Weekly|M-W2|

charter/Teams.md

-# Teams
-
-[[_TOC_]]
-
-## Engineering
-
-Big Bang consists of two primary missions: Product Development and Integration
-
-## Product Development
-
-Product development consists of improving Big Bang Applications used by all customers:
-
-* Upgrading application versions
-* Improving reliability
-* Adding configuration options used by multiple customers
-* Improving interface for customer consumption
-
-## Integration
-
-Integration consists of facilitating user adoption of Big Bang by providing:
-
-* On the ground debugging of production issues
-* Creation of Environment Bootstrap pipelines to test changes in versions of Big Bang Umbrella
-
-## Communication
-
-Execution in these two engineering efforts requires tight collaboration and feedback loop with each other and external teams as defined in the diagram below:
-
-![communication](imgs/communication.png)
-
-### Product and Integration
-
-#### Product to Integration
-
-* Change logs
-* Tier 2/3 support for application specific issues in customer production environments
-
-#### Integration to Product
-
-* Bugs from customers that need to be solved in Big Bang Applications
-* Common "extensions" of Big Bang Umbrella that should be added to provide consistency across customers
-* Mock environments for Umbrella testing
-
-### Integration and Customers
-
-#### Integration To Customers
-
-* Changelog of new versions of Big Bang Umbrella
-* Building
-
-#### Customers to Integration
-
-* Bugs
-* Environment specifics that can go back into Mock Environments as defined in [Testing](Testing.md)
-
-### Product and Iron Bank
-
-#### Product to Iron Bank
-
-* Requests for new/updated Iron Bank Images
-* pipelines for testing Iron Bank Image functionality
-
-#### Iron Bank to Product
-
-* Approval of Iron Bank Images

charter/packages/README.md

-# README
-
-All packages should have a folder under the `/packages` directory named `/packages/<name>` that contains all relevant information related to the Big Bang team assessment for inclusion into the Big Bang baseline
-
-**Do we maintain this information as packages are approved?**