update

content/for-delivery-engineers/gitops/environments.md

@@ -16,19 +16,13 @@ A dedicated namespace in cluster for developer in the cluster for every member o
 
 There are three CI/CD environments per tenant
 
-The CI/CD Environments are special Environments that are part of CI/CD workflow. There are 3 kind of CI/CD environments
+The CI/CD Environments are special Environments that are part of CI/CD workflow. There are 3 kinds of CI/CD environments:
 
-#### 1. Build
+1. Build - Build environment contains all Tekton pipeline configurations/resources like *pipeline,eventlistener,pipelinrun etc*. These pipelines respond to changes in Application/Service source repositories. This environment is used for running pipelines of tenant applications.
 
-Build environment contains all Tekton pipeline configurations/resources like *pipeline,eventlistener,pipelinrun etc*. These pipelines respond to changes in Application/Service source repositories. This environment is used for running pipelines of tenant applications.
+1. Preview - Preview environment contains all preview application deployments. As soon as there is a new PR in application, pipeline creates new environment to test this PR. Each PR is deployed in separate namespace.
 
-#### 2. Preview
-
-Preview environment contains all preview application deployments. As soon as there is a new PR in application, pipeline creates new environment to test this PR. Each PR is deployed in separate namespace.
-
-#### 3. Development
-
-Once the PR is merged; the dynamic test environment is automatically deleted and the Helm manifests are pushed to first permanent application environment i.e. `dev` by the CI pipeline.
+1. Development - Once the PR is merged; the dynamic test environment is automatically deleted and the Helm manifests are pushed to first permanent application environment i.e. `dev` by the CI pipeline.
 
 ### 3. Other Environments
 

content/for-developers/cloud-native-app.md

@@ -157,7 +157,7 @@ The application developer best understands the application dependencies, and it
 
 The build stage is where a code repository is converted into a versioned, binary artifact. It is during this stage that the dependencies declared during the design phase are fetched and bundled into the build artifact (often just simply called a “build”). In the Java world, a build might be a WAR1 or a JAR file, or it could be a ZIP file or a binary executable for other languages and frameworks.
 
-Builds are ideally created by a Continuous Integration server, and there is a 1:many relationship between builds and deployments. A single build should be able to be released or deployed to any number of environments, and each of those unmodified builds should work as expected. The immutability of this artifact and adherence to the other factors (especially environment parity) give you confidence that your app will work in production if it worked in QA.
+Builds are ideally created by a Continuous Integration server, and there is a `1:many` relationship between builds and deployments. A single build should be able to be released or deployed to any number of environments, and each of those unmodified builds should work as expected. The immutability of this artifact and adherence to the other factors (especially environment parity) give you confidence that your app will work in production if it worked in QA.
 
 If you ever find yourself troubleshooting "works on my machine" problems, that is a clear sign that the four stages of this process are likely not as separate as they should be. Forcing your team to use a CI server may often seem like a lot of upfront work, but once running, you’ll see that the “one build, many deploys” pattern works.
 
@@ -167,7 +167,7 @@ Once you have confidence that your codebase will work anywhere it should, and yo
 
 In the cloud-native world, the release is typically done by pushing to your cloud environment. The output of the build stage is combined with environment- and app-specific configuration information to produce another immutable artifact, a release.
 
-Releases need to be unique, and every release should ideally be tagged with some kind of unique ID, such as a timestamp or an auto-incremented number. Thinking back to the 1:many relationship between builds and releases, it makes sense that releases should not be tagged with the build ID.
+Releases need to be unique, and every release should ideally be tagged with some kind of unique ID, such as a timestamp or an auto-incremented number. Thinking back to the `1:many` relationship between builds and releases, it makes sense that releases should not be tagged with the build ID.
 
 Let’s say that your CI system has just built your application and labeled that artifact build-1234. The CI system might then release that application to the dev, staging, and production environments. The scheme is up to you, but each of those releases should be unique because each one combined the original build with environment specific configuration settings.
 

content/for-developers/helm.md

@@ -56,7 +56,7 @@ Helm is a package manager that also happens to include templating capabilities.
 
 Technically Helm can be used as only a templating engine by stopping the deployment process in the manifest level. It is perfectly possible to use Helm only to create plain Kubernetes manifests and then install them on the cluster using the standard methods (such as kubectl). But then you miss all the advantages of Helm (especially the application registry aspect).
 
-At the time of writing Helm is the only package manager for Kubernetes, so if you want a way to group your manifests and a registry of your running applications, there are no off-the-shelf alternative apart from Helm.
+At the time of writing Helm is the only package manager for Kubernetes, so if you want a way to group your manifests and a registry of your running applications, there are no off-the-shelf alternatives apart from Helm.
 
 Here is a table that highlights the comparison:
 

content/for-developers/onboarding/gitops-onboarding.md

@@ -19,7 +19,7 @@ To make things easier, we have created a [template](https://github.com/stakater/
 1. Now let's copy the structure that we saw in the [template](https://github.com/stakater/infra-gitops-config.git). Add a folder bearing your cluster's name at the root of the repository that you just created. If you plan on using this repository for multiple clusters, add a folder for each cluster.
 1. Inside the folder created in step 2, add two folders; one named `argocd-apps`, and another one named `tenant-operator-config`
     > The `argocd-apps` folder will contain ArgoCD applications that will _watch_ different resources added to the same repository. Let's spare ourselves from the details for now.
-1. Open the tenant-operator-config folder and add two folder inside it: quotas, tenants
+1. Open the `tenant-operator-config` folder and add two folders inside it: `quotas` and `tenants`
 1. The tenants folder will contain the tenant you want to add to your cluster. Let's create one called `gabbar` by adding the file below:
 
     ```yaml