Merge pull request #6098 from werf/doc-v2-update-documentation-for-v2.0

doc(v2): update documentation for v2

docs/_data/breadcrumbs.yml

@@ -31,7 +31,7 @@ en:
     url: /reference/cli/overview.html
   /resources: &documentation-resources
     title: Resources
-    url: /resources/migration_from_v1_2_to_v2_0.md
+    url: /resources/migration_from_v1_2_to_v2_0.html
 ru:
   /documentation:
     <<: *documentation

docs/pages_en/resources/comparison.md

@@ -15,7 +15,7 @@ GitOps mandates separation of development and operation, while giterminism allow
 
 Helm is used only for chart deployment and distribution, while werf can also be used for developing, building, testing, distributing images and bundles, and cleaning up the container registry. 
 
-Helm is built into werf and is enhanced with additional features such as advanced tracking, customizing the deployment order not only for hooks but also for regular resources, and more.
+For chart deployment and distribution we use Nelm: backward-compatible Helm alternative, which provides many new features and improvements, such as as advanced resource tracking, flexible ordering of resources during deployment, Server-Side Apply instead of 3-Way Merge, `terraform plan`-like capabilities and much more.
 
 ## werf vs Argo CD
 

docs/pages_en/usage/deploy/deployment_order.md

@@ -46,46 +46,7 @@ In this case, the CRD for the CronTab resource will be deployed first, followed
 
 ## Changing the order in which resources are deployed (werf only)
 
-By default, werf combines all the main resources ("main" means those are not hooks or CRDs from `crds/*.yaml`) into one group, creates resources for that group, and then tracks their readiness.
-
-The resources for the group are created in the following order:
-
-- Namespace;
-- NetworkPolicy;
-- ResourceQuota;
-- LimitRange;
-- PodSecurityPolicy;
-- PodDisruptionBudget;
-- ServiceAccount;
-- Secret;
-- SecretList;
-- ConfigMap;
-- StorageClass;
-- PersistentVolume;
-- PersistentVolumeClaim;
-- CustomResourceDefinition;
-- ClusterRole;
-- ClusterRoleList;
-- ClusterRoleBinding;
-- ClusterRoleBindingList;
-- Role;
-- RoleList;
-- RoleBinding;
-- RoleBindingList;
-- Service;
-- DaemonSet;
-- Pod;
-- ReplicationController;
-- ReplicaSet;
-- Deployment;
-- HorizontalPodAutoscaler;
-- StatefulSet;
-- Job;
-- CronJob;
-- Ingress;
-- APIService.
-
-Readiness tracking is enabled for all resources in the group simultaneously as soon as *all* resources in the group are created.
+By default, werf combines all the main resources ("main" means those are not hooks or CRDs from `crds/*.yaml`) into one group, creates resources for that group and tracks their readiness.
 
 To change the order in which resources are deployed, you can create *new resource groups* by assigning resources a *weight* other than the default `0`. All resources with the same weight are combined into their respective groups, and then the resource groups are deployed sequentially starting with the group with the lesser weight and progressing to the greater weight, for example:
 
@@ -264,5 +225,3 @@ metadata:
     secret.external-dependency.werf.io/resource: secret/my-dynamic-vault-secret
     secret.external-dependency.werf.io/namespace: my-namespace 
 ```
-
-*Note that all other release resources with the same weight will also be waiting for the external resource to be ready, since resources are grouped by weight and deployed as groups.*

docs/pages_en/usage/deploy/deployment_scenarios.md

@@ -159,7 +159,7 @@ You can separate the first and second steps as follows:
 werf build --repo example.org/mycompany/myapp
 ```
 
-```
+```shell
 werf render --require-built-images --output manifests.yaml --repo example.org/mycompany/myapp
 ```
 
@@ -231,7 +231,7 @@ You can explicitly specify the release name and Namespace if there is no access
 werf dismiss --release myapp-staging --namespace myapp-staging
 ```
 
-... or you can use a previous deployment report which contains the release name and Namespace. You can enable saving this report by using the `-save-deploy-report` flag of the `werf converge` or `werf bundle apply` commands.
+... or you can use a previous deployment report which contains the release name and Namespace. You can enable saving this report by using the `--save-deploy-report` flag of the `werf converge` or `werf bundle apply` commands.
 
 ```shell
 werf converge --save-deploy-report

docs/pages_en/usage/deploy/overview.md

@@ -5,17 +5,19 @@ permalink: usage/deploy/overview.html
 
 When setting up application delivery in Kubernetes, you must decide which format to use for managing the deployment configuration (parameterization, dependency management, configuration for different environments, etc.), as well as how to apply this configuration (the deployment mechanism).
 
-Helm is built into werf and is used for these tasks. Configuration development and maintenance is carried out using Helm charts. As for the deployment process, Helm in werf provides some advanced features:
+Nelm, the backward-compatible Helm alternative, is built into werf and is used for these tasks. Configuration development and maintenance is carried out using Helm charts. As for the deployment process, Nelm in werf provides some advanced features:
 
 - tracking the status of deployed resources (with the option to change the behaviour [for each resource]({{ "/reference/deploy_annotations.html" | true_relative_url }})):
   - smart waiting for resources to become ready;
   - instant termination of a failed deployment without the need to wait for a timeout;
   - deployment progress, logs, system events and application errors.
 - arbitrary deployment order for any resources, not just hooks;
 - waiting for resources that are not part of the release to be created and ready;
+- using much more robust Server-Side Apply for resource updates instead of 3-Way Merge;
+- `terraform plan`-like capabilities out of the box;
 - integrating building and deployment, and much more.
 
-werf strives to make working with Helm easier, more convenient and flexible without breaking backward compatibility with Helm charts, Helm templates, and Helm releases.
+werf strives to make working with Helm deployments easier, more convenient and flexible without breaking backward compatibility with Helm charts, Helm templates, and Helm releases.
 
 ## Basic deployment example
 

docs/pages_en/usage/deploy/releases.md

@@ -58,30 +58,6 @@ A release name generated using a special pattern or specified by the `--release`
 
 You can manually format any string to match the RFC 1123 Label Names format using the `werf slugify -f helm-release` command.
 
-## Adding resources that already exist in the cluster to the release
-
-werf does not allow a new release resource to be deployed on top of an existing resource in the cluster if the resource in the cluster *isn't part of the current release*. This behavior prevents accidental updates to resources belonging to another release or deployed without werf. Trying to do so will result in the following error:
-
-```
-Error: helm upgrade have failed: UPGRADE FAILED: rendered manifests contain a resource that already exists...
-```
-
-To add a cluster resource to the current release and allow it to be updated, add the `meta.helm.sh/release-name: <name of the current release>`, `meta.helm.sh/release-namespace: <Namespace of the current release>` annotations and the `app.kubernetes.io/managed-by: Helm` label to that cluster resource, for example:
-
-```shell
-kubectl annotate deploy/myapp meta.helm.sh/release-name=myapp-production
-kubectl annotate deploy/myapp meta.helm.sh/release-namespace=myapp-production
-kubectl label deploy/myapp app.kubernetes.io/managed-by=Helm
-```
-
-... and then restart the deployment:
-
-```shell
-werf converge
-```
-
-Running the above commands will result in the `myapp` release resource successfully updating the `myapp` resource in the cluster. On top of that, the cluster resource will become part of the current release.
-
 ## Auto-annotating the release resources being deployed
 
 During deployment, werf automatically adds the following annotations to all chart resources: