Update docs/FAQ.md, blog/big-bang-2-0.md, blog/dev-bigbang-mil-certificate.md,...

0be366a3 · Caitlin Bowman-Clare · Andrew Shoell · 29cfdf5f · 0be366a3 · 0be366a3
Commit 0be366a3 authored 7 months ago by Caitlin Bowman-Clare Committed by Andrew Shoell 7 months ago
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
 # Contributing to Big Bang
-Thanks for taking the time to contribute to BigBang!
+Thanks for taking the time to contribute to Big Bang!
-If you are coming from `repo1.dso.mil` and have an account at `login.dso.mil` please keep reading. If you are coming from or looking for the [project on Github](https://github.com/DoD-Platform-One) and wanting to make a Pull Request without a `dso.mil` account please see the last section [External Github Contributions](#community-contributions-to-dod-platform-one-via-github).
+If you are coming from `repo1.dso.mil` and have an account at `login.dso.mil`, please keep reading. If you are coming from or looking for the [project on Github](https://github.com/DoD-Platform-One) and wanting to make a Pull Request without a `dso.mil` account, please see the last section [External Github Contributions](#community-contributions-to-dod-platform-one-via-github).
 Table of Contents:
@@ -20,30 +20,30 @@ Table of Contents:
 ## Developers Guide
-Big Bang is designed in such a way as to be as easily deployed locally as it is in production.  In fact, most contributions begin locally.
+Big Bang is designed in such a way as to be as easily deployed locally as it is in production. In fact, most contributions begin locally.
 ## Iron Bank Images
-Per the [charter](https://repo1.dso.mil/big-bang/charter), all Big Bang packages will leverage container images from [IronBank](https://ironbank.dso.mil/).  In order to pull these images, ImagePullSecrets must be provided to Big Bang.  To obtain access to these images, follow the guides below.  These steps should NOT be used for production since the API keys for a user are only valid when the user is logged into [Registry1](https://registry1.dso.mil)
+Per the [charter](https://repo1.dso.mil/big-bang/charter), all Big Bang packages will leverage container images from [IronBank](https://ironbank.dso.mil/).  In order to pull these images, ImagePullSecrets must be provided to Big Bang. To obtain access to these images, follow the guides provided in this document. These steps should NOT be used for production since the API keys for a user are only valid when the user is logged into [Registry1](https://registry1.dso.mil)
-1) Register for a free Iron Bank account [Here](https://sso-info.il2.dso.mil/new_account.html)
+1) Register for a free Iron Bank account [Here](https://sso-info.il2.dso.mil/new_account.html).
 1) Log into the [Iron Bank Registry](https://registry1.dso.mil), in the top right click your *Username* and then *User Profile* to get access to your *CLI secret*/API keys.
-1) When installing BigBang, set the Helm Values `registryCredentials.username` and `registryCredentials.password` to match your Registry1 username and API token
+1) When installing BigBang, set the Helm Values `registryCredentials.username` and `registryCredentials.password` to match your Registry1 username and API token.
 ## Local Kubernetes cluster
 Follow the steps below to get a local Kubernetes cluster for Big Bang  using [k3d](https://k3d.io/).
 ```bash
-# Create a local k3d cluster with the appropriate port forwards (tested on version 5.4.1)
+# Create a local k3d cluster with the appropriate port forwards (tested on version 5.4.1).
 k3d cluster create --k3s-arg "--no-deploy=metrics-server,traefik@server:*" -p 80:80@loadbalancer -p 443:443@loadbalancer
 ```
 ## Deploying Big Bang (Quick Start)
-For development, it is quicker to test changes without having to push to Git.  To do this, we can bypass Flux2 and deploy Big Bang directly with its Helm chart.
+For development, it is quicker to test changes without having to push to Git. To do this, we can bypass Flux2 and deploy Big Bang directly with its Helm chart.
-Start by creating `myvalues.yaml` to configure your local Big Bang.  The Big Bang template repository contains a starter [development values.yaml](https://repo1.dso.mil/big-bang/customers/template/-/blob/main/package-strategy/configmap.yaml).
+Start by creating `myvalues.yaml` to configure your local Big Bang. The Big Bang template repository contains a starter [development values.yaml](https://repo1.dso.mil/big-bang/customers/template/-/blob/main/package-strategy/configmap.yaml).
 Configure `myvalues.yaml` to suit your needs.
@@ -65,7 +65,7 @@ For more extensive development, use the [Development Guide](./docs/developer).
 ## Testing Big Bang Development Changes
-Development changes should be tested using a full GitOps environment.  The [Big Bang environment template](https://repo1.dso.mil/big-bang/customers/template/) should be replicated, either on a branch or new repository, to start your deployment.  Follow the instructions in the [template's readme](https://repo1.dso.mil/big-bang/customers/template/-/tree/main/README.md) and in the [Big Bang docs](./docs) for configuration.
+Development changes should be tested using a full GitOps environment. The [Big Bang environment template](https://repo1.dso.mil/big-bang/customers/template/) should be replicated, either on a branch or new repository, to start your deployment. Follow the instructions in the [template's readme](https://repo1.dso.mil/big-bang/customers/template/-/tree/main/README.md) and in the [Big Bang docs](./docs) for configuration.
 Follow the [Big Bang documentation](./docs) for testing a full deployment of Big Bang.
@@ -75,13 +75,13 @@ To ease with local development, the TLD `dev.bigbang.mil` is maintained by the P
 `CNAME: *.dev.bigbang.mil -> cluster.local`
-All routable endpoints BigBang deploys will use the TLD of `bigbang.dev` by default.  It is expected that consumers modify this appropriately for their environment.
+All routable endpoints BigBang deploys will use the TLD of `bigbang.dev` by default. It is expected that consumers modify this appropriately for their environment.
 ## Secrets & Certificates
 Follow instructions in the [Big Bang encryption guide](./docs/understanding-bigbang/concepts/encryption.md) for how to encrypt and decrypt secrets.
-## Merge requests process
+## Merge Requests Process
 The merge request process is provided as an overview of the pipeline stages required to get a commit merged.
@@ -96,18 +96,18 @@ Follow instruction in [CI-Workflow](./docs/developer/ci-workflow.md) for specifi
 ## How to Contribute
-1. Fork this repository, develop, and test your changes
+1. Fork this repository, develop, and test your changes.
-1. Submit a pull request
+1. Submit a pull request.
 1. Keep an eye out for comments. From bots and maintainers to ensure CI is passing and issues or suggestions are addressed.
 ### Technical Requirements
- Pipelines which must pass will run on runners from `repo1.dso.mil` and a bot will comment the status and information from the pipeline.
+* Pipelines which must pass will run on runners from `repo1.dso.mil` and a bot will comment the status and information from the pipeline.
- Any change to a Big Bang package chart requires a version bump following [semver](https://semver.org/) principles. See [Documentation Changes](#documentation-changes) and [Versioning](#versioning) below
+* Any change to a Big Bang package chart requires a version bump following [semver](https://semver.org/) principles. See [Documentation Changes](#documentation-changes) and [Versioning](#versioning) below
- Big Bang Package Issues which need to be included in the Big Bang Umbrella chart are not complete when the package PR is merged so please do not close issues. A new tag will automatically get created on `repo1.dso.mil` along with an MR into the Big Bang Umbrella as part of the CI process. This repo1 MR is reviewed the Big Bang Product team to merge on the Gitlab side, upon which the issue will be closed.
+* Big Bang Package Issues which need to be included in the Big Bang Umbrella chart are not complete when the package PR is merged so please do not close issues. A new tag will automatically get created on `repo1.dso.mil` along with an MR into the Big Bang Umbrella as part of the CI process. This repo1 MR is reviewed the Big Bang Product team to merge on the Gitlab side, upon which the issue will be closed.
- Changes to the Big Bang Umbrella get released separately according to our Release Schedule outlined in the [README](./README.md#release-schedule).
+* Changes to the Big Bang Umbrella get released separately according to our Release Schedule outlined in the [README](./README.md#release-schedule).
-Once changes have been merged all subsequent automation will run on `repo1.dso.mil` with changes getting published back to Github.
+Once changes have been merged, all subsequent automation will run on `repo1.dso.mil` with changes getting published back to Github.
 ### Documentation Changes
@@ -123,6 +123,6 @@ Big Bang umbrella MRs will not need the version in `chart/Chart.yaml` edited via
 ### Generate README
-The readme of each Big Bang package chart can be re-generated with the following command <https://repo1.dso.mil/big-bang/product/packages/gluon/-/blob/master/docs/bb-package-readme.md>
+The readme of each Big Bang package chart can be re-generated with the following command: <https://repo1.dso.mil/big-bang/product/packages/gluon/-/blob/master/docs/bb-package-readme.md>.
 Big Bang umbrella MRs will not need the main README.md edited via Pull Requests.
--- a/README.md
+++ b/README.md
@@ -18,7 +18,7 @@ In order for an installation of Big Bang to be a valid installation/configuratio
 Big Bang also builds tooling around the testing and validation of Big Bang packages. These tools are provided as-is, without support.
-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, and/or monitoring are handled via Big Bang.  Additional packages (e.g. ArgoCD and GitLab) can also be enabled and customized to extend Big Bang's baseline.  Once deployed, the Kubernetes cluster can be used to add mission specific applications.
+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, and/or monitoring are handled via Big Bang.  Additional packages (e.g., ArgoCD and GitLab) can also be enabled and customized to extend Big Bang's baseline.  Once deployed, the Kubernetes cluster can be used to add mission specific applications.
 Additional information can be found in the [Big Bang Docs](./docs/README.md).
@@ -29,29 +29,29 @@ Additional information can be found in the [Big Bang Docs](./docs/README.md).
 ## Contributing to Big Bang
-There are three primary ways to contribute to Big Bang:
+There are three primary ways to contribute to Big Bang. They are listed in the following:
- [Contribute to the Big Bang Team's Backlog](https://repo1.dso.mil/big-bang/bigbang/-/issues)
+- [Contribute to the Big Bang Team's Backlog](https://repo1.dso.mil/big-bang/bigbang/-/issues).
- [Contribute to open-source projects under the Big Bang Technical Oversight Committee (BBTOC)](https://repo1.dso.mil/big-bang/product/bbtoc/-/blob/master/CONTRIBUTING.md)
+- [Contribute to open-source projects under the Big Bang Technical Oversight Committee (BBTOC)](https://repo1.dso.mil/big-bang/product/bbtoc/-/blob/master/CONTRIBUTING.md).
- [Submit new package proposals](https://repo1.dso.mil/big-bang/product/bbtoc/-/issues/new?issue%5Bmilestone_id%5D=)
+- [Submit new package proposals](https://repo1.dso.mil/big-bang/product/bbtoc/-/issues/new?issue%5Bmilestone_id%5D=).
-  - Please review the [package integration guide](./docs/developer/package-integration/README.md) if you are interested in submitting a new package
+  - Please review the [package integration guide](./docs/developer/package-integration/README.md) if you are interested in submitting a new package.
-  - A shepherd will be assigned to the project to create a repo in the [Big Bang Community Packages](https://repo1.dso.mil/big-bang/product/community)
+  - A shepherd will be assigned to the project to create a repo in the [Big Bang Community Packages](https://repo1.dso.mil/big-bang/product/community).
 Additional information can be found in the [contributing guide](./CONTRIBUTING.md).
 ## Release Schedule
- Big Bang releases adopt a standardized versioning based on and loosely following the [Semantic Versioning 2.0.0 guidelines](https://semver.org/spec/v2.0.0.html) (major.minor.patch). These releases are not based on a fixed schedule and instead, follow the specifics in the following scheme:
+- Big Bang releases adopt a standardized versioning based on and loosely following the [Semantic Versioning 2.0.0 guidelines](https://semver.org/spec/v2.0.0.html) (major.minor.patch). These releases are not based on a fixed schedule and instead, follow the specifics in the scheme that is described in this section. 
 ### Patch Version
-A patch version increment is performed when there is a change in the tag (version number) of a Big Bang core package or a bug fix for a Big Bang template or values files. A change in the patch version number should be backwards compatible with previous patch changes within a minor version.  If there is a significant functionality change in the a core package that requires adjustments to Big Bang templates, this would require a change in the minor or major version depending on the impact to the values and secrets used to integrated the package with Big Bang.
+A patch version increment is performed when there is a change in the tag (i.e., version number) of a Big Bang core package or a bug fix for a Big Bang template or values files. A change in the patch version number should be backwards compatible with previous patch changes within a minor version. If there is a significant functionality change in the a core package that requires adjustments to Big Bang templates, this would require a change in the minor or major version depending on the impact to the values and secrets used to integrated the package with Big Bang.
 NOTE: Patch versions would not typically be created for addon package updates, rather customers would be expected to be updating those packages via `git.tag`/`helmRepo.tag` changes directly, or "inheriting" those updates through another version.
 ### Minor Version
-A minor version increment is required when there is a change in the integration of Big Bang with core or addon packages. As examples the following changes warrant a Minor version change:
+A minor version increment is required when there is a change in the integration of Big Bang with core or addon packages. For example, the following changes warrant a Minor version change:
 - Change in the umbrella values.yaml (except for changes to package version keys)
 - Change in any Big Bang templates (non bug fix changes)
@@ -60,14 +60,14 @@ Minor version changes should be backwards compatible.
 ### Major Version
-A major version increment indicates a release that has significant changes, which could potentially break compatibility with previous versions. A major change is required when there are changes to the architecture of Big Bang or critical values file keys. For example removing a core package or changing significant values that propagate to all core and add-on packages are considered major version changes. As examples of major version changes:
+A major version increment indicates a release that has significant changes, which could potentially break compatibility with previous versions. A major change is required when there are changes to the architecture of Big Bang or critical values file keys. For example removing a core package or changing significant values that propagate to all core and add-on packages are considered major version changes. Examples of major version changes are provided in the folowing:
 - Removal or renaming of Big Bang values.yaml top level keys (e.g., istio and/or git repository values).
 - Change to the structure of chart/templates files or key values.
 - Additional integration between core/add-on packages that require change to the charts of all packages.
 - Modification of Big Bang GitOps engine (i.e., switching from FluxCD -> ArgoCD).
-To see what is on the roadmap or included in a given release you can still review our [project milestones](https://repo1.dso.mil/groups/big-bang/-/milestones)
+To see what is on the roadmap or included in a given release you can still review our [project milestones](https://repo1.dso.mil/groups/big-bang/-/milestones).
 ## Community

--- a/blog/big-bang-2-0.md
+++ b/blog/big-bang-2-0.md
@@ -6,58 +6,57 @@ tags:
 # Big Bang 2.0
-What is Big Bang 2.0? Why are we doing it? 2.0 is the second major release since Big Bang 1.0 released in December 2020. This blog post should provide you with both the why behind what we're doing as well as what the changes involved are - and what that means for you as a user.
+What is Big Bang 2.0? Why are we doing it? 2.0 is the second major release since Big Bang 1.0 released in December 2020. This blog post should provide you with both the why behind what we're doing, as well as what the changes involved are, and what that means for you as a user.
 ## Why Change Things?
-A lot of the why behind 2.0 comes down to customer pain points. Here are a few of the top ones that tie into specific things changing in 2.0:
+The majority of the why behind 2.0 comes down to customer pain points. A few of the top ones that tie into specific things changing in 2.0 are listed in the following:
-1. The barrier to entry for users is too high, both from a technical/knowledge standpoint and from a cost perspective
+1. The barrier to entry for users is too high, both from a technical/knowledge standpoint and from a cost perspective.
-2. Upgrades of Big Bang are difficult, partially due to the large amount of changes in each release
+2. Upgrades of Big Bang are difficult, partially due to the large amount of changes in each release.
-3. Adding on community packages/mission apps is too hard - there's no easy (or even documented) way to add a new community package to your deployment
+3. Adding on community packages/mission apps is too hard; there's no easy (or even documented) way to add a new community package to your deployment.
+Beyond these pain points, there are also changes we are making to enable future platform improvements that necessitate a major release.
-Beyond these pain points there are also changes we are making to enable future platform improvements - that necessitate a major release.
 ## What is Changing?
 ### Free and OpenSource Core by Default
-The default core packages in 1.x releases come with both licensing and closed source concerns, as well as some usability concerns in some cases. Several of the default packages will be changing in 2.0 as a result:
+The default core packages in 1.x releases come with both licensing and closed source concerns, as well as some usability concerns in some cases. Several of the default packages will be changing in 2.0 as a result. These changes are listed in the following:
- Runtime Security: NeuVector will replace Twistlock as the default. NeuVector is opensourced and does not come with a license cost.
+* **Runtime Security:** NeuVector will replace Twistlock as the default. NeuVector is opensourced and does not come with a license cost.
- Logging: The PLG (Promtail/Loki/Grafana) stack will become the new default stack, replacing EFK (Elasticsearch/Fluentbit/Kibana). PLG has lower resource costs for users, and does not have a license requirement for core features.
+* **Logging:** The Promtail/Loki/Grafana (PLG) stack will become the new default stack, replacing Elasticsearch/Fluentbit/Kibana (EFK). PLG has lower resource costs for users, and does not have a license requirement for core features.
- Policy Enforcement: Kyverno will replace Gatekeeper as the default. Kyverno provides a better user experience for policy writing, and is more directly focused on the Kubernetes experience.
+* **Policy Enforcement:** Kyverno will replace Gatekeeper as the default. Kyverno provides a better user experience for policy writing, and is more directly focused on the Kubernetes experience.
- Tracing: Tempo will replace Jaeger as the default. Jaeger has a dependency on Elasticsearch for persistence, and Tempo is better integrated with the PLG stack to tie traces to specific logs.
+* **Tracing:** Tempo will replace Jaeger as the default. Jaeger has a dependency on Elasticsearch for persistence, and Tempo is better integrated with the PLG stack to tie traces to specific logs.
-These will be *small* breaking changes to user values. If you want to continue to deploy Twistlock for example, you will need to adjust your values to disable NeuVector and enable Twistlock before upgrading. It's also important to note that we will continue to support the alternative packages in all of these cases, we do not intend to lock users in to a single option.
+These will be *small* breaking changes to user values. If you want to continue to deploy Twistlock, for example, you will need to adjust your values to disable NeuVector and enable Twistlock before upgrading. It's also important to note that we will continue to support the alternative packages in all of these cases, we do not intend to lock users in to a single option.
 ### Standardization of Naming
-Within Big Bang, packages have a wide variety of naming conventions and mis-matches between different locations. Some packages may have a values key that doesn't match the namespace or `HelmRelease` name. In order to improve the user experience we are standardizing the names in these areas. Package values keys will line up with the namespace and `HelmRelease`/`GitRepository` name 1:1 with case translations to accommodate different usages (`camelCase` for Helm values, `kebab-case` for Kubernetes resources). In addition, Big Bang will provide a documented style guide with any exceptions to the guide.
+Within Big Bang, packages have a wide variety of naming conventions and mis-matches between different locations. Some packages may have a values key that doesn't match the namespace or `HelmRelease` name. In order to improve the user experience, we are standardizing the names in these areas. Package values keys will line up with the namespace and `HelmRelease`/`GitRepository` name 1:1 with case translations to accommodate different usages (`camelCase` for Helm values, `kebab-case` for Kubernetes resources). In addition, Big Bang will provide a documented style guide with any exceptions to the guide.
 Once again - these will be *small* breaking changes to user values and potentially has effects on any extra user scripts/tooling on top of Big Bang. Exact changes will be provided as part of a follow on blog post and in the release notes for 2.0.
 ### Improved Package Extensibility
-With 2.0 we will be providing a way to deploy community/arbitrary packages as part of Big Bang, as a "first-class" experience. This will provide a way for users to effectively extend Big Bang, and still have the lifecycle of additional packages tied to the Big Bang deployment directly. Beyond this, there will also be a new `wrapper` provided that offers some features for integration of an application inside of Big Bang, strictly via Big Bang values. This includes things like configuring `VirtualService`, `ServiceMonitor`, and `NetworkPolicy` resources.
+With 2.0 we will be providing a way to deploy community/arbitrary packages as part of Big Bang and as a "first-class" experience. This will provide a way for users to effectively extend Big Bang, and still have the lifecycle of additional packages tied to the Big Bang deployment directly. Beyond this, there will also be a new `wrapper` provided that offers some features for integration of an application inside of Big Bang, strictly via Big Bang values. This includes things like configuring `VirtualService`, `ServiceMonitor`, and `NetworkPolicy` resources.
-For additional details on what this looks like from a user/values perspective read the [extra package deployment guide](../docs/guides/deployment-scenarios/extra-package-deployment.md). This will be provided as a new feature, and not change any existing architecture/functionality.
+For additional details on what this looks like from a user/values perspective, read the [extra package deployment guide](../docs/guides/deployment-scenarios/extra-package-deployment.md). This will be provided as a new feature, and not change any existing architecture/functionality.
 ### Upgrade Process Improvements
-As mentioned in our why section - upgrades for Big Bang are hard. A big piece of this is a lack of documentation surrounding what a Big Bang upgrade should look like, and how to complete one. In 2.0 we will be providing clear documentation around updates for both single packages and the entire stack as a whole.
+As mentioned in our "Why" section, upgrades for Big Bang are hard. A big piece of this is a lack of documentation surrounding what a Big Bang upgrade should look like, and how to complete one. In 2.0, we will be providing clear documentation around updates for both single packages and the entire stack as a whole.
-One of the challenges we are balancing is keeping end users up to date with the latest security patches as quick as they release, while avoiding the danger of updating 10, 20, 30+ packages in a single upgrade. Part of our approach to resolving this pain is releasing/encouraging smaller upgrades, more often. A piece of our solution for this is providing the Renovate tool as a Big Bang package, along with guidance around usage and templates for configuration. Renovate is a tool that provides automation of dependency updates. Within the context of Big Bang this would alert end users of new package releases and provide automatic changes to the user's GitOps config repo in the form of merge/pull requests.. The ultimate goal is that customers could update packages asynchronously from the Big Bang releases (smaller updates, more often).
+One of the challenges we are balancing is keeping end users up to date with the latest security patches as quick as they release, while avoiding the danger of updating 10, 20, or 30+ packages in a single upgrade. Part of our approach to resolving this pain is releasing/encouraging smaller upgrades at a more frequent rate. A piece of our solution for this is providing the Renovate tool as a Big Bang package, along with providing guidance around usage and templates for configuration. Renovate is a tool that provides automation of dependency updates. Within the context of Big Bang, this would alert end users of new package releases and provide automatic changes to the user's GitOps config repo in the form of merge/pull requests. The ultimate goal is for customers to be able to update packages asynchronously from the Big Bang releases (i.e., smaller updates, more often).
-This again will largely look more like a new feature - although it may have implications to the current release process/cadence. We will continue to release Big Bang versions, but again we hope for these to be smaller updates due to package updates happening differently. As a result the requirements for a major/minor/patch version will be different and will be documented in the near future.
+This again will largely look more like a new feature, although it may have implications to the current release process/cadence. We will continue to release Big Bang versions, but again, we hope for these to be smaller updates due to package updates happening differently. As a result the requirements for a major/minor/patch version will be different and will be documented in the near future.
 ### OCI HelmRepositories
-OCI `HelmRepository` will be offered as a deployment option instead of `GitRepository` in 2.0. Big Bang charts are currently being published as Helm OCI artifacts in `registry1.dso.mil/bigbang` and will be published for all Big Bang core, addon, and community packages. It is important to call out that there is no inherent extra scanning/security going into these artifacts today - this is largely just a "storage format" change for the way Flux sources the Helm charts. In the future Big Bang will be signing our OCI Helm charts and providing for verification of these signatures by end users - increasing confidence in our supply chain security. We also hope that will enable future improvements to the airgap process - all artifacts needed for Big Bang will be "OCI shaped", both the images and the Helm charts.
+OCI `HelmRepository` will be offered as a deployment option instead of `GitRepository` in 2.0. Big Bang charts are currently being published as Helm OCI artifacts in `registry1.dso.mil/bigbang` and will be published for all Big Bang core, addon, and community packages. It is important to call out that there is no inherent extra scanning/security going into these artifacts today; this is largely just a "storage format" change for the way Flux sources the Helm charts. In the future, Big Bang will be signing our OCI Helm charts and providing for verification of these signatures by end users, increasing confidence in our supply chain security. We also hope this will enable future improvements to the airgap process. All artifacts needed for Big Bang will be "OCI shaped," both the images and the Helm charts.
 This is a change in the underlying architecture of Big Bang, but it will be offered as an option in 2.0 to start with, and `GitRepository` will remain the default. We anticipate changing the default in the future but `GitRepository` will remain an option long-term to enable a variety of deployment needs.
-## Where can I learn more?
+## Where can I Learn More?
-Big Bang's 2.0 epic is a great place to start [here](https://repo1.dso.mil/groups/big-bang/-/epics/217). Beyond this we encourage users to get involved via the [BBTOC](https://repo1.dso.mil/platform-one/bbtoc).
+Big Bang's 2.0 epic is a great place to start [here](https://repo1.dso.mil/groups/big-bang/-/epics/217). Beyond this, we encourage users to get involved via the [BBTOC](https://repo1.dso.mil/platform-one/bbtoc).
 Continue reading about Big Bang 2.0 in [part 2 of this series](./2-0-breaking-changes.md), which is focused specifically on the breaking changes included in 2.0.
--- a/blog/dev-bigbang-mil-certificate.md
+++ b/blog/dev-bigbang-mil-certificate.md
@@ -4,8 +4,8 @@ tags:
  - blog
 ---
-# BigBang Mil Domain & Certificate
+# Big Bang Mil Domain & Certificate
-In late March 2024 BigBang migrated to a P1 owned and operated domain `bigbang.mil` and updated the DEVELOPMENT ONLY certificate we ship with BigBang which makes the process of doing dev setup and quickstart items easier via using a valid and pre-configured certificate. 
+In late March 2024, Big Bang migrated to a Platform One (P1) owned and operated domain `bigbang.mil` and updated the DEVELOPMENT ONLY certificate we ship with BigBang which makes the process of doing dev setup and quickstart items easier via using a valid and pre-configured certificate. 
-This `*.dev.bigbang.mil` certificate is for our team's internal CI pipelines and Development ONLY. No artifacts, articles, pages or downloads will be available behind this domain. If there is anything pointing to or referencing this domain that is publicly available it is NOT owned or operated by P1. Our method of publishing and hosting releases only on `repo1.dso.mil`, `registry1.dso.mil` and `github.com/DoD-Platform-One` will continue to be our method where you can find our artifacts and releases.
+This `*.dev.bigbang.mil` certificate is for our team's internal Continuous Integration (CI) pipelines and Development ONLY. No artifacts, articles, pages or downloads will be available behind this domain. If there is anything pointing to or referencing this domain that is publicly available it is NOT owned or operated by P1. Our method of publishing and hosting releases only on `repo1.dso.mil`, `registry1.dso.mil` and `github.com/DoD-Platform-One` will continue to be our method where you can find our artifacts and releases.
--- a/docs/FAQ.md
+++ b/docs/FAQ.md
@@ -2,10 +2,10 @@
 ## Costs and licensing Fees
-> Will a user, government program, or support contract incur any costs, other
+> Will a user, Government program, or support contract incur any costs, other
 than their own labor, for installing and using Big Bang?
-Big Bang itself is open-source, and you do not need to pay Platform One
+Big Bang itself is open-source. You do not need to pay Platform One
 to use it in your environment.
 Our baseline includes multiple software components, with a variety
@@ -13,22 +13,22 @@ of open-source and commercial licenses. Details of these components and
 their licensing models can be found in
 [Big Bang Licensing Model Overview.](./understanding-bigbang/licensing-model.md)
-In Big Bang 2.0, our default core components will be open source, though paid
+In Big Bang 2.0, our default core components will be open source; however, paid
 alternatives will remain available.
 You are in complete control over which components you install in your
 environment, and choose whether or not to use commercial software.
-However, your Approving Official may require certain commercial applications for a cATO.
+However, your Approving Official may require certain commercial applications for a continuous Authority to Operate (cATO).
-> Are users required to set up a "contract" with Platform One in order to
+> Are users required to set up a contract with Platform One in order to
 use Big Bang?
 No. Big Bang is open source, and can be used by you and your organization
 without payment to Platform One.
-Platform One does offer optional hosting and support contracts:
+Platform One does offer optional hosting and support contracts. These are listed in the following:
- Our Big Bang Integration Team helps customers install, upgrade, and operate BigBang on customer hardware and in customer environments.
+- Our Big Bang Integration Team helps customers install, upgrade, and operate Big Bang on customer hardware and in customer environments.
 - Our Digital Twin service will deploy an instance of your application to
  our testing clusters, so we can ensure that changes to our baseline won't break your integration tests. Providing you with customized release notes for your environment.
 - [Party Bus](https://p1.dso.mil/products/party-bus) is a managed environment and
@@ -83,7 +83,7 @@ managed Big Bang Platform as a Service (PaaS) solution, or one of the [Big Bang
 ## Change Control
-> How do you manage change control on Big Bang? How can we be notified of changed?
+> How do you manage change control on Big Bang? How can we be notified of changes?
 Big Bang has a two-week release cadence. You can view our
 [release schedule](https://docs-bigbang.dso.mil/latest/#Navigating-our-documentation),

--- a/docs/assets/diagrams/developer/bb-gitlab-ci-diagram.drawio
+++ b/docs/assets/diagrams/developer/bb-gitlab-ci-diagram.drawio
 <mxfile host="Electron" modified="2021-09-13T18:30:18.191Z" agent="5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/12.9.9 Chrome/80.0.3987.163 Electron/8.2.1 Safari/537.36" etag="pn3BY3rUH7aw4UmqKB5J" version="12.9.9" type="device" pages="2"><diagram id="C5RBs43oDa-KdzZeNtuy" name="BB pipelines">7Vxbe5s4EP01/rb7kP0QV/sxtpO26WW7Tdu0jzLINrWMCAhf8pDfvhIXGxBxHMcYoiYPsRkLCebMmRkNQh1tMF+9DaA//UQchDuq4qw62rCjqsBSVPbBJetUAnp6IpkErpPKtoJr9w6lQiWVRq6DwkJDSgimrl8U2sTzkE0LMhgEZFlsNia4OKoPJ0gQXNsQi9Ib16HTRNpVra38HXIn02xkYPaSX+Ywa5zeSTiFDlnmRNpFRxsEhNDk23w1QJhrL9PLzfv1Df44M99e/Rfewu/9D98+/zhLOrt8yimbWwiQRw/u+lZ3Z4vVGvTsO+3D4Ap9+KJdnalaem90nSkMOUx/6SEJ6JRMiAfxxVbaD0jkOYh3q7CjbZuPhPhMCJjwN6J0nRoDjChhoimd4/RXtHLpz9z3X7yrf4z0aLhKe44P1tmBR4P1z/xB7ix+uD0tPsrOS+6P31TJHh5RZmarMJggukODoLcxBUYiROaIjc5ODBCG1F0UR4WpMU827TanfiEuux5VSZnXM1OapbzTMivMughJFNgoPWsLO/uSu4ytKDaGJxhGOtoC4ii9BcFQimawnLoUXfvQ5r8umTMpQj4JoOMyjQ8IJkF8vjaO/9hvYxfjTO4RD21QW6CAotUBuIlwpL3ooKjWbnqfy5xr6JqJbJpzC4L68wgWdP9URVtGIww8kE3Ic865U2aHI0zsWSK6dHHW8RHpVtnOqoVtwFQKZqFq+7GN6QKuc8183iB8eJxNLCmNc7lne6ArJYNLruCo1LdM2WNC3VacWMuOdtq+wUU5hrmf2kozZ3ksK92lwlyA8gMUC4JwR6gCj4eqMfFoaqZA5aELwzBMLSekAZltEkneepMVbpONfc1ECG8Ph60SIEAMWyADIR+29CNErYfdcEH71xR6TuQz4UxzeD6Po5CiQD4ojGIGsdH7KbCodhICFgOMoMdE772QQt5BCQN2q7SoaIjdice+20xbDDStzxXislnUefrD3HWcxNGj0L2Do7grrufUmbB+jX7HGPK+mG8PU9BqTOUsrQhEryKVq4ChtkROFWAYIh8TfsWXOFo1TITj69/oto0IYkjYINB3JyPoTTqqibnlj5hfMif825t3CM9Zg8jnMxT0t3QwWaBtMOkCTN9QyNMJaNuIqYsXiPi1kJAnKcobOwqwfLh09bbhYumCkl/z/hdZLAJlG6m5WJSlo7tSEGUcEO5oHTSGEeYXPwqgZ0873MYFrxwiFFsi8rkLgCOykNA1l1NJTWnaBQAxl/yeBEZJc8iSE1YtEQHzlEkkELPIwRTZMxIVGLN0Kf+wpyynQU1Pd+tPLVtADDG3PPd9vM6DkKQtLNPsv2aaLUHtNdWsSjWbByZzs/Kmms/MJPMV5B2Z5B4pZ+5R9WEp5/MY2BMYOHRDHyf16Ph8lgzENytfGANKySOqjRNPFTP1IcKI8mx70IqKbQ0wAKNtMOi9RvxfS32Z2t3Tl2kPAH0aX5ZdZhsfOdUwOS0+cjIa54zZfeVMmQr7cEZrkjOaWFDwEF2SYBbPhKRjjaa1jjavK/yeS7V9V2skDyQbo5pYotg8g5eRarrVOqpJ/wCldqrp+1LNaJRqYl1plD1glpFqJmgd1ZqZQMlENWNfqpmNUs0QqEbjEq5kFLOM1lFM+mXAtVPM3Jdi3UYpZu6IZszyPenI1u21jmzWSyFb7aTZuxj43LU0zyONWAzczrakJA1QWlfb0MSnS9vqkpwggNbNerOOcyDcA4OrHdmC/uVYNdQtQKBmlemmFg3pYpH13jqLMZi7IgfkwCDjfrbkMXuPMgeCdVIQxJrAPVDiB64yo1BaWWKK3uikL2Ho4nRRcmcEQHmRgSFicFJ3ZIgB4VvgTiYoYCOdiwvjzljba3uK7AizyKwqn/k1xkvr+pGLneoTPn1l/zAcxdtVxIMofyWFAcV2WcPbiG/L0H8C5hiN6ctAvFtMAfSKRavAqEDcqA3xigCkyez3NNMoZmEVnKtCoD7OqSICUsd/Q2kbAuLjNx7/NalRMMtTwgoUThr/jaosTGYErG7beFCRgUkdC3pq2xAQ67n3uswIAKV14VjcH+FelRoCtXXxWCzQCqrPvQ+a7juVQyFpfWChW1TUI3rIZM98E1RITHsl/T7wJqi4I5L6WE9Jgb62d0oNsbZ7zw415cyUu6RigYLeTaUnEOmkKZUlTu7+ACLp5VeqrQOJ1CttLSZ0VDOPLHFm+AfCp5VrH4fCJ3RUN3zitPJ6Tmb8tQP+KqP43oEUTrBbgu+E08rhBN98uh0YVx+d0Lr8OhhHv88qdsNMK5pxQbNiA4NM4riLsij0+cYIuUomYgbEPr+i2ygpYF4sULw/W9KeXXD+lJy4ovM9xptDL4L8jinkCzxQrYPZZD536eZFW3HzhycNu7epv5harloqoFTsRwqqivfmESz9F17cjn9r51H/sxr+MEfo3x/9l2Dp8ltB1V5mmz1dCtvSPt0M2OF2y+okSm13/tYu/gc=</diagram><diagram id="7LAne4oA9n-VVIV32Hwe" name="Package pipeline">7Vtbd5s4EP41Pmf3IT3IXIwfHcdpt2ez2zbppnmUQQbVAhEQdpyH/vaVQFxF4lzqS0nzEjToxnzzSTMjeaBPg7v3MYz8C+oiMhhq7t1APxsMh8AYmfyfkGykRNOlxIuxK2WV4BLfo6KilKbYRUmjIqOUMBw1hQ4NQ+SwhgzGMV03qy0oaY4aQQ8pgksHElV6jV3m51Lb1Cr5B4Q9vxgZaPJNAIvKUpD40KXrmkifDfRpTCnLn4K7KSJCe4VePmtM1+HN0KazK7j+eo1vo+lJ3tn5c5qUnxCjkL246+Gn2/vxhbbZTD7+o4ETG977tmyirSBJpb44DgvspTFkmIb5K+zKQqYFtilUG9M0dJHoHgz007WPGbqMoCPerrk1cZnPAiJfL2jIpHUArrpTj8BEQKvx54TFdFnCI2qXuhav5RxRzNBdC9QtGgElTNzAEQ0Qize8nezFkF8vTVu3pWWvKzsBBfh+zUaKdlCaplf2XKmfP0gEnoEGUFSMXG7Mskhj5lOPhpDMKulpBYJQVVXnb0ojqczviLGN1D1MGW0Cg+4w+1Z7vhFdvTNl6exO9pwVNkUh5J/7rV6otRLFqllW2jSQFB/1Ahy5YmgaO+gxBUoEGYw9xB6rOOq2jBgRbuur5vR+Os5DhXWPcEvbzi0vhi7mGpxSQuOsvb7I/gTvMCGFPKQh2iWfzCahhpamEMoedxBKH+6KUfpBGPVCdqDQnYgdjxfnhDrLXHSOyWuoumvKaU9knPlKwsmmnyjm0y5NDtjjd+Pa32jUsEBDM5s95p8jO6lsi6sdbmrVIlEheXjY0idojXP+xPqFwVemnc+gMvRSRS+3faPvu8lWvhyL7YMH1s23afymtgfjN5Ut9pLB0E0jLlzqrgg4SJowFPfPqx231hpN3YX369ZaChZTgqAILv4KEwZFBy0MuEpYU9E8CvFC/uxw1XDQ9FOhOMzDvIl8EWDXzZcwlOB7OM+6EnqW5sz7NU8H5pnoi69aiQRth0CMRi13aNThDnXgsDNnaKTgUOpfO0MRXztR6GCU9I4SVnv7PTgl7Eeg+ASdpUhq9A2FkXlsKIx/e0i7Dsif7CIdNCAvplnj4wdEAjFxlIjNY8Ifp5uI7y2JGD8UDkTixDgSfs4cJtwg+kZX2z42ugKw3ZHQFjEVuLloAVOSoRPD0PEHYqYWEV7FnPt8liee/kgQykBDUQbrnK7Qn70Dsu0QGvbBgVQTYF8jkcRSN71+eIItKpWJshoC1j49QaCrTPKRs6RpgzFrzMQ/x4eh9wbcwiMghqHgMokisqmDoHGHQny6dBL5ShcRugmQDOr7BFDbYzwCgNS8wm9Hob26HR4lS1Fyzxz7wa79dpkr2O632922sSe/XU1pnOEkInk+M2vPmZh9bP+2L6C1A+rDE0/Na5whgpjYp6Y9zbcC0E64Hh6GsQLDVYw9T7jLk85IqJC4eNUWJZGIsHLZCW98geLM7/iCblO+5/Gn2QplBwZ5fT7jepOauKPzJ4wXwDCFJFuLPLHm7XQwhwYBZqWXpUaRzxr2ybEMQQv2S0Qyw/YRf0ckA7pCGWtXtl4Qq2brZQJVu8qcsl7GlLZhNZHQVSS67lr8jJjyv5MEXZ7rHwMIlth2Aw0sFx1XyX7wIhAMxurdsV5g0DrgMTog2FVY3wmBmh/rPQRm+2hnj6mVTgzU1JbAQBPy/qJgGeZWFEb7REHNb2VMENcC+ovCaHRkKKjJkt6vR2NwZOuRevlCYKCLywD9RcFsoWB27Mx7ZYKap3hzTOjCYK9MUHMT2c7cZwws88gwUBMTb3Bf3udqNI7xzfeLxfr9l9VlcuX4YzSddIVq4mBDS5DTTwQAaJ8kGfsjwnxoUBsEq9nUvf53PZ1MPofpA9GykR2N95cJVitiLk9g98CEThjUiFlRfO0Olfz9TA2DvPYLz2FUNdXUYHaooZC98t54K19tgZZ2H7gnrt4/1/UtPeXHR0pPL7jk3YmeGmsfXZr7ySz+ZVPARse1ZmB0WK/+fBLzYvX72txqqp8p67P/AQ==</diagram></mxfile>
\ No newline at end of file