Minor changes and fixed typos (#124)

Co-authored-by: Sergey Shurlakov <sergey@typeable.io>

docs/en/Control_scripts.md

@@ -11,7 +11,7 @@ Control scripts can be roughly split into two categories: (1) control scripts in
 
 _stdout_ and _stderr_ output from the most important scripts involved in the deployment lifecycle will be collected and stored. DevOps engineers can then view these logs from the _octo CLI_, should that be needed.
 
-All of the _scripts_ in this category receive the exact same exact same set of command line arguments.
+All of the _scripts_ in this category receive the exact same set of command line arguments.
 
 There are four "static" arguments that are passed to all *scripts* in this category. The first three arguments come from the [_Kubernetes ConfigMap_][configmap]:
 * `--project-name` – the name of the project. It is supplied mostly for informational purposes and can be useful for sending notifications if that is necessary.

docs/en/Helm-based_deployment_guide.md

@@ -49,7 +49,7 @@ So here you have it, your first Octopod deployment!
 
 ## Going further
 
-As we can said earlier you can override all default parameters using Octopod UI. Let's dive right in!
+As we said earlier you can override all default parameters using Octopod UI. Let's dive right in!
 
 First, let's archive our wordpress deployment:
 
@@ -85,6 +85,6 @@ As in the previous example Octopod parsed the _App Overrides_ from the [chart va
 
 `chart_repo_url`, `chart_name` parameters are usually provided by the chart developer. Version however is usually skipped and you encouraged to take the last one, but we think about this as a bad practice.
 
-If you not sure where to get the `chart_version` parameter you can add repo locally using `helm repo add` and then execute `helm search repo <CHART_NAME> -l` too see the whole list of available chart versions.
+If you're not sure where to get the `chart_version` parameter you can add repo locally using `helm repo add` and then execute `helm search repo <CHART_NAME> -l` too see the whole list of available chart versions.
 
 Now you have Octopod inside Octopod! Try to install your own chart with Octopod!

docs/en/Integration.md

@@ -21,7 +21,7 @@ octo create -n $NAME -t $IMAGE_TAG
 
 ## 🚀 Updating deployments
 
-Updating deployments is done using the same arguments, but you need to call `create` command, instead of the `update` command:
+Updating deployments is done using the same arguments, but you need to call the `create` command, instead of the `update` command:
 
 ```bash
 octo update -n $NAME -t $IMAGE_TAG

docs/en/Octopod_deployment_guide.md

@@ -1,10 +1,10 @@
 # Octopod Server deployment guide
 
 ## Installation options
-There are several options to install octopod depending on your needs.
+There are several options to install Octopod depending on your needs.
 
-### If you have a kubernetes cluster
-You can install octopod in any kubernetes cluster using our [Helm chart](../../charts/octopod).
+### If you have a Kubernetes cluster
+You can install Octopod in any Kubernetes cluster using our [Helm chart](../../charts/octopod).
 
 
 Your cluster must satisfy following requirements:

docs/en/Overview.md

@@ -8,7 +8,7 @@ _Octopod_ is a tool which implements the multi-staging deployment model (MSDM) o
 
 _Octopod_ exists to reduce the overhead in deploying and maintaining per-feature staging environments. This responsibility may otherwise fall to:
 
-1. **DevOps engineers** – this might seem natural since deploying and updating systems in new environments is typically the task of a DevOps engineer who has experience in system administration. However, developers and QA engineers would be blocked for additional periods while DevOps engineers deal with the additional load.
+1. **DevOps engineers** – this might seem natural since deploying and updating systems in new environments is typically the task of a DevOps engineer who has experience in system administration. However, developers and QA engineers would be blocked for extended periods while DevOps engineers deal with the additional load.
 2. **Developers** – they might take on the responsibility for deploying and maintaining their feature stagings ― this would most likely waste a lot of time since developers might not have the required experience.
 
 The process of deploying and updating stagings is likely to be extremely similar across different developed features ― changing the behavior of a button and updating pricing calculations would probably be identical from the point of view of system administration ― a new version of the system needs to be deployed with the same default configuration (the staging configuration, as opposed to a production configuration).

docs/en/PM_case_study.md

@@ -56,7 +56,7 @@ guarantee that the feature won’t unexpectedly break someone else’s code.
 If a critical part of the application, like authentication, gets broken,
 this may block the testing process completely until the problem is
 resolved. And to top it off, when this happens, it might not be
-immediately clear who’s change is to blame. Thus, everyone who did
+immediately clear whose change is to blame. Thus, everyone who did
 recent merges begin looking into their code trying to see whether it was
 their check-in that broke the server. Of course, it takes time and
 blocks the development process as well until the culprit merge is found

docs/en/README.md

@@ -7,7 +7,7 @@
 
 ## 🛠️ Technical documentation
 - [🏗 Technical architecture](Technical_architecture.md)
-- [⚙️ Control script guide](Control_scripts.md)
+- [⚙️ Control scripts guide](Control_scripts.md)
 - [🔧🐙 Octopod deployment guide](Octopod_deployment_guide.md)
 - [🔧🚀 Helm-based Octopod project setup](Helm-based_deployment_guide.md)
 - [🐙🎛 octo CLI user guide](Octo_user_guide.md)

docs/en/Security_model.md

@@ -22,7 +22,7 @@ There is currently no way to give someone access to _octo CLI_ without giving th
 _Octopod Server_ is deployed in the `octopod` _Kubernetes_ namespace. Deployments are deployed in the `deployments` namespace.
 _Octopod Server_ uses the `octopod` [_Service Account_][kubernetes-service-account].
 
-Octopod needs sufficient permissions to run helm inside kubernetes and create all resources described in helm chart it is installing. Thus permissions are quite extensive.
+Octopod needs sufficient permissions to run Helm inside Kubernetes and create all resources described in the Helm chart it is installing. Thus permissions are quite extensive.
 
 [RBAC][kubernetes-rbac] rules to describe permissions needed are added automatically by [the Octopod Helm Chart](../../charts/octopod/templates/rbac.yaml).
 
@@ -36,7 +36,7 @@ The [_Web UI_](Technical_architecture.md#-web-ui) on its own does not have any a
 
 ## octo CLI authentication
 
-Authentication between _octo CLI_ and _Octopod Server_ is done through special token which is generated automatically or specified by user in `octopod.cliAuthSecret` parameter, as described [here](../../charts/octopod/README.md#parameters)
+Authentication between _octo CLI_ and _Octopod Server_ is done through special token which is generated automatically or specified by user in `octopod.cliAuthSecret` parameter, as described [here](../../charts/octopod/README.md#parameters).
 
 [kubernetes-service-account]: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account
 [kubernetes-ingress-nginx-external-auth]: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#external-authentication

docs/en/Tech_case_study.md

@@ -22,7 +22,7 @@ It is sometimes the case that certain features need a "special" environment to b
 
 "Current" is used here to denote features that have been completed after the last time QA engineers had the opportunity to test the staging of the given project. It is assumed that the completed features are merged into something analogous to a `master` branch in git.
 
-A way to mitigate the issue might be to have fine-grained control over what features are allowed to be merged into the `master` branch so that when we deploy it, we will have only the one feature which needs the "special" environment, in a sense, batching features based on the environment they require. The main problem with this is that the payment processor is in all likelihood a tiny sliver, a single dimension of the whole space of possible environment setups. Trying to capture and institutionalize the whole breadth of a production environment in your development workflow seems like a futile endeavor.
+A way to mitigate the issue might be to have fine-grained control over what features are allowed to be merged into the `master` branch so that when we deploy it, we will have only the feature which needs the "special" environment, in a sense, batching features based on the environment they require. The main problem with this is that the payment processor is in all likelihood a tiny sliver, a single dimension of the whole space of possible environment setups. Trying to capture and institutionalize the whole breadth of a production environment in your development workflow seems like a futile endeavor.
 
 Having per-feature stagings allow you to have completely separate and independent configurations for every single feature you develop and test at no additional cost.
 

docs/en/Technical_architecture.md

@@ -51,7 +51,7 @@ This is necessary to make _Octopod_ itself independent from any particular deplo
 
 When the [_Octopod Server_](#-octopod-server) _Pod_ starts, the contents of the *control scripts* container are copied into the _Octopod Server_ container file system. This means that the executables need to be either statically linked or interpreted through _Bash_ since it needs to be executed in the _Octopod Server_ container environment.
 
-These [scripts need to be implemented](Control_scripts.md) to deploy _Octopod_.
+These [scripts need to be implemented](Control_scripts.md) to deploy _Octopod_ unless the set of generic scripts is used.
 
 
 ### Kube API Server