diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 82a579b4a1cb82319adc34725c5b4c4c639ec0c2..37fa72fa76e2cdee17f69ac9a7db7339dbe724e7 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -55,12 +55,12 @@ Configure `myvalues.yaml` to suit your needs. # Be aware, the internet version is likely newer than the Iron Bank version ./hack/flux-install.sh -# Apply a local version of the umbrella chart +# Apply a local version of the Big Bang chart # NOTE: This is the alternative to deploying a HelmRelease and having flux manage it, we use a local copy to avoid having to commit every change helm upgrade -i bigbang chart -n bigbang --create-namespace -f myvalues.yaml -# A convenience development script is provided to force fluxv2 to reconcile all helmreleases within the cluster insteading of waiting for the next polling interval. -hack/sync.sh +# It may take Big Bang up to 10 minutes to recognize your changes and start to deploy them. This is based on the flux `interval` value set for polling. You can force Big Bang to immediately check for changes by running the ./hack/sync.sh script. +./hack/sync.sh ``` For more extensive development, use the [Development Guide](docs/c_development.md). @@ -73,7 +73,7 @@ Follow the [Big Bang documentation](./docs) for testing a full deployment of Big ## DNS -To ease with local development, the TLD `bigbang.dev` has been purchased with the following CNAME record: +To ease with local development, the TLD `bigbang.dev` is maintained by the Big Bang team with the CNAME record: `CNAME: *.bigbang.dev -> 127.0.0.1` diff --git a/charter/GitOpsEngine.md b/charter/GitOpsEngine.md index 14e82810561e89fa6435df516dad48e6d66c0158..cc6d135b6e7098b3f5c2ae530ead8f40e509e5ee 100644 --- a/charter/GitOpsEngine.md +++ b/charter/GitOpsEngine.md @@ -6,7 +6,7 @@ Big Bang will be deployed and managed with [Flux 2](https://github.com/fluxcd/fl ### Big Bang and Flux -Big Bang is composed of several Open Source and licensed products. [Helm](https://helm.sh/), as a member of the [CNCF](https://www.cncf.io/), is the de facto standard for packaging applications for Kubernetes. As a result, several vendors support the release of their product **as helm charts** and have built their packaging and lifecycle management to expect to be the engine for driving that management. As a result, Big Bang has adopted Helm as its internal deployment framework for BigBang packages and requires Helm to be treated as a first class citizen. +Big Bang is composed of several Open Source and licensed products. [Helm](https://helm.sh/), as a member of the [CNCF](https://www.cncf.io/), is the de facto standard for packaging applications for Kubernetes. As a result, several vendors support the release of their product **as helm charts** and have built their packaging and lifecycle management to expect to be the engine for driving that management. As a result, Big Bang has adopted Helm as its internal deployment framework for Big Bang packages and requires Helm to be treated as a first class citizen. The Flux2 Engine has native Helm support, meaning the controller deployed as part of "Flux 2" leverages the same Helm code as the CLI. diff --git a/charter/GitlabLabels.md b/charter/GitlabLabels.md index 65da64c5e4b734844bb46df15fc2322f41f3d86e..74c2f4ab9384fa978fb5c0973fdea8a6b4651230 100644 --- a/charter/GitlabLabels.md +++ b/charter/GitlabLabels.md @@ -13,11 +13,11 @@ The kind label shows the type of work that needs to be accomplished #### `kind::bug` -Issues related to Bigbang not functioning as expected +Issues related to Big Bang not functioning as expected #### `kind::chore` -Catch all kind that captures administrative tasking for the BigBang project +Catch all kind that captures administrative tasking for the Big Bang project #### `kind:ci` @@ -29,7 +29,7 @@ Issues related to documentation #### `kind::feature` -Creation of a new capability for BigBang and/or one of its packages +Creation of a new capability for Big Bang and/or one of its packages #### `kind::enhancement` diff --git a/docs/configuration.md b/docs/configuration.md index 4abcf551ce7a5c1c54daa826e64cc99a625e711b..70635cf468ab37ccde9f8f57bdd0d0f53f6c62b9 100644 --- a/docs/configuration.md +++ b/docs/configuration.md @@ -80,7 +80,7 @@ Registry credentials are used to pull images for Big Bang. By default, it point ### `flux` -Flux settings are used to setup the default continuos deployment configuration for Big Bang packages. +Flux settings are used to setup the default continuous deployment configuration for Big Bang packages. | Key | Description | Type | Default | |--|--|--|--| diff --git a/docs/developer/ci-workflow.md b/docs/developer/ci-workflow.md index 62e70f2f242ee7c37cd84def1e6116ca37115859..748dc81905a46c9e62d9c85aaf04d1993bf626ab 100644 --- a/docs/developer/ci-workflow.md +++ b/docs/developer/ci-workflow.md @@ -111,7 +111,7 @@ More information on the full set of infrastructure tests are below: For each cloud, a BigBang owned network will be created that conform with the appropriate set of tests about to be ran. For example, to validate that Big Bang deploys in a connected environment on AWS, a VPC, subnets, route tables, etc... are created, and the outputs are made available through terraform's remote `data` source. -At this time the infrastructue testing pipeline is only utilizing internet-connect AWS govcloud. +At this time the infrastructure testing pipeline is only utilizing internet-connect AWS govcloud. #### Cluster Creation @@ -119,7 +119,7 @@ The infrastructure pipeline is currently setup to standup an `rke2` cluster by d An `rke2` cluster is created that leverages the upstream [terraform modules](https://repo1.dso.mil/platform-one/distros/rancher-federal/rke2/rke2-aws-terraform) -It is a hard requriement at this stage that every cluster outputs an admin scoped `kubeconfig` as a gitlab ci artifact. This artifact will be leveraged in the following stages for interacting with the created cluster. +It is a hard requirement at this stage that every cluster outputs an admin scoped `kubeconfig` as a gitlab ci artifact. This artifact will be leveraged in the following stages for interacting with the created cluster. #### Big Bang Installation diff --git a/docs/developer/develop-package.md b/docs/developer/develop-package.md index 2f9f3c37ba5386d8d9cd4ffb954c17d260480aa1..eabe79aa432545a3ae6fcb7f91e7bcc0bd389811 100644 --- a/docs/developer/develop-package.md +++ b/docs/developer/develop-package.md @@ -60,7 +60,7 @@ Package is the term we use for an application that has been prepared to be deplo 1. Add a VirtualService if your application has a back-end API or a front-end GUI. Create the VirtualService in the sub-directory "chart/templates/bigbang/VirtualService.yaml". You will need to manually create the "bigbang" directory. It is convenient to copy VirtualService code from one of the other Packages and then modify it. You should be able to load the application in your browser if all the configuration is correct. -1. Add NetworkPolices templates in the sub-directory "chart/templates/bigbang/networkpolicies/*.yaml". The intent is to lock down all ingress and egress traffic except for what is required for the application to function properly. Start with a deny-all policy and then add additionl policies to open traffic as needed. Refer to the other Packages code for examples. The [Gitlab package](https://repo1.dso.mil/platform-one/big-bang/apps/developer-tools/gitlab/-/tree/main/chart/templates/bigbang/networkpolicies) is a good/complete example. +1. Add NetworkPolices templates in the sub-directory "chart/templates/bigbang/networkpolicies/*.yaml". The intent is to lock down all ingress and egress traffic except for what is required for the application to function properly. Start with a deny-all policy and then add additional policies to open traffic as needed. Refer to the other Packages code for examples. The [Gitlab package](https://repo1.dso.mil/platform-one/big-bang/apps/developer-tools/gitlab/-/tree/main/chart/templates/bigbang/networkpolicies) is a good/complete example. 1. Add a continuous integration (CI) pipeline to the Package. A Package should be able to be deployed by itself, independently from the BigBang chart. The Package pipeline takes advantage of this to run a Package pipeline test. The package testing is done with a helm test library. Reference the [pipeline documentation](https://repo1.dso.mil/platform-one/big-bang/pipeline-templates/pipeline-templates#using-the-infrastructure-in-your-package-ci-gitlab-pipeline) for how to create a pipeline and also [detailed instructions](https://repo1.dso.mil/platform-one/big-bang/apps/library-charts/gluon/-/blob/master/docs/bb-tests.md) in the gluon library. Instructions are not repeated here.