From 4a498a0d488cfa92d5431320b15d6311b0be7cd8 Mon Sep 17 00:00:00 2001 From: Alexey Igrychev Date: Fri, 16 Dec 2022 12:34:03 +0000 Subject: [PATCH 1/7] docs(ci/cd): move workflows from ci/cd basics Signed-off-by: Alexey Igrychev --- docs/_data/sidebars/_documentation.yml | 6 + docs/_data/sidebars/documentation.yml | 6 + .../ci_cd_workflow_basics.md | 235 ----------------- .../ci_cd_workflows.md | 239 ++++++++++++++++++ .../ci_cd_workflow_basics.md | 233 ----------------- .../ci_cd_workflows.md | 239 ++++++++++++++++++ 6 files changed, 490 insertions(+), 468 deletions(-) create mode 100644 docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md create mode 100644 docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md diff --git a/docs/_data/sidebars/_documentation.yml b/docs/_data/sidebars/_documentation.yml index d7594281cd..f6ea294ab1 100644 --- a/docs/_data/sidebars/_documentation.yml +++ b/docs/_data/sidebars/_documentation.yml @@ -114,6 +114,9 @@ entries: - title: CI/CD workflow basics url: /usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html + - title: CI/CD workflows + url: /usage/integration_with_ci_cd_systems/ci_cd_workflows.html + - title: How CI/CD integration works f: - title: General overview @@ -302,6 +305,9 @@ entries: - title: Основы организации CI/CD url: /usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html + - title: Рабочие процессы CI/CD + url: /usage/integration_with_ci_cd_systems/ci_cd_workflows.html + - title: Как работает интеграция с CI/CD f: - title: Общие сведения diff --git a/docs/_data/sidebars/documentation.yml b/docs/_data/sidebars/documentation.yml index f06071d7e2..40b3b5ed7a 100644 --- a/docs/_data/sidebars/documentation.yml +++ b/docs/_data/sidebars/documentation.yml @@ -744,6 +744,9 @@ entries: - title: CI/CD workflow basics url: /usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html + - title: CI/CD workflows + url: /usage/integration_with_ci_cd_systems/ci_cd_workflows.html + - title: How CI/CD integration works f: - title: General overview @@ -932,6 +935,9 @@ entries: - title: Основы организации CI/CD url: /usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html + - title: Рабочие процессы CI/CD + url: /usage/integration_with_ci_cd_systems/ci_cd_workflows.html + - title: Как работает интеграция с CI/CD f: - title: Общие сведения diff --git a/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md b/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md index 9f4772408f..ba0ee74c86 100644 --- a/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md +++ b/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md @@ -92,238 +92,3 @@ We recommend you to read the guide for your specific CI/CD system: - The [GitHub Actions]({{ "how_to/integration_with_ci_cd_systems/github_actions/workflows.html" | true_relative_url }}) guide. If you want to learn more about how to create a workflow, or no instructions exist for your particular CI/CD system, then you can read the following sections where the [workflow components](#workflow-components-for-various-environments) and [ready-made workflow configurations](#ready-made-workflow-configurations) are defined. After reading them, you will be able to choose a ready-made configuration (or create your own) and implement it for your CI/CD system using werf. - -## Workflow components for various environments - -Next, we will discuss various options for rolling out to production and other environments in conjunction with the git. Each section describes a building block that you can use to work with a specific environment. We will call such a block a "workflow block". You can build your own workflow using workflow blocks or make use of a ready-made configuration (see [Ready-made workflow configurations](#ready-made-workflow-configurations) below). - -Review environments are created and deleted dynamically as per the developers' request. Thus, there are some specificities when deploying code to these environments. In the review-related sections, we will describe how to create as well as delete a review environment. - -### Automatically deploy to production from master - -A merge request or a commit to the master branch triggers the pipeline to deploy directly to production. - -The state of the branch reflects the state of the environment at any given time. Therefore, this option complies with the true CI/CD approach. - -Rollback options: - - Recommended: rollback via reverting the commit in the master branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. - - By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). - -### Deploy to production from master at the click of a button - -You can manually run a pipeline to deploy to production for a commit in the master branch only. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. - -Rollback options: - - Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). - - By reverting a commit in the master branch and then [manually](#run-a-pipeline-manually) run the pipeline using the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the master is not consistent with the state of the environment at all times (as opposed to the automatic deployment). Thus, it does not make sense to revert exclusively for the rollback. - -### Automatically deploy to production using a tag - -Creating a new tag automatically triggers the pipeline to deploy the code to the production environment on the basis of the commit associated with this tag. - -Rollback options: - - Recommended: by means of CI/CD system; [re-run the pipeline manually](#run-a-pipeline-manually) using the old tag. - - By creating a new tag linked to the old commit; the pipeline will be run automatically for the new tag. It is not the best option since it leads to the generation of unnecessary tags. - -### Deploy to production using a tag at the click of a button - -The pipeline to deploy to the production environment can only be triggered using the existing tag in git. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. - -Rollback options: -- By means of the CI/CD system; [re-run the pipeline manually](#run-a-pipeline-manually) using the old tag. - -### Automatically deploy to production from a branch - -A merge request or a commit to the specific branch triggers the pipeline to deploy to production (this option is similar to the (master-automatically) (#master-automatically), but involves a separate branch). - -The state of the specific branch is consistent with the state of the environment at any given time. Therefore, this option complies with the true CI/CD approach. - -Rollback options: -- Recommended: rollback via reverting the commit in the branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. - - By means of the CI/CD system; the user can [manually run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "undo" button performs precisely these steps). - - By reverting the commit in the master, then fast-forwarding merge to the specific branch. - - By deleting the commit in the specific branch (delete the commit in git and then use the git push-force procedure). - -### Deploy to production from a branch at the click of a button - -Manually run a pipeline to deploy to production for a commit to the specific branch only. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. - -Rollback options: - - Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). - - By reverting the commit in the specific branch and then [manually](#run-a-pipeline-manually) run the pipeline using the means of the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the master is not consistent with the state of the environment at all times (as opposed to the automatic deployment). Thus, it does not make sense to revert exclusively for the rollback. - -### Deploy to production-like using a pull request at the click of a button - -The pipeline to deploy to production can be run on any commit to the pull request. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. - -Rollback options: - - By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). - -### Automatically deploy to staging from master - -A merge request or a commit to the master branch triggers the pipeline to deploy directly to the staging environment. - -The state of the branch reflects the state of the environment at any given time. Therefore, this option complies with the true CI/CD approach. - -Rollback options: - - Recommended: rollback via reverting the commit in the master branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. - - By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). - -### Deploy to staging from master at the click of a button - -The pipeline to deploy to staging can only be [run manually](#run-a-pipeline-manually) on a commit from the master branch. The pipeline is triggered manually using the CI/CD system's tools, such as a dedicated button or an API call. - -Rollback options: - - Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). - - Revert the commit in the master branch and then [manually](#run-a-pipeline-manually) run the pipeline using the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the master does not consistent with the state of the environment at all times (as opposed to the automatic deployment from master to staging). Thus, it does not make sense to revert exclusively for the rollback. - -### Automatically deploy to production-like from a branch - -A merge request or a commit to the specific branch triggers the pipeline to deploy to the production-like environment (this option is similar to (master-automatically) (#master-automatically), but involves a separate branch). A separate branch is used for each specific production-like environment, such as staging or testing. - -The state of the specific branch is consistent with the state of the environment at any given time. Therefore, this option complies with the true CI/CD approach. - -Rollback options: - - Recommended: rollback via reverting the commit in the branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. - - By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). - - Revert the commit in the master, then fast-forward merge to the specific branch. - - Delete the commit in the specific branch (by deleting the commit in git and then using the git push-force procedure). - -### Deploy to production-like from a branch at the click of a button - -Manually run a pipeline to deploy to the production-like environment for a commit to the specific branch only. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. - -Rollback options: - - Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). - - Revert the commit in the specific branch and then [manually](#run-a-pipeline-manually) run the pipeline using the means of the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the branch is not consistent with the state of the environment at all times (as opposed to the automatic deployment to the production-like environment). Thus, it does not make sense to revert exclusively for the purposes of a rollback. - -### Automatically deploy to review using a pull request - -Further commits to the branch tied to the pull request automatically trigger roll-outs to the review environment. - -Rollback options: - - Recommended: rollback via reverting the commit in the branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. - - By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). - -Deleting the review environment: - - By closing or merging a PR. - - Automatically when the time-lo-live period since the last deployment expires (in other words, if there is no activity in the environment). - -### Automatically deploy to review from a branch using a pattern - -Creating a pull request for a branch that matches some specific pattern automatically triggers a roll-out to a separate review environment. The name of this environment is associated with the name of the branch. Further commits to the branch associated with the pull request automatically trigger a roll-out to the review environment. - -For example, if you have a `review_*` pattern, then the creation of a pull request for the branch called `review_myfeature1` would automatically lead to the creation of the corresponding review-environment. - -Rollback options: - - Recommended: rollback via reverting the commit in the branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. - - By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). - -Deleting the review environment: - - By closing or merging a PR. - - Automatically when the time-lo-live period since the last deployment expires (in other words, if there is no activity in the environment). - -### Deploy to review using a pull request at the click of a button - -The pipeline to deploy to the review environment can only be run manually on a commit from the branch tied to this environment. The name of this environment is associated with the name of the branch. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button, an API call, or by assigning a label. - -Rollback options: - - Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). - - Revert the commit in the specific branch and then [manually](#run-a-pipeline-manually) run the pipeline using the means of the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the branch does not always correspond to the state of the environment (in contrast to "deploy automatically using the pull request" and "deploy automatically using the pull request and a pattern"), so it does not make sense to perform a revert solely for the rollback. - -Deleting the review environment: - - By closing or merging a PR. - - Automatically when the time-lo-live period since the last deployment expires (in other words, if there is no activity in the environment). - -### Automatically deploy to review using a pull request; manual triggering - -The review environment is created for the pull request after the pipeline is manually run by the means of the CI/CD system. From this point on, any commit to the branch tied to the pull request leads to an automatic roll-out to the review environment. After the work is complete, you can deactivate the review environment manually using the CI/CD system. - -The pipeline to deploy to the review environment can only be run manually on a commit from the branch tied to this environment. The name of this environment is associated with the name of the branch. The pipeline to activate the environment is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button, an API call, or by assigning a label. - -Rollback options: - - Recommended: rollback via reverting the commit in the branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. - - By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). - -Deleting the review environment: - - The pipeline to deactivate the environment is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button, an API call, or by assigning a label. - - By closing or merging a PR. - - Automatically when the time-lo-live period since the previous deployment expires (in other words, if there is no activity in the environment). - -## Comparing building blocks for creating a workflow - -### The level of git control - -| | **Rollback via git** | **Rollback manually** | -|:---|:---|:---| -| **Deploy via git** | [Automatically deploy to production from master](#automatically-deploy-to-production-from-master);
[Automatically deploy to production using a tag](#automatically-deploy-to-production-using-a-tag);
[Automatically deploy to production from a branch](#automatically-deploy-to-production-from-a-branch);
[Automatically deploy to staging from master](#automatically-deploy-to-staging-from-master);
[Automatically deploy to production-like from a branch](#automatically-deploy-to-production-like-from-a-branch);
[Automatically deploy to review using a pull request](#automatically-deploy-to-review-using-a-pull-request);
[Automatically deploy to review from a branch using a pattern](#automatically-deploy-to-review-from-a-branch-using-a-pattern);
[Automatically deploy to review using a pull request; manual triggering (semi-automatic)](#automatically-deploy-to-review-using-a-pull-request-manual-triggering); | [Automatically deploy to production from master](#automatically-deploy-to-production-from-master);
[Automatically deploy to production using a tag](#automatically-deploy-to-production-using-a-tag);
[Automatically deploy to production from a branch](#automatically-deploy-to-production-from-a-branch);
[Automatically deploy to staging from master](#automatically-deploy-to-staging-from-master);
[Automatically deploy to production-like from a branch](#automatically-deploy-to-production-like-from-a-branch);
[Automatically deploy to review using a pull request](#automatically-deploy-to-review-using-a-pull-request);
[Automatically deploy to review from a branch using a pattern](#automatically-deploy-to-review-from-a-branch-using-a-pattern);
[Automatically deploy to review using a pull request; manual triggering (semi-automatic)](#automatically-deploy-to-review-using-a-pull-request-manual-triggering); | -| **Deploy manually** | [Automatically deploy to review using a pull request; manual triggering (semi-automatic)](#automatically-deploy-to-review-using-a-pull-request-manual-triggering); | [Deploy to production from master at the click of a button](#deploy-to-production-from-master-at-the-click-of-a-button);
[Deploy to production using a tag at the click of a button](#deploy-to-production-using-a-tag-at-the-click-of-a-button);
[Deploy to production from a branch at the click of a button](#deploy-to-production-from-a-branch-at-the-click-of-a-button);
[Deploy to production-like using a pull request at the click of a button](#deploy-to-production-like-using-a-pull-request-at-the-click-of-a-button);
[Deploy to review using a pull request at the click of a button](#deploy-to-review-using-a-pull-request-at-the-click-of-a-button);
[Automatically deploy to review using a pull request; manual triggering (semi-automatic)](#automatically-deploy-to-review-using-a-pull-request-manual-triggering); | - -### Does the building block meet the criteria for CI/CD? - -| | **True CI/CD** | **Recommended for werf** | -|:---|:---:|:---:| -| [**Automatically deploy to production from master**](#automatically-deploy-to-production-from-master) | yes | yes | -| [**Deploy to production from master at the click of a button**](#deploy-to-production-from-master-at-the-click-of-a-button) | no | no | -| [**Automatically deploy to production using a tag**](#automatically-deploy-to-production-using-a-tag) | no | yes | -| [**Deploy to production using a tag at the click of a button**](#deploy-to-production-using-a-tag-at-the-click-of-a-button) | no | yes | -| [**Automatically deploy to production from a branch**](#automatically-deploy-to-production-from-a-branch) | yes | no | -| [**Deploy to production from a branch at the click of a button**](#deploy-to-production-from-a-branch-at-the-click-of-a-button) | no | no | -| [**Deploy to production-like using a pull request at the click of a button**](#deploy-to-production-like-using-a-pull-request-at-the-click-of-a-button) | no | yes | -| [**Automatically deploy to staging from master**](#automatically-deploy-to-staging-from-master) | yes | yes | -| [**Deploy to staging from master at the click of a button**](#deploy-to-staging-from-master-at-the-click-of-a-button) | no | no | -| [**Automatically deploy to production-like from a branch**](#automatically-deploy-to-production-like-from-a-branch) | yes | no | -| [**Deploy to production-like from a branch at the click of a button**](#deploy-to-production-like-from-a-branch-at-the-click-of-a-button) | no | no | -| [**Automatically deploy to review using a pull request**](#automatically-deploy-to-review-using-a-pull-request) | yes | no | -| [**Automatically deploy to review from a branch using a pattern**](#automatically-deploy-to-review-from-a-branch-using-a-pattern) | yes | no | -| [**Deploy to review using a pull request at the click of a button**](#deploy-to-review-using-a-pull-request-at-the-click-of-a-button) | no | no | -| [**Automatically deploy to review using a pull request; manual triggering**](#automatically-deploy-to-review-using-a-pull-request-manual-triggering) | yes | yes | - -## Ready-made workflow configurations - -In this section, we offer the user the selection of ready-made workflow configurations tailored to various use cases. These configurations are made up of the workflow blocks listed above. In the documentation, these ready-made configurations can also be referred to as workflow strategies. - -The exact configuration for each type of the CI/CD system you can find in the documentation for that system. For example, GitLab CI/CD: link, GitHub Actions: link. - -### №1 Fast and Furious - -We recommend this configuration as the most consistent with the principles of CI/CD of those that can be implemented using werf. - -This configuration supports any number of production-like environments, such as testing, staging, development, qa, and so on. - -| **Environment** | **The workflow block** | -| :--- | :--- | -| Production | [Automatically deploy to production from master](#automatically-deploy-to-production-from-master) + rollback changes via revert | -| Staging / Testing / Development / QA | [Deploy to production-like using a pull request at the click of a button](#deploy-to-production-like-using-a-pull-request-at-the-click-of-a-button) | -| Review | [Automatically deploy to review using a pull request; manual triggering](#automatically-deploy-to-review-using-a-pull-request-manual-triggering) | - -### №2 Push the button - -| **Environment** | **The workflow block** | -| :--- | :--- | -| Production | [Deploy to production from master at the click of a button](#deploy-to-production-from-master-at-the-click-of-a-button) | -| Staging | [Automatically deploy to staging from master](#automatically-deploy-to-staging-from-master) | -| Testing / Development / QA | [Automatically deploy to production-like from a branch](#automatically-deploy-to-production-like-from-a-branch) | -| Review | [Deploy to review using a pull request at the click of a button](#deploy-to-review-using-a-pull-request-at-the-click-of-a-button) | - -### №3 Tag everything - -Not all projects are ready to implement the CI/CD approach. These projects use the more classical approach, that implies making releases after the active development phase is complete. The transition to the CI/CD approach in such projects requires both developers and DevOps engineers to change personal habits and rethink the workflow. Therefore, for such projects, we also offer a classic configuration. We recommend to use it with werf if [fast & furious](#1-fast-and-furious) does not suit you. - -| **Environment** | **The workflow block** | -| :--- | :--- | -| Production | [Automatically deploy to production using a tag](#automatically-deploy-to-production-using-a-tag) | -| Staging | [Automatically deploy to staging from master or Deploy to staging from master at the click of a button](#automatically-deploy-to-staging-from-master) | -| Review | [Automatically deploy to review using a pull request; manual triggering](#automatically-deploy-to-review-using-a-pull-request-manual-triggering) | - -### №4 Branch, branch, branch - -Directly manage the deployment process via git by using branches and git merge, rebase, push-force procedures. By creating branches with specific names, you can trigger an automatic deployment to review environments. - -We recommend this configuration for those who would like to manage the CI/CD process via git only. Note that this approach is also consistent with the CI/CD principles (just like the fast & furious approach described above). - -| **Environment** | **The workflow block** | -| :--- | :--- | -| Production | [Automatically deploy to production from master](#automatically-deploy-to-production-from-master) + rollback changes via revert | -| Staging | [Automatically deploy to staging from master](#automatically-deploy-to-staging-from-master) | -| Review | [Automatically deploy to review from a branch using a pattern](#automatically-deploy-to-review-from-a-branch-using-a-pattern) | diff --git a/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md b/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md new file mode 100644 index 0000000000..bfb26e52a5 --- /dev/null +++ b/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md @@ -0,0 +1,239 @@ +--- +title: CI/CD workflows +permalink: usage/integration_with_ci_cd_systems/ci_cd_workflows.html +--- + +## Ready-made workflow configurations + +In this section, we offer the user the selection of ready-made workflow configurations tailored to various use cases. These configurations are made up of the workflow blocks listed above. In the documentation, these ready-made configurations can also be referred to as workflow strategies. + +The exact configuration for each type of the CI/CD system you can find in the documentation for that system. For example, GitLab CI/CD: link, GitHub Actions: link. + +### №1 Fast and Furious + +We recommend this configuration as the most consistent with the principles of CI/CD of those that can be implemented using werf. + +This configuration supports any number of production-like environments, such as testing, staging, development, qa, and so on. + +| **Environment** | **The workflow block** | +| :--- | :--- | +| Production | [Automatically deploy to production from master](#automatically-deploy-to-production-from-master) + rollback changes via revert | +| Staging / Testing / Development / QA | [Deploy to production-like using a pull request at the click of a button](#deploy-to-production-like-using-a-pull-request-at-the-click-of-a-button) | +| Review | [Automatically deploy to review using a pull request; manual triggering](#automatically-deploy-to-review-using-a-pull-request-manual-triggering) | + +### №2 Push the button + +| **Environment** | **The workflow block** | +| :--- | :--- | +| Production | [Deploy to production from master at the click of a button](#deploy-to-production-from-master-at-the-click-of-a-button) | +| Staging | [Automatically deploy to staging from master](#automatically-deploy-to-staging-from-master) | +| Testing / Development / QA | [Automatically deploy to production-like from a branch](#automatically-deploy-to-production-like-from-a-branch) | +| Review | [Deploy to review using a pull request at the click of a button](#deploy-to-review-using-a-pull-request-at-the-click-of-a-button) | + +### №3 Tag everything + +Not all projects are ready to implement the CI/CD approach. These projects use the more classical approach, that implies making releases after the active development phase is complete. The transition to the CI/CD approach in such projects requires both developers and DevOps engineers to change personal habits and rethink the workflow. Therefore, for such projects, we also offer a classic configuration. We recommend to use it with werf if [fast & furious](#1-fast-and-furious) does not suit you. + +| **Environment** | **The workflow block** | +| :--- | :--- | +| Production | [Automatically deploy to production using a tag](#automatically-deploy-to-production-using-a-tag) | +| Staging | [Automatically deploy to staging from master or Deploy to staging from master at the click of a button](#automatically-deploy-to-staging-from-master) | +| Review | [Automatically deploy to review using a pull request; manual triggering](#automatically-deploy-to-review-using-a-pull-request-manual-triggering) | + +### №4 Branch, branch, branch + +Directly manage the deployment process via git by using branches and git merge, rebase, push-force procedures. By creating branches with specific names, you can trigger an automatic deployment to review environments. + +We recommend this configuration for those who would like to manage the CI/CD process via git only. Note that this approach is also consistent with the CI/CD principles (just like the fast & furious approach described above). + +| **Environment** | **The workflow block** | +| :--- | :--- | +| Production | [Automatically deploy to production from master](#automatically-deploy-to-production-from-master) + rollback changes via revert | +| Staging | [Automatically deploy to staging from master](#automatically-deploy-to-staging-from-master) | +| Review | [Automatically deploy to review from a branch using a pattern](#automatically-deploy-to-review-from-a-branch-using-a-pattern) | + +## Workflow components for various environments + +Next, we will discuss various options for rolling out to production and other environments in conjunction with the git. Each section describes a building block that you can use to work with a specific environment. We will call such a block a "workflow block". You can build your own workflow using workflow blocks or make use of a ready-made configuration (see [Ready-made workflow configurations](#ready-made-workflow-configurations) below). + +Review environments are created and deleted dynamically as per the developers' request. Thus, there are some specificities when deploying code to these environments. In the review-related sections, we will describe how to create as well as delete a review environment. + +### Automatically deploy to production from master + +A merge request or a commit to the master branch triggers the pipeline to deploy directly to production. + +The state of the branch reflects the state of the environment at any given time. Therefore, this option complies with the true CI/CD approach. + +Rollback options: +- Recommended: rollback via reverting the commit in the master branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. +- By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). + +### Deploy to production from master at the click of a button + +You can manually run a pipeline to deploy to production for a commit in the master branch only. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. + +Rollback options: +- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- By reverting a commit in the master branch and then [manually](#run-a-pipeline-manually) run the pipeline using the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the master is not consistent with the state of the environment at all times (as opposed to the automatic deployment). Thus, it does not make sense to revert exclusively for the rollback. + +### Automatically deploy to production using a tag + +Creating a new tag automatically triggers the pipeline to deploy the code to the production environment on the basis of the commit associated with this tag. + +Rollback options: +- Recommended: by means of CI/CD system; [re-run the pipeline manually](#run-a-pipeline-manually) using the old tag. +- By creating a new tag linked to the old commit; the pipeline will be run automatically for the new tag. It is not the best option since it leads to the generation of unnecessary tags. + +### Deploy to production using a tag at the click of a button + +The pipeline to deploy to the production environment can only be triggered using the existing tag in git. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. + +Rollback options: +- By means of the CI/CD system; [re-run the pipeline manually](#run-a-pipeline-manually) using the old tag. + +### Automatically deploy to production from a branch + +A merge request or a commit to the specific branch triggers the pipeline to deploy to production (this option is similar to the (master-automatically) (#master-automatically), but involves a separate branch). + +The state of the specific branch is consistent with the state of the environment at any given time. Therefore, this option complies with the true CI/CD approach. + +Rollback options: +- Recommended: rollback via reverting the commit in the branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. +- By means of the CI/CD system; the user can [manually run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "undo" button performs precisely these steps). +- By reverting the commit in the master, then fast-forwarding merge to the specific branch. +- By deleting the commit in the specific branch (delete the commit in git and then use the git push-force procedure). + +### Deploy to production from a branch at the click of a button + +Manually run a pipeline to deploy to production for a commit to the specific branch only. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. + +Rollback options: +- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- By reverting the commit in the specific branch and then [manually](#run-a-pipeline-manually) run the pipeline using the means of the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the master is not consistent with the state of the environment at all times (as opposed to the automatic deployment). Thus, it does not make sense to revert exclusively for the rollback. + +### Deploy to production-like using a pull request at the click of a button + +The pipeline to deploy to production can be run on any commit to the pull request. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. + +Rollback options: +- By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). + +### Automatically deploy to staging from master + +A merge request or a commit to the master branch triggers the pipeline to deploy directly to the staging environment. + +The state of the branch reflects the state of the environment at any given time. Therefore, this option complies with the true CI/CD approach. + +Rollback options: +- Recommended: rollback via reverting the commit in the master branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. +- By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). + +### Deploy to staging from master at the click of a button + +The pipeline to deploy to staging can only be [run manually](#run-a-pipeline-manually) on a commit from the master branch. The pipeline is triggered manually using the CI/CD system's tools, such as a dedicated button or an API call. + +Rollback options: +- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- Revert the commit in the master branch and then [manually](#run-a-pipeline-manually) run the pipeline using the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the master does not consistent with the state of the environment at all times (as opposed to the automatic deployment from master to staging). Thus, it does not make sense to revert exclusively for the rollback. + +### Automatically deploy to production-like from a branch + +A merge request or a commit to the specific branch triggers the pipeline to deploy to the production-like environment (this option is similar to (master-automatically) (#master-automatically), but involves a separate branch). A separate branch is used for each specific production-like environment, such as staging or testing. + +The state of the specific branch is consistent with the state of the environment at any given time. Therefore, this option complies with the true CI/CD approach. + +Rollback options: +- Recommended: rollback via reverting the commit in the branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. +- By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- Revert the commit in the master, then fast-forward merge to the specific branch. +- Delete the commit in the specific branch (by deleting the commit in git and then using the git push-force procedure). + +### Deploy to production-like from a branch at the click of a button + +Manually run a pipeline to deploy to the production-like environment for a commit to the specific branch only. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. + +Rollback options: +- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- Revert the commit in the specific branch and then [manually](#run-a-pipeline-manually) run the pipeline using the means of the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the branch is not consistent with the state of the environment at all times (as opposed to the automatic deployment to the production-like environment). Thus, it does not make sense to revert exclusively for the purposes of a rollback. + +### Automatically deploy to review using a pull request + +Further commits to the branch tied to the pull request automatically trigger roll-outs to the review environment. + +Rollback options: +- Recommended: rollback via reverting the commit in the branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. +- By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). + +Deleting the review environment: +- By closing or merging a PR. +- Automatically when the time-lo-live period since the last deployment expires (in other words, if there is no activity in the environment). + +### Automatically deploy to review from a branch using a pattern + +Creating a pull request for a branch that matches some specific pattern automatically triggers a roll-out to a separate review environment. The name of this environment is associated with the name of the branch. Further commits to the branch associated with the pull request automatically trigger a roll-out to the review environment. + +For example, if you have a `review_*` pattern, then the creation of a pull request for the branch called `review_myfeature1` would automatically lead to the creation of the corresponding review-environment. + +Rollback options: +- Recommended: rollback via reverting the commit in the branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. +- By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). + +Deleting the review environment: +- By closing or merging a PR. +- Automatically when the time-lo-live period since the last deployment expires (in other words, if there is no activity in the environment). + +### Deploy to review using a pull request at the click of a button + +The pipeline to deploy to the review environment can only be run manually on a commit from the branch tied to this environment. The name of this environment is associated with the name of the branch. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button, an API call, or by assigning a label. + +Rollback options: +- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- Revert the commit in the specific branch and then [manually](#run-a-pipeline-manually) run the pipeline using the means of the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the branch does not always correspond to the state of the environment (in contrast to "deploy automatically using the pull request" and "deploy automatically using the pull request and a pattern"), so it does not make sense to perform a revert solely for the rollback. + +Deleting the review environment: +- By closing or merging a PR. +- Automatically when the time-lo-live period since the last deployment expires (in other words, if there is no activity in the environment). + +### Automatically deploy to review using a pull request; manual triggering + +The review environment is created for the pull request after the pipeline is manually run by the means of the CI/CD system. From this point on, any commit to the branch tied to the pull request leads to an automatic roll-out to the review environment. After the work is complete, you can deactivate the review environment manually using the CI/CD system. + +The pipeline to deploy to the review environment can only be run manually on a commit from the branch tied to this environment. The name of this environment is associated with the name of the branch. The pipeline to activate the environment is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button, an API call, or by assigning a label. + +Rollback options: +- Recommended: rollback via reverting the commit in the branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. +- By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). + +Deleting the review environment: +- The pipeline to deactivate the environment is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button, an API call, or by assigning a label. +- By closing or merging a PR. +- Automatically when the time-lo-live period since the previous deployment expires (in other words, if there is no activity in the environment). + +## Comparing building blocks for creating a workflow + +### The level of git control + +| | **Rollback via git** | **Rollback manually** | +|:---|:---|:---| +| **Deploy via git** | [Automatically deploy to production from master](#automatically-deploy-to-production-from-master);
[Automatically deploy to production using a tag](#automatically-deploy-to-production-using-a-tag);
[Automatically deploy to production from a branch](#automatically-deploy-to-production-from-a-branch);
[Automatically deploy to staging from master](#automatically-deploy-to-staging-from-master);
[Automatically deploy to production-like from a branch](#automatically-deploy-to-production-like-from-a-branch);
[Automatically deploy to review using a pull request](#automatically-deploy-to-review-using-a-pull-request);
[Automatically deploy to review from a branch using a pattern](#automatically-deploy-to-review-from-a-branch-using-a-pattern);
[Automatically deploy to review using a pull request; manual triggering (semi-automatic)](#automatically-deploy-to-review-using-a-pull-request-manual-triggering); | [Automatically deploy to production from master](#automatically-deploy-to-production-from-master);
[Automatically deploy to production using a tag](#automatically-deploy-to-production-using-a-tag);
[Automatically deploy to production from a branch](#automatically-deploy-to-production-from-a-branch);
[Automatically deploy to staging from master](#automatically-deploy-to-staging-from-master);
[Automatically deploy to production-like from a branch](#automatically-deploy-to-production-like-from-a-branch);
[Automatically deploy to review using a pull request](#automatically-deploy-to-review-using-a-pull-request);
[Automatically deploy to review from a branch using a pattern](#automatically-deploy-to-review-from-a-branch-using-a-pattern);
[Automatically deploy to review using a pull request; manual triggering (semi-automatic)](#automatically-deploy-to-review-using-a-pull-request-manual-triggering); | +| **Deploy manually** | [Automatically deploy to review using a pull request; manual triggering (semi-automatic)](#automatically-deploy-to-review-using-a-pull-request-manual-triggering); | [Deploy to production from master at the click of a button](#deploy-to-production-from-master-at-the-click-of-a-button);
[Deploy to production using a tag at the click of a button](#deploy-to-production-using-a-tag-at-the-click-of-a-button);
[Deploy to production from a branch at the click of a button](#deploy-to-production-from-a-branch-at-the-click-of-a-button);
[Deploy to production-like using a pull request at the click of a button](#deploy-to-production-like-using-a-pull-request-at-the-click-of-a-button);
[Deploy to review using a pull request at the click of a button](#deploy-to-review-using-a-pull-request-at-the-click-of-a-button);
[Automatically deploy to review using a pull request; manual triggering (semi-automatic)](#automatically-deploy-to-review-using-a-pull-request-manual-triggering); | + +### Does the building block meet the criteria for CI/CD? + +| | **True CI/CD** | **Recommended for werf** | +|:---|:---:|:---:| +| [**Automatically deploy to production from master**](#automatically-deploy-to-production-from-master) | yes | yes | +| [**Deploy to production from master at the click of a button**](#deploy-to-production-from-master-at-the-click-of-a-button) | no | no | +| [**Automatically deploy to production using a tag**](#automatically-deploy-to-production-using-a-tag) | no | yes | +| [**Deploy to production using a tag at the click of a button**](#deploy-to-production-using-a-tag-at-the-click-of-a-button) | no | yes | +| [**Automatically deploy to production from a branch**](#automatically-deploy-to-production-from-a-branch) | yes | no | +| [**Deploy to production from a branch at the click of a button**](#deploy-to-production-from-a-branch-at-the-click-of-a-button) | no | no | +| [**Deploy to production-like using a pull request at the click of a button**](#deploy-to-production-like-using-a-pull-request-at-the-click-of-a-button) | no | yes | +| [**Automatically deploy to staging from master**](#automatically-deploy-to-staging-from-master) | yes | yes | +| [**Deploy to staging from master at the click of a button**](#deploy-to-staging-from-master-at-the-click-of-a-button) | no | no | +| [**Automatically deploy to production-like from a branch**](#automatically-deploy-to-production-like-from-a-branch) | yes | no | +| [**Deploy to production-like from a branch at the click of a button**](#deploy-to-production-like-from-a-branch-at-the-click-of-a-button) | no | no | +| [**Automatically deploy to review using a pull request**](#automatically-deploy-to-review-using-a-pull-request) | yes | no | +| [**Automatically deploy to review from a branch using a pattern**](#automatically-deploy-to-review-from-a-branch-using-a-pattern) | yes | no | +| [**Deploy to review using a pull request at the click of a button**](#deploy-to-review-using-a-pull-request-at-the-click-of-a-button) | no | no | +| [**Automatically deploy to review using a pull request; manual triggering**](#automatically-deploy-to-review-using-a-pull-request-manual-triggering) | yes | yes | diff --git a/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md b/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md index f5e66885dc..7e6bb2a6cb 100644 --- a/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md +++ b/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md @@ -91,237 +91,4 @@ Pipeline-ы и стадии внутри pipeline-ов могут быть ак Если вы хотите узнать больше подробностей по методике составления workflow или для вашей CI/CD системы не нашлось инструкции, тогда можно ознакомится с дальнейшими разделами где определяются [составляющие workflow](#составляющие-workflow-для-отдельных-окружений) и [готовые конфигурации workflow](#готовые-конфигурации-workflow). После этого вы будете готовы выбрать готовую конфигурацию или составить свою и реализовать её для вашей CI/CD системы с использованием werf. -## Составляющие workflow для отдельных окружений -Далее рассмотрим различные варианты выката production и других окружений в связке с git. Каждый пункт определяет строительный блок, который можно использовать для работы с определённым окружением. Мы будем называть такой строительный блок блоком workflow. Из блоков workflow в дальнейшем можно собрать свой workflow или взять готовую конфигурацию (см. далее [готовые конфигурации workflow](#готовые-конфигурации-workflow)). - -Review окружения создаются и удаляются динамически по требованию разработчиков. С этим связаны особенности выката в эти окружения. В разделах, связанных с review, будет описано не только как создать review-окружение, но и как его удалить. - -### Выкат на production из master автоматически - -Merge или коммит в ветку master вызывает pipeline выката непосредственно на production. - -Состояние ветки в любой момент времени отражает состояние окружения. Поэтому данный вариант является соответствующим подходу true CI/CD. - -Варианты отката: - - Рекомендованный: откат через реверт коммита в ветке master. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. - - Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). - -### Выкат на production из master по кнопке - -Pipeline выката в production может быть запущен вручную только на коммите из ветки master. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. - -Варианты отката: - - Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). - - Реверт коммита в ветке master, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта master-автоматом), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. - -### Выкат на production из тега автоматически - -Создание нового тега автоматически вызывает pipeline выката на production-окружение из коммита, связанного с этим тегом. - -Варианты отката: - - Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом теге. - - Создание нового тега на старый коммит, далее автоматический вызов pipeline выката для нового тега. Не предпочтительный вариант, т.к. плодятся лишние теги. - -### Выкат на production из тега по кнопке - -Pipeline выката в production-окружение может быть вызван только на существующем теге в git. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. - -Варианты отката: - - Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом теге. - -### Выкат на production из ветки автоматически - -Merge или коммит в специальную ветку вызывает pipeline выката непосредственно на production (вариант похож на (master-автоматически)(#master-автоматически), но используется отдельная ветка). - -Состояние специальной ветки в любой момент времени отражает состояние окружения. Поэтому данный вариант является соответствующим подходу true CI/CD. - -Варианты отката: - - Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. - - Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). - - Реверт коммита в master, затем fast-forward merge в специальную ветку. - - Удаление коммита в специальной ветке (через удаление коммита в git, затем процедура git push-force). - -### Выкат на production из ветки по кнопке - -Pipeline выката в production может быть запущен вручную только на коммите из специальной ветки. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. - -Варианты отката: - - Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). - - Реверт коммита в ветке, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта master-автоматом), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. - -### Выкат на production-like из pull request по кнопке - -Pipeline выката в production может быть запущен на любом коммите в pull request. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. - -Варианты отката: - - Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). - -### Выкат на staging из master автоматически - -Merge или коммит в ветку master вызывает pipeline выката непосредственно на staging окружение. - -Состояние ветки в любой момент времени отражает состояние окружения. Поэтому данный вариант является соответствующим подходу true CI/CD. - -Варианты отката: - - Рекомендованный: откат через реверт коммита в ветке master. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. - - Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). - -### Выкат на staging из master по кнопке - -Pipeline выката в staging может быть запущен вручную только на коммите из ветки master. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. - -Варианты отката: - - Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). - - Реверт коммита в ветке master, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта Выкат на staging из master автоматически), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. - -### Выкат на production-like из ветки автоматически - -Merge или коммит в специальную ветку вызывает pipeline выката непосредственно на production-like окружение (вариант похож на (master-автоматически)(#master-автоматически), но используется отдельная ветка). Для каждого конкретного production-like окружения, как то: staging или testing — используется отдельная ветка. - -Состояние специальной ветки в любой момент времени отражает состояние окружения. Поэтому данный вариант является соответствующим подходу true CI/CD. - -Варианты отката: - - Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. - - Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). - - Реверт коммита в master, затем fast-forward merge в специальную ветку. - - Удаление коммита в специальной ветке (через удаление коммита в git, затем процедура git push-force). - -### Выкат на production-like из ветки по кнопке - -Pipeline выката в production-like окружение может быть запущен вручную только на коммите из специальной ветки. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. - -Варианты отката: - - Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). - - Реверт коммита в ветке, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние ветки не всегда соответствует состоянию окружения (в отличие от варианта Выкат на production-like из ветки автоматически), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. - -### Выкат на review из pull request автоматически - -Создание pull request автоматически вызывает выкат в отдельное review окружение. Название этого окружения связано с именем ветки. Дальнейшие коммиты в ветку, связанную с pull request автоматически вызывают выкат в review окружение. - -Варианты отката: - - Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. - - Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). - -Удаление review-окружения: - - По закрытию или принятию PR. - - Автоматически по истечению time-to-live с последнего выката на данное окружение (другими словами, при отсутствии активности в данном окружении). - -### Выкат на review из ветки по шаблону автоматически - -Создание pull request для ветки, подходящей под определённый паттерн автоматически вызывает выкат в отдельное review окружение. Название этого окружения связано с именем ветки. Дальнейшие коммиты в ветку, связанную с pull request автоматически вызывают выкат в review окружение. - -Например, для паттерна `review_*` создание pull request для ветки `review_myfeature1` вызовет автоматическое создание соответствующего review окружения. - -Варианты отката: - - Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. - - Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). - -Удаление review-окружения: - - По закрытию или принятию PR. - - Автоматически по истечению time-to-live с последнего выката на данное окружение (другими словами, при отсутствии активности в данном окружении). - -### Выкат на review из pull request по кнопке - -Pipeline выката в review-окружение может быть запущен вручную только на коммите из ветки соответствующей этому окружению. Название этого окружения связано с именем ветки. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе, повесить label или вызов API. - -Варианты отката: - - Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). - - Реверт коммита в ветке, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние ветки не всегда соответствует состоянию окружения (в отличие от вариантов "автоматом для pull-request" и "автоматом для pull-request по паттерну"), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. - -Удаление review-окружения: - - По закрытию или принятию PR. - - Автоматически по истечению time-to-live с последнего выката на данное окружение (другими словами, при отсутствии активности в данном окружении). - -### Выкат на review из pull request автоматически после ручной активации - -Review-окружение для pull request создаётся после его ручной активации средствами CI/CD системы. С этого момента любой коммит в ветку, связанную с pull request, вызывает автоматический выкат на review окружение. После работы с review его можно деактивировать вручную средствами CI/CD системы. - -Pipeline выката в review-окружение может быть запущен только на коммите из ветки соответствующей этому окружению. Название этого окружения связано с именем ветки. Запуск pipeline для активации review окружения производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе, повесить label или вызов API. - -Варианты отката: - - Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. - - Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). - -Удаление review-окружения: - - Запуск pipeline для деактивации review окружения средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе, снять ранее повешенный label или вызов API. - - По закрытию или принятию PR. - - Автоматически по истечению time-to-live с последнего выката на данное окружение (другими словами, при отсутствии активности в данном окружении). - -## Сравнение составляющих блоков для построения workflow - -### Степень управляемости через git - -| | **Откат через git** | **Ручной откат** | -|:---|:---|:---| -| **Выкат через git** | [Выкат на production из master автоматически](#выкат-на-production-из-master-автоматически);
[Выкат на production из тега автоматически](#выкат-на-production-из-тега-автоматически);
[Выкат на production из ветки автоматически](#выкат-на-production-из-ветки-автоматически);
[Выкат на staging из master автоматически](#выкат-на-staging-из-master-автоматически);
[Выкат на production-like из ветки автоматически](#выкат-на-production-like-из-ветки-автоматически);
[Выкат на review из pull request автоматически](#выкат-на-review-из-pull-request-автоматически);
[Выкат на review из ветки по шаблону автоматически](#выкат-на-review-из-ветки-по-шаблону-автоматически);
[Выкат на review из pull request автоматически после ручной активации (полуавтоматический)](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации); | [Выкат на production из master автоматически](#выкат-на-production-из-master-автоматически);
[Выкат на production из тега автоматически](#выкат-на-production-из-тега-автоматически);
[Выкат на production из ветки автоматически](#выкат-на-production-из-ветки-автоматически);
[Выкат на staging из master автоматически](#выкат-на-staging-из-master-автоматически);
[Выкат на production-like из ветки автоматически](#выкат-на-production-like-из-ветки-автоматически);
[Выкат на review из pull request автоматически](#выкат-на-review-из-pull-request-автоматически);
[Выкат на review из ветки по шаблону автоматически](#выкат-на-review-из-ветки-по-шаблону-автоматически);
[Выкат на review из pull request автоматически после ручной активации (полуавтоматический)](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации); | -| **Ручной выкат** | [Выкат на review из pull request автоматически после ручной активации (полуавтоматический)](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации); | [Выкат на production из master по кнопке](#выкат-на-production-из-master-по-кнопке);
[Выкат на production из тега по кнопке](#выкат-на-production-из-тега-по-кнопке);
[Выкат на production из ветки по кнопке](#выкат-на-production-из-ветки-по-кнопке);
[Выкат на production-like из pull request по кнопке](#выкат-на-production-like-из-pull-request-по-кнопке);
[Выкат на review из pull request по кнопке](#выкат-на-review-из-pull-request-по-кнопке);
[Выкат на review из pull request автоматически после ручной активации (полуавтоматический)](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации); | - -### Соответствие CI/CD - -| | **True CI/CD** | **Рекомендовано для werf** | -|:---|:---:|:---:| -| [**Выкат на production из master автоматически**](#выкат-на-production-из-master-автоматически) | да | да | -| [**Выкат на production из master по кнопке**](#выкат-на-production-из-master-по-кнопке) | нет | нет | -| [**Выкат на production из тега автоматически**](#выкат-на-production-из-тега-автоматически) | нет | да | -| [**Выкат на production из тега по кнопке**](#выкат-на-production-из-тега-по-кнопке) | нет | да | -| [**Выкат на production из ветки автоматически**](#выкат-на-production-из-ветки-автоматически) | да | нет | -| [**Выкат на production из ветки по кнопке**](#выкат-на-production-из-ветки-по-кнопке) | нет | нет | -| [**Выкат на production-like из pull request по кнопке**](#выкат-на-production-like-из-pull-request-по-кнопке) | нет | да | -| [**Выкат на staging из master автоматически**](#выкат-на-staging-из-master-автоматически) | да | да | -| [**Выкат на staging из master по кнопке**](#выкат-на-staging-из-master-по-кнопке) | нет | нет | -| [**Выкат на production-like из ветки автоматически**](#выкат-на-production-like-из-ветки-автоматически) | да | нет | -| [**Выкат на production-like из ветки по кнопке**](#выкат-на-production-like-из-ветки-по-кнопке) | нет | нет | -| [**Выкат на review из pull request автоматически**](#выкат-на-review-из-pull-request-автоматически) | да | нет | -| [**Выкат на review из ветки по шаблону автоматически**](#выкат-на-review-из-ветки-по-шаблону-автоматически) | да | нет | -| [**Выкат на review из pull request по кнопке**](#выкат-на-review-из-pull-request-по-кнопке) | нет | нет | -| [**Выкат на review из pull request автоматически после ручной активации**](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации) | да | да | - -## Готовые конфигурации workflow - -Мы предлагаем пользователю на выбор несколько готовых конфигураций workflow для проекта. Эти конфигурации составлены из приведенных выше блоков workflow. В документации эти готовые конфигурации могут называться также стратегиями workflow. - -Конкретные конфиги по каждой из конфигураций можно найти в инструкциях по конкретной CI/CD системе. Например, Gitlab CI: ссылка, Github Actions: ссылка. - -### №1 Fast and Furious - -Конфигурация рекомендована в качестве наиболее соответствующей канонам CI/CD, которую можно реализовать с помощью werf. - -В данной конфигурации может быть произвольное число production-like окружений, как то: testing, staging, development, qa, и т.д. - -| **Окружение** | **Блок workflow** | -| :--- | :--- | -| Production | [Выкат на production из master автоматически](#выкат-на-production-из-master-автоматически) + откат через revert | -| Staging / Testing / Development / QA | [Выкат на production-like из pull request по кнопке](#выкат-на-production-like-из-pull-request-по-кнопке) | -| Review | [Выкат на review из pull request автоматически после ручной активации](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации) | - -### №2 Push the button - -| **Окружение** | **Блок workflow** | -| :--- | :--- | -| Production | [Выкат на production из master по кнопке](#выкат-на-production-из-master-по-кнопке) | -| Staging | [Выкат на staging из master автоматически](#выкат-на-staging-из-master-автоматически) | -| Testing / Development / QA | [Выкат на production-like из ветки автоматически](#выкат-на-production-like-из-ветки-автоматически) | -| Review | [Выкат на review из pull request по кнопке](#выкат-на-review-из-pull-request-по-кнопке) | - -### №3 Tag everything - -Не все проекты сходу готовы к внедрению CI/CD. В таких проектах используется более классический метод создания релизов только после активной фазы разработки. Переход к CI/CD в таких проектах требует усилий по преодолению привычных вещей и переосмысления как от разработчиков, так и от devops. Поэтому для таких проектов мы предлагаем и классическую конфигурацию, которая также рекомендована для werf в случае невозможности использования [fast & furious](#1-fast-and-furious). - -| **Окружение** | **Блок workflow** | -| :--- | :--- | -| Production | [Выкат на production из тега автоматически](#выкат-на-production-из-тега-автоматически) | -| Staging | [Выкат на staging из master автоматически](#выкат-на-staging-из-master-автоматически) или [выкат на staging из master по кнопке](#выкат-на-staging-из-master-по-кнопке) | -| Review | [Выкат на review из pull request автоматически после ручной активации](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации) | - -### №4 Branch, branch, branch - -Управляем выкатом прямо через git с использованием веток и процедур git merge, rebase и push-force. Через создание определённых имен веток получаем автоматический выкат на review окружения. - -Рекомендуем для тех, кто хочет управлять CI/CD полностью из git. Отметим, что подход также является соответствующим канонам CI/CD, как и fast & furious. - -| **Окружение** | **Блок workflow** | -| :--- | :--- | -| Production | [Выкат на production из master автоматически](#выкат-на-production-из-master-автоматически) + откат через revert | -| Staging | [Выкат на staging из master автоматически](#выкат-на-staging-из-master-автоматически) | -| Review | [Выкат на review из ветки по шаблону автоматически](#выкат-на-review-из-ветки-по-шаблону-автоматически) | diff --git a/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md b/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md new file mode 100644 index 0000000000..047ae1798c --- /dev/null +++ b/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md @@ -0,0 +1,239 @@ +--- +title: Рабочие процессы CI/CD +permalink: usage/integration_with_ci_cd_systems/ci_cd_workflows.html +--- + +## Готовые конфигурации workflow + +Мы предлагаем пользователю на выбор несколько готовых конфигураций workflow для проекта. Эти конфигурации составлены из приведенных выше блоков workflow. В документации эти готовые конфигурации могут называться также стратегиями workflow. + +Конкретные конфиги по каждой из конфигураций можно найти в инструкциях по конкретной CI/CD системе. Например, Gitlab CI: ссылка, Github Actions: ссылка. + +### №1 Fast and Furious + +Конфигурация рекомендована в качестве наиболее соответствующей канонам CI/CD, которую можно реализовать с помощью werf. + +В данной конфигурации может быть произвольное число production-like окружений, как то: testing, staging, development, qa, и т.д. + +| **Окружение** | **Блок workflow** | +| :--- | :--- | +| Production | [Выкат на production из master автоматически](#выкат-на-production-из-master-автоматически) + откат через revert | +| Staging / Testing / Development / QA | [Выкат на production-like из pull request по кнопке](#выкат-на-production-like-из-pull-request-по-кнопке) | +| Review | [Выкат на review из pull request автоматически после ручной активации](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации) | + +### №2 Push the button + +| **Окружение** | **Блок workflow** | +| :--- | :--- | +| Production | [Выкат на production из master по кнопке](#выкат-на-production-из-master-по-кнопке) | +| Staging | [Выкат на staging из master автоматически](#выкат-на-staging-из-master-автоматически) | +| Testing / Development / QA | [Выкат на production-like из ветки автоматически](#выкат-на-production-like-из-ветки-автоматически) | +| Review | [Выкат на review из pull request по кнопке](#выкат-на-review-из-pull-request-по-кнопке) | + +### №3 Tag everything + +Не все проекты сходу готовы к внедрению CI/CD. В таких проектах используется более классический метод создания релизов только после активной фазы разработки. Переход к CI/CD в таких проектах требует усилий по преодолению привычных вещей и переосмысления как от разработчиков, так и от devops. Поэтому для таких проектов мы предлагаем и классическую конфигурацию, которая также рекомендована для werf в случае невозможности использования [fast & furious](#1-fast-and-furious). + +| **Окружение** | **Блок workflow** | +| :--- | :--- | +| Production | [Выкат на production из тега автоматически](#выкат-на-production-из-тега-автоматически) | +| Staging | [Выкат на staging из master автоматически](#выкат-на-staging-из-master-автоматически) или [выкат на staging из master по кнопке](#выкат-на-staging-из-master-по-кнопке) | +| Review | [Выкат на review из pull request автоматически после ручной активации](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации) | + +### №4 Branch, branch, branch + +Управляем выкатом прямо через git с использованием веток и процедур git merge, rebase и push-force. Через создание определённых имен веток получаем автоматический выкат на review окружения. + +Рекомендуем для тех, кто хочет управлять CI/CD полностью из git. Отметим, что подход также является соответствующим канонам CI/CD, как и fast & furious. + +| **Окружение** | **Блок workflow** | +| :--- | :--- | +| Production | [Выкат на production из master автоматически](#выкат-на-production-из-master-автоматически) + откат через revert | +| Staging | [Выкат на staging из master автоматически](#выкат-на-staging-из-master-автоматически) | +| Review | [Выкат на review из ветки по шаблону автоматически](#выкат-на-review-из-ветки-по-шаблону-автоматически) | + +## Составляющие workflow для отдельных окружений + +Далее рассмотрим различные варианты выката production и других окружений в связке с git. Каждый пункт определяет строительный блок, который можно использовать для работы с определённым окружением. Мы будем называть такой строительный блок блоком workflow. Из блоков workflow в дальнейшем можно собрать свой workflow или взять готовую конфигурацию (см. далее [готовые конфигурации workflow](#готовые-конфигурации-workflow)). + +Review окружения создаются и удаляются динамически по требованию разработчиков. С этим связаны особенности выката в эти окружения. В разделах, связанных с review, будет описано не только как создать review-окружение, но и как его удалить. + +### Выкат на production из master автоматически + +Merge или коммит в ветку master вызывает pipeline выката непосредственно на production. + +Состояние ветки в любой момент времени отражает состояние окружения. Поэтому данный вариант является соответствующим подходу true CI/CD. + +Варианты отката: +- Рекомендованный: откат через реверт коммита в ветке master. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. +- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). + +### Выкат на production из master по кнопке + +Pipeline выката в production может быть запущен вручную только на коммите из ветки master. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. + +Варианты отката: +- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Реверт коммита в ветке master, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта master-автоматом), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. + +### Выкат на production из тега автоматически + +Создание нового тега автоматически вызывает pipeline выката на production-окружение из коммита, связанного с этим тегом. + +Варианты отката: +- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом теге. +- Создание нового тега на старый коммит, далее автоматический вызов pipeline выката для нового тега. Не предпочтительный вариант, т.к. плодятся лишние теги. + +### Выкат на production из тега по кнопке + +Pipeline выката в production-окружение может быть вызван только на существующем теге в git. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. + +Варианты отката: +- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом теге. + +### Выкат на production из ветки автоматически + +Merge или коммит в специальную ветку вызывает pipeline выката непосредственно на production (вариант похож на (master-автоматически)(#master-автоматически), но используется отдельная ветка). + +Состояние специальной ветки в любой момент времени отражает состояние окружения. Поэтому данный вариант является соответствующим подходу true CI/CD. + +Варианты отката: +- Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. +- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Реверт коммита в master, затем fast-forward merge в специальную ветку. +- Удаление коммита в специальной ветке (через удаление коммита в git, затем процедура git push-force). + +### Выкат на production из ветки по кнопке + +Pipeline выката в production может быть запущен вручную только на коммите из специальной ветки. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. + +Варианты отката: +- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Реверт коммита в ветке, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта master-автоматом), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. + +### Выкат на production-like из pull request по кнопке + +Pipeline выката в production может быть запущен на любом коммите в pull request. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. + +Варианты отката: +- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). + +### Выкат на staging из master автоматически + +Merge или коммит в ветку master вызывает pipeline выката непосредственно на staging окружение. + +Состояние ветки в любой момент времени отражает состояние окружения. Поэтому данный вариант является соответствующим подходу true CI/CD. + +Варианты отката: +- Рекомендованный: откат через реверт коммита в ветке master. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. +- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). + +### Выкат на staging из master по кнопке + +Pipeline выката в staging может быть запущен вручную только на коммите из ветки master. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. + +Варианты отката: +- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Реверт коммита в ветке master, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта Выкат на staging из master автоматически), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. + +### Выкат на production-like из ветки автоматически + +Merge или коммит в специальную ветку вызывает pipeline выката непосредственно на production-like окружение (вариант похож на (master-автоматически)(#master-автоматически), но используется отдельная ветка). Для каждого конкретного production-like окружения, как то: staging или testing — используется отдельная ветка. + +Состояние специальной ветки в любой момент времени отражает состояние окружения. Поэтому данный вариант является соответствующим подходу true CI/CD. + +Варианты отката: +- Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. +- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Реверт коммита в master, затем fast-forward merge в специальную ветку. +- Удаление коммита в специальной ветке (через удаление коммита в git, затем процедура git push-force). + +### Выкат на production-like из ветки по кнопке + +Pipeline выката в production-like окружение может быть запущен вручную только на коммите из специальной ветки. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. + +Варианты отката: +- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Реверт коммита в ветке, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние ветки не всегда соответствует состоянию окружения (в отличие от варианта Выкат на production-like из ветки автоматически), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. + +### Выкат на review из pull request автоматически + +Создание pull request автоматически вызывает выкат в отдельное review окружение. Название этого окружения связано с именем ветки. Дальнейшие коммиты в ветку, связанную с pull request автоматически вызывают выкат в review окружение. + +Варианты отката: +- Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. +- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). + +Удаление review-окружения: +- По закрытию или принятию PR. +- Автоматически по истечению time-to-live с последнего выката на данное окружение (другими словами, при отсутствии активности в данном окружении). + +### Выкат на review из ветки по шаблону автоматически + +Создание pull request для ветки, подходящей под определённый паттерн автоматически вызывает выкат в отдельное review окружение. Название этого окружения связано с именем ветки. Дальнейшие коммиты в ветку, связанную с pull request автоматически вызывают выкат в review окружение. + +Например, для паттерна `review_*` создание pull request для ветки `review_myfeature1` вызовет автоматическое создание соответствующего review окружения. + +Варианты отката: +- Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. +- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). + +Удаление review-окружения: +- По закрытию или принятию PR. +- Автоматически по истечению time-to-live с последнего выката на данное окружение (другими словами, при отсутствии активности в данном окружении). + +### Выкат на review из pull request по кнопке + +Pipeline выката в review-окружение может быть запущен вручную только на коммите из ветки соответствующей этому окружению. Название этого окружения связано с именем ветки. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе, повесить label или вызов API. + +Варианты отката: +- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Реверт коммита в ветке, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние ветки не всегда соответствует состоянию окружения (в отличие от вариантов "автоматом для pull-request" и "автоматом для pull-request по паттерну"), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. + +Удаление review-окружения: +- По закрытию или принятию PR. +- Автоматически по истечению time-to-live с последнего выката на данное окружение (другими словами, при отсутствии активности в данном окружении). + +### Выкат на review из pull request автоматически после ручной активации + +Review-окружение для pull request создаётся после его ручной активации средствами CI/CD системы. С этого момента любой коммит в ветку, связанную с pull request, вызывает автоматический выкат на review окружение. После работы с review его можно деактивировать вручную средствами CI/CD системы. + +Pipeline выката в review-окружение может быть запущен только на коммите из ветки соответствующей этому окружению. Название этого окружения связано с именем ветки. Запуск pipeline для активации review окружения производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе, повесить label или вызов API. + +Варианты отката: +- Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. +- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). + +Удаление review-окружения: +- Запуск pipeline для деактивации review окружения средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе, снять ранее повешенный label или вызов API. +- По закрытию или принятию PR. +- Автоматически по истечению time-to-live с последнего выката на данное окружение (другими словами, при отсутствии активности в данном окружении). + +## Сравнение составляющих блоков для построения workflow + +### Степень управляемости через git + +| | **Откат через git** | **Ручной откат** | +|:---|:---|:---| +| **Выкат через git** | [Выкат на production из master автоматически](#выкат-на-production-из-master-автоматически);
[Выкат на production из тега автоматически](#выкат-на-production-из-тега-автоматически);
[Выкат на production из ветки автоматически](#выкат-на-production-из-ветки-автоматически);
[Выкат на staging из master автоматически](#выкат-на-staging-из-master-автоматически);
[Выкат на production-like из ветки автоматически](#выкат-на-production-like-из-ветки-автоматически);
[Выкат на review из pull request автоматически](#выкат-на-review-из-pull-request-автоматически);
[Выкат на review из ветки по шаблону автоматически](#выкат-на-review-из-ветки-по-шаблону-автоматически);
[Выкат на review из pull request автоматически после ручной активации (полуавтоматический)](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации); | [Выкат на production из master автоматически](#выкат-на-production-из-master-автоматически);
[Выкат на production из тега автоматически](#выкат-на-production-из-тега-автоматически);
[Выкат на production из ветки автоматически](#выкат-на-production-из-ветки-автоматически);
[Выкат на staging из master автоматически](#выкат-на-staging-из-master-автоматически);
[Выкат на production-like из ветки автоматически](#выкат-на-production-like-из-ветки-автоматически);
[Выкат на review из pull request автоматически](#выкат-на-review-из-pull-request-автоматически);
[Выкат на review из ветки по шаблону автоматически](#выкат-на-review-из-ветки-по-шаблону-автоматически);
[Выкат на review из pull request автоматически после ручной активации (полуавтоматический)](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации); | +| **Ручной выкат** | [Выкат на review из pull request автоматически после ручной активации (полуавтоматический)](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации); | [Выкат на production из master по кнопке](#выкат-на-production-из-master-по-кнопке);
[Выкат на production из тега по кнопке](#выкат-на-production-из-тега-по-кнопке);
[Выкат на production из ветки по кнопке](#выкат-на-production-из-ветки-по-кнопке);
[Выкат на production-like из pull request по кнопке](#выкат-на-production-like-из-pull-request-по-кнопке);
[Выкат на review из pull request по кнопке](#выкат-на-review-из-pull-request-по-кнопке);
[Выкат на review из pull request автоматически после ручной активации (полуавтоматический)](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации); | + +### Соответствие CI/CD + +| | **True CI/CD** | **Рекомендовано для werf** | +|:---|:---:|:---:| +| [**Выкат на production из master автоматически**](#выкат-на-production-из-master-автоматически) | да | да | +| [**Выкат на production из master по кнопке**](#выкат-на-production-из-master-по-кнопке) | нет | нет | +| [**Выкат на production из тега автоматически**](#выкат-на-production-из-тега-автоматически) | нет | да | +| [**Выкат на production из тега по кнопке**](#выкат-на-production-из-тега-по-кнопке) | нет | да | +| [**Выкат на production из ветки автоматически**](#выкат-на-production-из-ветки-автоматически) | да | нет | +| [**Выкат на production из ветки по кнопке**](#выкат-на-production-из-ветки-по-кнопке) | нет | нет | +| [**Выкат на production-like из pull request по кнопке**](#выкат-на-production-like-из-pull-request-по-кнопке) | нет | да | +| [**Выкат на staging из master автоматически**](#выкат-на-staging-из-master-автоматически) | да | да | +| [**Выкат на staging из master по кнопке**](#выкат-на-staging-из-master-по-кнопке) | нет | нет | +| [**Выкат на production-like из ветки автоматически**](#выкат-на-production-like-из-ветки-автоматически) | да | нет | +| [**Выкат на production-like из ветки по кнопке**](#выкат-на-production-like-из-ветки-по-кнопке) | нет | нет | +| [**Выкат на review из pull request автоматически**](#выкат-на-review-из-pull-request-автоматически) | да | нет | +| [**Выкат на review из ветки по шаблону автоматически**](#выкат-на-review-из-ветки-по-шаблону-автоматически) | да | нет | +| [**Выкат на review из pull request по кнопке**](#выкат-на-review-из-pull-request-по-кнопке) | нет | нет | +| [**Выкат на review из pull request автоматически после ручной активации**](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации) | да | да | From d1a74da92addb428d044977af9fbec6fe0b7544d Mon Sep 17 00:00:00 2001 From: Alexey Igrychev Date: Fri, 16 Dec 2022 12:35:52 +0000 Subject: [PATCH 2/7] docs(ci/cd): change ci/cd basics article title Signed-off-by: Alexey Igrychev --- docs/_data/sidebars/_documentation.yml | 2 +- docs/_data/sidebars/documentation.yml | 2 +- .../integration_with_ci_cd_systems/ci_cd_workflow_basics.md | 2 +- .../integration_with_ci_cd_systems/ci_cd_workflow_basics.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/_data/sidebars/_documentation.yml b/docs/_data/sidebars/_documentation.yml index f6ea294ab1..8156d6d0ac 100644 --- a/docs/_data/sidebars/_documentation.yml +++ b/docs/_data/sidebars/_documentation.yml @@ -302,7 +302,7 @@ entries: - title: Интеграция с CI/CD системами f: - - title: Основы организации CI/CD + - title: Основы рабочего процесса CI/CD url: /usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html - title: Рабочие процессы CI/CD diff --git a/docs/_data/sidebars/documentation.yml b/docs/_data/sidebars/documentation.yml index 40b3b5ed7a..53e4f7f5a0 100644 --- a/docs/_data/sidebars/documentation.yml +++ b/docs/_data/sidebars/documentation.yml @@ -932,7 +932,7 @@ entries: - title: Интеграция с CI/CD системами f: - - title: Основы организации CI/CD + - title: Основы рабочего процесса CI/CD url: /usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html - title: Рабочие процессы CI/CD diff --git a/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md b/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md index ba0ee74c86..e835f09e6d 100644 --- a/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md +++ b/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md @@ -1,5 +1,5 @@ --- -title: CI/CD basics +title: CI/CD workflow basics permalink: usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html --- diff --git a/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md b/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md index 7e6bb2a6cb..a8984c139d 100644 --- a/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md +++ b/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md @@ -1,5 +1,5 @@ --- -title: Основы организации CI/CD +title: Основы рабочего процесса CI/CD permalink: usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html --- From 4d259c2232f2f1af3904a53e3580dfd6f48a73d4 Mon Sep 17 00:00:00 2001 From: Alexey Igrychev Date: Fri, 16 Dec 2022 12:37:28 +0000 Subject: [PATCH 3/7] docs(ci/cd): remove redundant sections from workflows Signed-off-by: Alexey Igrychev --- .../ci_cd_workflows.md | 29 ------------------- .../ci_cd_workflows.md | 29 ------------------- 2 files changed, 58 deletions(-) diff --git a/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md b/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md index bfb26e52a5..1e667ae9cc 100644 --- a/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md +++ b/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md @@ -208,32 +208,3 @@ Deleting the review environment: - The pipeline to deactivate the environment is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button, an API call, or by assigning a label. - By closing or merging a PR. - Automatically when the time-lo-live period since the previous deployment expires (in other words, if there is no activity in the environment). - -## Comparing building blocks for creating a workflow - -### The level of git control - -| | **Rollback via git** | **Rollback manually** | -|:---|:---|:---| -| **Deploy via git** | [Automatically deploy to production from master](#automatically-deploy-to-production-from-master);
[Automatically deploy to production using a tag](#automatically-deploy-to-production-using-a-tag);
[Automatically deploy to production from a branch](#automatically-deploy-to-production-from-a-branch);
[Automatically deploy to staging from master](#automatically-deploy-to-staging-from-master);
[Automatically deploy to production-like from a branch](#automatically-deploy-to-production-like-from-a-branch);
[Automatically deploy to review using a pull request](#automatically-deploy-to-review-using-a-pull-request);
[Automatically deploy to review from a branch using a pattern](#automatically-deploy-to-review-from-a-branch-using-a-pattern);
[Automatically deploy to review using a pull request; manual triggering (semi-automatic)](#automatically-deploy-to-review-using-a-pull-request-manual-triggering); | [Automatically deploy to production from master](#automatically-deploy-to-production-from-master);
[Automatically deploy to production using a tag](#automatically-deploy-to-production-using-a-tag);
[Automatically deploy to production from a branch](#automatically-deploy-to-production-from-a-branch);
[Automatically deploy to staging from master](#automatically-deploy-to-staging-from-master);
[Automatically deploy to production-like from a branch](#automatically-deploy-to-production-like-from-a-branch);
[Automatically deploy to review using a pull request](#automatically-deploy-to-review-using-a-pull-request);
[Automatically deploy to review from a branch using a pattern](#automatically-deploy-to-review-from-a-branch-using-a-pattern);
[Automatically deploy to review using a pull request; manual triggering (semi-automatic)](#automatically-deploy-to-review-using-a-pull-request-manual-triggering); | -| **Deploy manually** | [Automatically deploy to review using a pull request; manual triggering (semi-automatic)](#automatically-deploy-to-review-using-a-pull-request-manual-triggering); | [Deploy to production from master at the click of a button](#deploy-to-production-from-master-at-the-click-of-a-button);
[Deploy to production using a tag at the click of a button](#deploy-to-production-using-a-tag-at-the-click-of-a-button);
[Deploy to production from a branch at the click of a button](#deploy-to-production-from-a-branch-at-the-click-of-a-button);
[Deploy to production-like using a pull request at the click of a button](#deploy-to-production-like-using-a-pull-request-at-the-click-of-a-button);
[Deploy to review using a pull request at the click of a button](#deploy-to-review-using-a-pull-request-at-the-click-of-a-button);
[Automatically deploy to review using a pull request; manual triggering (semi-automatic)](#automatically-deploy-to-review-using-a-pull-request-manual-triggering); | - -### Does the building block meet the criteria for CI/CD? - -| | **True CI/CD** | **Recommended for werf** | -|:---|:---:|:---:| -| [**Automatically deploy to production from master**](#automatically-deploy-to-production-from-master) | yes | yes | -| [**Deploy to production from master at the click of a button**](#deploy-to-production-from-master-at-the-click-of-a-button) | no | no | -| [**Automatically deploy to production using a tag**](#automatically-deploy-to-production-using-a-tag) | no | yes | -| [**Deploy to production using a tag at the click of a button**](#deploy-to-production-using-a-tag-at-the-click-of-a-button) | no | yes | -| [**Automatically deploy to production from a branch**](#automatically-deploy-to-production-from-a-branch) | yes | no | -| [**Deploy to production from a branch at the click of a button**](#deploy-to-production-from-a-branch-at-the-click-of-a-button) | no | no | -| [**Deploy to production-like using a pull request at the click of a button**](#deploy-to-production-like-using-a-pull-request-at-the-click-of-a-button) | no | yes | -| [**Automatically deploy to staging from master**](#automatically-deploy-to-staging-from-master) | yes | yes | -| [**Deploy to staging from master at the click of a button**](#deploy-to-staging-from-master-at-the-click-of-a-button) | no | no | -| [**Automatically deploy to production-like from a branch**](#automatically-deploy-to-production-like-from-a-branch) | yes | no | -| [**Deploy to production-like from a branch at the click of a button**](#deploy-to-production-like-from-a-branch-at-the-click-of-a-button) | no | no | -| [**Automatically deploy to review using a pull request**](#automatically-deploy-to-review-using-a-pull-request) | yes | no | -| [**Automatically deploy to review from a branch using a pattern**](#automatically-deploy-to-review-from-a-branch-using-a-pattern) | yes | no | -| [**Deploy to review using a pull request at the click of a button**](#deploy-to-review-using-a-pull-request-at-the-click-of-a-button) | no | no | -| [**Automatically deploy to review using a pull request; manual triggering**](#automatically-deploy-to-review-using-a-pull-request-manual-triggering) | yes | yes | diff --git a/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md b/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md index 047ae1798c..f83130fe9b 100644 --- a/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md +++ b/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md @@ -208,32 +208,3 @@ Pipeline выката в review-окружение может быть запу - Запуск pipeline для деактивации review окружения средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе, снять ранее повешенный label или вызов API. - По закрытию или принятию PR. - Автоматически по истечению time-to-live с последнего выката на данное окружение (другими словами, при отсутствии активности в данном окружении). - -## Сравнение составляющих блоков для построения workflow - -### Степень управляемости через git - -| | **Откат через git** | **Ручной откат** | -|:---|:---|:---| -| **Выкат через git** | [Выкат на production из master автоматически](#выкат-на-production-из-master-автоматически);
[Выкат на production из тега автоматически](#выкат-на-production-из-тега-автоматически);
[Выкат на production из ветки автоматически](#выкат-на-production-из-ветки-автоматически);
[Выкат на staging из master автоматически](#выкат-на-staging-из-master-автоматически);
[Выкат на production-like из ветки автоматически](#выкат-на-production-like-из-ветки-автоматически);
[Выкат на review из pull request автоматически](#выкат-на-review-из-pull-request-автоматически);
[Выкат на review из ветки по шаблону автоматически](#выкат-на-review-из-ветки-по-шаблону-автоматически);
[Выкат на review из pull request автоматически после ручной активации (полуавтоматический)](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации); | [Выкат на production из master автоматически](#выкат-на-production-из-master-автоматически);
[Выкат на production из тега автоматически](#выкат-на-production-из-тега-автоматически);
[Выкат на production из ветки автоматически](#выкат-на-production-из-ветки-автоматически);
[Выкат на staging из master автоматически](#выкат-на-staging-из-master-автоматически);
[Выкат на production-like из ветки автоматически](#выкат-на-production-like-из-ветки-автоматически);
[Выкат на review из pull request автоматически](#выкат-на-review-из-pull-request-автоматически);
[Выкат на review из ветки по шаблону автоматически](#выкат-на-review-из-ветки-по-шаблону-автоматически);
[Выкат на review из pull request автоматически после ручной активации (полуавтоматический)](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации); | -| **Ручной выкат** | [Выкат на review из pull request автоматически после ручной активации (полуавтоматический)](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации); | [Выкат на production из master по кнопке](#выкат-на-production-из-master-по-кнопке);
[Выкат на production из тега по кнопке](#выкат-на-production-из-тега-по-кнопке);
[Выкат на production из ветки по кнопке](#выкат-на-production-из-ветки-по-кнопке);
[Выкат на production-like из pull request по кнопке](#выкат-на-production-like-из-pull-request-по-кнопке);
[Выкат на review из pull request по кнопке](#выкат-на-review-из-pull-request-по-кнопке);
[Выкат на review из pull request автоматически после ручной активации (полуавтоматический)](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации); | - -### Соответствие CI/CD - -| | **True CI/CD** | **Рекомендовано для werf** | -|:---|:---:|:---:| -| [**Выкат на production из master автоматически**](#выкат-на-production-из-master-автоматически) | да | да | -| [**Выкат на production из master по кнопке**](#выкат-на-production-из-master-по-кнопке) | нет | нет | -| [**Выкат на production из тега автоматически**](#выкат-на-production-из-тега-автоматически) | нет | да | -| [**Выкат на production из тега по кнопке**](#выкат-на-production-из-тега-по-кнопке) | нет | да | -| [**Выкат на production из ветки автоматически**](#выкат-на-production-из-ветки-автоматически) | да | нет | -| [**Выкат на production из ветки по кнопке**](#выкат-на-production-из-ветки-по-кнопке) | нет | нет | -| [**Выкат на production-like из pull request по кнопке**](#выкат-на-production-like-из-pull-request-по-кнопке) | нет | да | -| [**Выкат на staging из master автоматически**](#выкат-на-staging-из-master-автоматически) | да | да | -| [**Выкат на staging из master по кнопке**](#выкат-на-staging-из-master-по-кнопке) | нет | нет | -| [**Выкат на production-like из ветки автоматически**](#выкат-на-production-like-из-ветки-автоматически) | да | нет | -| [**Выкат на production-like из ветки по кнопке**](#выкат-на-production-like-из-ветки-по-кнопке) | нет | нет | -| [**Выкат на review из pull request автоматически**](#выкат-на-review-из-pull-request-автоматически) | да | нет | -| [**Выкат на review из ветки по шаблону автоматически**](#выкат-на-review-из-ветки-по-шаблону-автоматически) | да | нет | -| [**Выкат на review из pull request по кнопке**](#выкат-на-review-из-pull-request-по-кнопке) | нет | нет | -| [**Выкат на review из pull request автоматически после ручной активации**](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации) | да | да | From 84e274686499d7e07d4c871c7c6afcd1ede9adaa Mon Sep 17 00:00:00 2001 From: Alexey Igrychev Date: Fri, 16 Dec 2022 13:20:01 +0000 Subject: [PATCH 4/7] docs(ci/cd): restructure workflows article Signed-off-by: Alexey Igrychev --- .../ci_cd_workflows.md | 156 ++++++++++-------- .../ci_cd_workflows.md | 151 +++++++++-------- 2 files changed, 171 insertions(+), 136 deletions(-) diff --git a/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md b/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md index 1e667ae9cc..f39dd6fd12 100644 --- a/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md +++ b/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md @@ -15,30 +15,30 @@ We recommend this configuration as the most consistent with the principles of CI This configuration supports any number of production-like environments, such as testing, staging, development, qa, and so on. -| **Environment** | **The workflow block** | -| :--- | :--- | -| Production | [Automatically deploy to production from master](#automatically-deploy-to-production-from-master) + rollback changes via revert | +| **Environment** | **The workflow block** | +|:-------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------| +| Production | [Automatically deploy to production from master](#automatically-deploy-to-production-from-master) + rollback changes via revert | | Staging / Testing / Development / QA | [Deploy to production-like using a pull request at the click of a button](#deploy-to-production-like-using-a-pull-request-at-the-click-of-a-button) | -| Review | [Automatically deploy to review using a pull request; manual triggering](#automatically-deploy-to-review-using-a-pull-request-manual-triggering) | +| Review | [Automatically deploy to review using a pull request; manual triggering](#automatically-deploy-to-review-using-a-pull-request-manual-triggering) | ### №2 Push the button -| **Environment** | **The workflow block** | -| :--- | :--- | -| Production | [Deploy to production from master at the click of a button](#deploy-to-production-from-master-at-the-click-of-a-button) | -| Staging | [Automatically deploy to staging from master](#automatically-deploy-to-staging-from-master) | -| Testing / Development / QA | [Automatically deploy to production-like from a branch](#automatically-deploy-to-production-like-from-a-branch) | -| Review | [Deploy to review using a pull request at the click of a button](#deploy-to-review-using-a-pull-request-at-the-click-of-a-button) | +| **Environment** | **The workflow block** | +|:---------------------------|:----------------------------------------------------------------------------------------------------------------------------------| +| Production | [Deploy to production from master at the click of a button](#deploy-to-production-from-master-at-the-click-of-a-button) | +| Staging | [Automatically deploy to staging from master](#automatically-deploy-to-staging-from-master) | +| Testing / Development / QA | [Automatically deploy to production-like from a branch](#automatically-deploy-to-production-like-from-a-branch) | +| Review | [Deploy to review using a pull request at the click of a button](#deploy-to-review-using-a-pull-request-at-the-click-of-a-button) | ### №3 Tag everything Not all projects are ready to implement the CI/CD approach. These projects use the more classical approach, that implies making releases after the active development phase is complete. The transition to the CI/CD approach in such projects requires both developers and DevOps engineers to change personal habits and rethink the workflow. Therefore, for such projects, we also offer a classic configuration. We recommend to use it with werf if [fast & furious](#1-fast-and-furious) does not suit you. -| **Environment** | **The workflow block** | -| :--- | :--- | -| Production | [Automatically deploy to production using a tag](#automatically-deploy-to-production-using-a-tag) | -| Staging | [Automatically deploy to staging from master or Deploy to staging from master at the click of a button](#automatically-deploy-to-staging-from-master) | -| Review | [Automatically deploy to review using a pull request; manual triggering](#automatically-deploy-to-review-using-a-pull-request-manual-triggering) | +| **Environment** | **The workflow block** | +|:----------------|:------------------------------------------------------------------------------------------------------------------------------------------------------| +| Production | [Automatically deploy to production using a tag](#automatically-deploy-to-production-using-a-tag) | +| Staging | [Automatically deploy to staging from master or Deploy to staging from master at the click of a button](#automatically-deploy-to-staging-from-master) | +| Review | [Automatically deploy to review using a pull request; manual triggering](#automatically-deploy-to-review-using-a-pull-request-manual-triggering) | ### №4 Branch, branch, branch @@ -46,11 +46,11 @@ Directly manage the deployment process via git by using branches and git merge, We recommend this configuration for those who would like to manage the CI/CD process via git only. Note that this approach is also consistent with the CI/CD principles (just like the fast & furious approach described above). -| **Environment** | **The workflow block** | -| :--- | :--- | -| Production | [Automatically deploy to production from master](#automatically-deploy-to-production-from-master) + rollback changes via revert | -| Staging | [Automatically deploy to staging from master](#automatically-deploy-to-staging-from-master) | -| Review | [Automatically deploy to review from a branch using a pattern](#automatically-deploy-to-review-from-a-branch-using-a-pattern) | +| **Environment** | **The workflow block** | +|:----------------|:--------------------------------------------------------------------------------------------------------------------------------| +| Production | [Automatically deploy to production from master](#automatically-deploy-to-production-from-master) + rollback changes via revert | +| Staging | [Automatically deploy to staging from master](#automatically-deploy-to-staging-from-master) | +| Review | [Automatically deploy to review from a branch using a pattern](#automatically-deploy-to-review-from-a-branch-using-a-pattern) | ## Workflow components for various environments @@ -58,7 +58,11 @@ Next, we will discuss various options for rolling out to production and other en Review environments are created and deleted dynamically as per the developers' request. Thus, there are some specificities when deploying code to these environments. In the review-related sections, we will describe how to create as well as delete a review environment. -### Automatically deploy to production from master +### Deploy to production environment + +#### From master branch + +##### Automatically A merge request or a commit to the master branch triggers the pipeline to deploy directly to production. @@ -68,7 +72,7 @@ Rollback options: - Recommended: rollback via reverting the commit in the master branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. - By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). -### Deploy to production from master at the click of a button +##### At the click of a button You can manually run a pipeline to deploy to production for a commit in the master branch only. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. @@ -76,24 +80,11 @@ Rollback options: - Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). - By reverting a commit in the master branch and then [manually](#run-a-pipeline-manually) run the pipeline using the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the master is not consistent with the state of the environment at all times (as opposed to the automatic deployment). Thus, it does not make sense to revert exclusively for the rollback. -### Automatically deploy to production using a tag - -Creating a new tag automatically triggers the pipeline to deploy the code to the production environment on the basis of the commit associated with this tag. - -Rollback options: -- Recommended: by means of CI/CD system; [re-run the pipeline manually](#run-a-pipeline-manually) using the old tag. -- By creating a new tag linked to the old commit; the pipeline will be run automatically for the new tag. It is not the best option since it leads to the generation of unnecessary tags. - -### Deploy to production using a tag at the click of a button +#### From a specific branch -The pipeline to deploy to the production environment can only be triggered using the existing tag in git. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. - -Rollback options: -- By means of the CI/CD system; [re-run the pipeline manually](#run-a-pipeline-manually) using the old tag. - -### Automatically deploy to production from a branch +##### Automatically -A merge request or a commit to the specific branch triggers the pipeline to deploy to production (this option is similar to the (master-automatically) (#master-automatically), but involves a separate branch). +A merge request or a commit to the specific branch triggers the pipeline to deploy to production (this option is similar to the [master-automatically](#master-automatically), but involves a separate branch). The state of the specific branch is consistent with the state of the environment at any given time. Therefore, this option complies with the true CI/CD approach. @@ -103,7 +94,7 @@ Rollback options: - By reverting the commit in the master, then fast-forwarding merge to the specific branch. - By deleting the commit in the specific branch (delete the commit in git and then use the git push-force procedure). -### Deploy to production from a branch at the click of a button +##### At the click of a button Manually run a pipeline to deploy to production for a commit to the specific branch only. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. @@ -111,34 +102,39 @@ Rollback options: - Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). - By reverting the commit in the specific branch and then [manually](#run-a-pipeline-manually) run the pipeline using the means of the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the master is not consistent with the state of the environment at all times (as opposed to the automatic deployment). Thus, it does not make sense to revert exclusively for the rollback. -### Deploy to production-like using a pull request at the click of a button +#### From tag -The pipeline to deploy to production can be run on any commit to the pull request. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. +##### Automatically -Rollback options: -- By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +Creating a new tag automatically triggers the pipeline to deploy the code to the production environment on the basis of the commit associated with this tag. -### Automatically deploy to staging from master +Rollback options: +- Recommended: by means of CI/CD system; [re-run the pipeline manually](#run-a-pipeline-manually) using the old tag. +- By creating a new tag linked to the old commit; the pipeline will be run automatically for the new tag. It is not the best option since it leads to the generation of unnecessary tags. -A merge request or a commit to the master branch triggers the pipeline to deploy directly to the staging environment. +##### At the click of a button -The state of the branch reflects the state of the environment at any given time. Therefore, this option complies with the true CI/CD approach. +The pipeline to deploy to the production environment can only be triggered using the existing tag in git. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. Rollback options: -- Recommended: rollback via reverting the commit in the master branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. -- By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- By means of the CI/CD system; [re-run the pipeline manually](#run-a-pipeline-manually) using the old tag. -### Deploy to staging from master at the click of a button +### Deploy to production-like environment -The pipeline to deploy to staging can only be [run manually](#run-a-pipeline-manually) on a commit from the master branch. The pipeline is triggered manually using the CI/CD system's tools, such as a dedicated button or an API call. +#### From pull request + +##### At the click of a button + +The pipeline to deploy to production can be run on any commit to the pull request. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. Rollback options: -- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). -- Revert the commit in the master branch and then [manually](#run-a-pipeline-manually) run the pipeline using the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the master does not consistent with the state of the environment at all times (as opposed to the automatic deployment from master to staging). Thus, it does not make sense to revert exclusively for the rollback. +- By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). -### Automatically deploy to production-like from a branch +#### From a specific branch -A merge request or a commit to the specific branch triggers the pipeline to deploy to the production-like environment (this option is similar to (master-automatically) (#master-automatically), but involves a separate branch). A separate branch is used for each specific production-like environment, such as staging or testing. +##### Automatically + +A merge request or a commit to the specific branch triggers the pipeline to deploy to the production-like environment (this option is similar to [master-automatically](#master-automatically), but involves a separate branch). A separate branch is used for each specific production-like environment, such as staging or testing. The state of the specific branch is consistent with the state of the environment at any given time. Therefore, this option complies with the true CI/CD approach. @@ -148,7 +144,17 @@ Rollback options: - Revert the commit in the master, then fast-forward merge to the specific branch. - Delete the commit in the specific branch (by deleting the commit in git and then using the git push-force procedure). -### Deploy to production-like from a branch at the click of a button +###### Example workflow for staging environment + +A merge request or a commit to the master branch triggers the pipeline to deploy directly to the staging environment. + +The state of the branch reflects the state of the environment at any given time. Therefore, this option complies with the true CI/CD approach. + +Rollback options: +- Recommended: rollback via reverting the commit in the master branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. +- By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). + +##### At the click of a button Manually run a pipeline to deploy to the production-like environment for a commit to the specific branch only. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. @@ -156,21 +162,19 @@ Rollback options: - Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). - Revert the commit in the specific branch and then [manually](#run-a-pipeline-manually) run the pipeline using the means of the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the branch is not consistent with the state of the environment at all times (as opposed to the automatic deployment to the production-like environment). Thus, it does not make sense to revert exclusively for the purposes of a rollback. -### Automatically deploy to review using a pull request +###### Example workflow for staging environment -Further commits to the branch tied to the pull request automatically trigger roll-outs to the review environment. +The pipeline to deploy to staging can only be [run manually](#run-a-pipeline-manually) on a commit from the master branch. The pipeline is triggered manually using the CI/CD system's tools, such as a dedicated button or an API call. Rollback options: -- Recommended: rollback via reverting the commit in the branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. -- By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- Revert the commit in the master branch and then [manually](#run-a-pipeline-manually) run the pipeline using the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the master does not consistent with the state of the environment at all times (as opposed to the automatic deployment from master to staging). Thus, it does not make sense to revert exclusively for the rollback. -Deleting the review environment: -- By closing or merging a PR. -- Automatically when the time-lo-live period since the last deployment expires (in other words, if there is no activity in the environment). +### Deploy to review environment -### Automatically deploy to review from a branch using a pattern +#### From a specific branch (using a pattern) -Creating a pull request for a branch that matches some specific pattern automatically triggers a roll-out to a separate review environment. The name of this environment is associated with the name of the branch. Further commits to the branch associated with the pull request automatically trigger a roll-out to the review environment. +Creating a pull request for a branch that matches some specific pattern automatically triggers a roll-out to a separate review environment. The name of this environment is associated with the name of the branch. Further commits to the branch associated with the pull request automatically trigger a roll-out to the review environment. For example, if you have a `review_*` pattern, then the creation of a pull request for the branch called `review_myfeature1` would automatically lead to the creation of the corresponding review-environment. @@ -182,19 +186,21 @@ Deleting the review environment: - By closing or merging a PR. - Automatically when the time-lo-live period since the last deployment expires (in other words, if there is no activity in the environment). -### Deploy to review using a pull request at the click of a button +#### From pull request -The pipeline to deploy to the review environment can only be run manually on a commit from the branch tied to this environment. The name of this environment is associated with the name of the branch. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button, an API call, or by assigning a label. +##### Automatically + +Further commits to the branch tied to the pull request automatically trigger roll-outs to the review environment. Rollback options: -- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). -- Revert the commit in the specific branch and then [manually](#run-a-pipeline-manually) run the pipeline using the means of the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the branch does not always correspond to the state of the environment (in contrast to "deploy automatically using the pull request" and "deploy automatically using the pull request and a pattern"), so it does not make sense to perform a revert solely for the rollback. +- Recommended: rollback via reverting the commit in the branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. +- By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). Deleting the review environment: - By closing or merging a PR. - Automatically when the time-lo-live period since the last deployment expires (in other words, if there is no activity in the environment). -### Automatically deploy to review using a pull request; manual triggering +##### Automatically with manual triggering The review environment is created for the pull request after the pipeline is manually run by the means of the CI/CD system. From this point on, any commit to the branch tied to the pull request leads to an automatic roll-out to the review environment. After the work is complete, you can deactivate the review environment manually using the CI/CD system. @@ -208,3 +214,15 @@ Deleting the review environment: - The pipeline to deactivate the environment is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button, an API call, or by assigning a label. - By closing or merging a PR. - Automatically when the time-lo-live period since the previous deployment expires (in other words, if there is no activity in the environment). + +##### At the click of a button + +The pipeline to deploy to the review environment can only be run manually on a commit from the branch tied to this environment. The name of this environment is associated with the name of the branch. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button, an API call, or by assigning a label. + +Rollback options: +- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- Revert the commit in the specific branch and then [manually](#run-a-pipeline-manually) run the pipeline using the means of the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the branch does not always correspond to the state of the environment (in contrast to "deploy automatically using the pull request" and "deploy automatically using the pull request and a pattern"), so it does not make sense to perform a revert solely for the rollback. + +Deleting the review environment: +- By closing or merging a PR. +- Automatically when the time-lo-live period since the last deployment expires (in other words, if there is no activity in the environment). diff --git a/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md b/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md index f83130fe9b..8212a533ca 100644 --- a/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md +++ b/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md @@ -15,30 +15,30 @@ permalink: usage/integration_with_ci_cd_systems/ci_cd_workflows.html В данной конфигурации может быть произвольное число production-like окружений, как то: testing, staging, development, qa, и т.д. -| **Окружение** | **Блок workflow** | -| :--- | :--- | -| Production | [Выкат на production из master автоматически](#выкат-на-production-из-master-автоматически) + откат через revert | -| Staging / Testing / Development / QA | [Выкат на production-like из pull request по кнопке](#выкат-на-production-like-из-pull-request-по-кнопке) | -| Review | [Выкат на review из pull request автоматически после ручной активации](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации) | +| **Окружение** | **Блок рабочего процесса** | +|:-------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------| +| Production | [Выкат на production из master автоматически](#выкат-на-production-из-master-автоматически) + откат через revert | +| Staging / Testing / Development / QA | [Выкат на production-like из pull request по кнопке](#выкат-на-production-like-из-pull-request-по-кнопке) | +| Review | [Выкат на review из pull request автоматически после ручной активации](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации) | ### №2 Push the button -| **Окружение** | **Блок workflow** | -| :--- | :--- | -| Production | [Выкат на production из master по кнопке](#выкат-на-production-из-master-по-кнопке) | -| Staging | [Выкат на staging из master автоматически](#выкат-на-staging-из-master-автоматически) | +| **Окружение** | **Блок рабочего процесса** | +|:---------------------------|:----------------------------------------------------------------------------------------------------| +| Production | [Выкат на production из master по кнопке](#выкат-на-production-из-master-по-кнопке) | +| Staging | [Выкат на staging из master автоматически](#выкат-на-staging-из-master-автоматически) | | Testing / Development / QA | [Выкат на production-like из ветки автоматически](#выкат-на-production-like-из-ветки-автоматически) | -| Review | [Выкат на review из pull request по кнопке](#выкат-на-review-из-pull-request-по-кнопке) | +| Review | [Выкат на review из pull request по кнопке](#выкат-на-review-из-pull-request-по-кнопке) | ### №3 Tag everything Не все проекты сходу готовы к внедрению CI/CD. В таких проектах используется более классический метод создания релизов только после активной фазы разработки. Переход к CI/CD в таких проектах требует усилий по преодолению привычных вещей и переосмысления как от разработчиков, так и от devops. Поэтому для таких проектов мы предлагаем и классическую конфигурацию, которая также рекомендована для werf в случае невозможности использования [fast & furious](#1-fast-and-furious). -| **Окружение** | **Блок workflow** | -| :--- | :--- | -| Production | [Выкат на production из тега автоматически](#выкат-на-production-из-тега-автоматически) | -| Staging | [Выкат на staging из master автоматически](#выкат-на-staging-из-master-автоматически) или [выкат на staging из master по кнопке](#выкат-на-staging-из-master-по-кнопке) | -| Review | [Выкат на review из pull request автоматически после ручной активации](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации) | +| **Окружение** | **Блок рабочего процесса** | +|:--------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Production | [Выкат на production из тега автоматически](#выкат-на-production-из-тега-автоматически) | +| Staging | [Выкат на staging из master автоматически](#выкат-на-staging-из-master-автоматически) или [выкат на staging из master по кнопке](#выкат-на-staging-из-master-по-кнопке) | +| Review | [Выкат на review из pull request автоматически после ручной активации](#выкат-на-review-из-pull-request-автоматически-после-ручной-активации) | ### №4 Branch, branch, branch @@ -46,19 +46,19 @@ permalink: usage/integration_with_ci_cd_systems/ci_cd_workflows.html Рекомендуем для тех, кто хочет управлять CI/CD полностью из git. Отметим, что подход также является соответствующим канонам CI/CD, как и fast & furious. -| **Окружение** | **Блок workflow** | -| :--- | :--- | -| Production | [Выкат на production из master автоматически](#выкат-на-production-из-master-автоматически) + откат через revert | -| Staging | [Выкат на staging из master автоматически](#выкат-на-staging-из-master-автоматически) | -| Review | [Выкат на review из ветки по шаблону автоматически](#выкат-на-review-из-ветки-по-шаблону-автоматически) | +| **Окружение** | **Блок рабочего процесса** | +|:--------------|:-----------------------------------------------------------------------------------------------------------------| +| Production | [Выкат на production из master автоматически](#выкат-на-production-из-master-автоматически) + откат через revert | +| Staging | [Выкат на staging из master автоматически](#выкат-на-staging-из-master-автоматически) | +| Review | [Выкат на review из ветки по шаблону автоматически](#выкат-на-review-из-ветки-по-шаблону-автоматически) | -## Составляющие workflow для отдельных окружений +## Варианты организации выката для различных окружений -Далее рассмотрим различные варианты выката production и других окружений в связке с git. Каждый пункт определяет строительный блок, который можно использовать для работы с определённым окружением. Мы будем называть такой строительный блок блоком workflow. Из блоков workflow в дальнейшем можно собрать свой workflow или взять готовую конфигурацию (см. далее [готовые конфигурации workflow](#готовые-конфигурации-workflow)). +### Выкат на production -Review окружения создаются и удаляются динамически по требованию разработчиков. С этим связаны особенности выката в эти окружения. В разделах, связанных с review, будет описано не только как создать review-окружение, но и как его удалить. +#### Из master ветки -### Выкат на production из master автоматически +##### Автоматически Merge или коммит в ветку master вызывает pipeline выката непосредственно на production. @@ -68,7 +68,7 @@ Merge или коммит в ветку master вызывает pipeline вык - Рекомендованный: откат через реверт коммита в ветке master. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. - Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). -### Выкат на production из master по кнопке +##### По кнопке Pipeline выката в production может быть запущен вручную только на коммите из ветки master. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. @@ -76,24 +76,11 @@ Pipeline выката в production может быть запущен вруч - Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). - Реверт коммита в ветке master, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта master-автоматом), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. -### Выкат на production из тега автоматически +#### Из произвольной ветки -Создание нового тега автоматически вызывает pipeline выката на production-окружение из коммита, связанного с этим тегом. - -Варианты отката: -- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом теге. -- Создание нового тега на старый коммит, далее автоматический вызов pipeline выката для нового тега. Не предпочтительный вариант, т.к. плодятся лишние теги. - -### Выкат на production из тега по кнопке - -Pipeline выката в production-окружение может быть вызван только на существующем теге в git. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. +##### Автоматически -Варианты отката: -- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом теге. - -### Выкат на production из ветки автоматически - -Merge или коммит в специальную ветку вызывает pipeline выката непосредственно на production (вариант похож на (master-автоматически)(#master-автоматически), но используется отдельная ветка). +Merge или коммит в специальную ветку вызывает pipeline выката непосредственно на production (вариант похож на [master-автоматически](#master-автоматически), но используется отдельная ветка). Состояние специальной ветки в любой момент времени отражает состояние окружения. Поэтому данный вариант является соответствующим подходу true CI/CD. @@ -103,7 +90,7 @@ Merge или коммит в специальную ветку вызывает - Реверт коммита в master, затем fast-forward merge в специальную ветку. - Удаление коммита в специальной ветке (через удаление коммита в git, затем процедура git push-force). -### Выкат на production из ветки по кнопке +##### По кнопке Pipeline выката в production может быть запущен вручную только на коммите из специальной ветки. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. @@ -111,34 +98,39 @@ Pipeline выката в production может быть запущен вруч - Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). - Реверт коммита в ветке, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта master-автоматом), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. -### Выкат на production-like из pull request по кнопке +#### Из тега -Pipeline выката в production может быть запущен на любом коммите в pull request. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. +##### Автоматически -Варианты отката: -- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +Создание нового тега автоматически вызывает pipeline выката на production-окружение из коммита, связанного с этим тегом. -### Выкат на staging из master автоматически +Варианты отката: +- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом теге. +- Создание нового тега на старый коммит, далее автоматический вызов pipeline выката для нового тега. Не предпочтительный вариант, т.к. плодятся лишние теги. -Merge или коммит в ветку master вызывает pipeline выката непосредственно на staging окружение. +##### По кнопке -Состояние ветки в любой момент времени отражает состояние окружения. Поэтому данный вариант является соответствующим подходу true CI/CD. +Pipeline выката в production-окружение может быть вызван только на существующем теге в git. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. Варианты отката: -- Рекомендованный: откат через реверт коммита в ветке master. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. -- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом теге. -### Выкат на staging из master по кнопке +### Выкат на production-like -Pipeline выката в staging может быть запущен вручную только на коммите из ветки master. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. +#### Из pull request + +##### По кнопке + +Pipeline выката в production может быть запущен на любом коммите в pull request. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. Варианты отката: -- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). -- Реверт коммита в ветке master, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта Выкат на staging из master автоматически), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. +- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). -### Выкат на production-like из ветки автоматически +#### Из ветки -Merge или коммит в специальную ветку вызывает pipeline выката непосредственно на production-like окружение (вариант похож на (master-автоматически)(#master-автоматически), но используется отдельная ветка). Для каждого конкретного production-like окружения, как то: staging или testing — используется отдельная ветка. +##### Автоматически + +Merge или коммит в специальную ветку вызывает pipeline выката непосредственно на production-like окружение (вариант похож на [master-автоматически](#master-автоматически), но используется отдельная ветка). Для каждого конкретного production-like окружения, как то: staging или testing — используется отдельная ветка. Состояние специальной ветки в любой момент времени отражает состояние окружения. Поэтому данный вариант является соответствующим подходу true CI/CD. @@ -148,7 +140,17 @@ Merge или коммит в специальную ветку вызывает - Реверт коммита в master, затем fast-forward merge в специальную ветку. - Удаление коммита в специальной ветке (через удаление коммита в git, затем процедура git push-force). -### Выкат на production-like из ветки по кнопке +###### Пример рабочего процесса для staging + +Merge или коммит в ветку master вызывает pipeline выката непосредственно на staging окружение. + +Состояние ветки в любой момент времени отражает состояние окружения. Поэтому данный вариант является соответствующим подходу true CI/CD. + +Варианты отката: +- Рекомендованный: откат через реверт коммита в ветке master. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. +- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). + +##### По кнопке Pipeline выката в production-like окружение может быть запущен вручную только на коммите из специальной ветки. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. @@ -156,7 +158,19 @@ Pipeline выката в production-like окружение может быть - Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). - Реверт коммита в ветке, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние ветки не всегда соответствует состоянию окружения (в отличие от варианта Выкат на production-like из ветки автоматически), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. -### Выкат на review из pull request автоматически +###### Пример рабочего процесса для staging + +Pipeline выката в staging может быть запущен вручную только на коммите из ветки master. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. + +Варианты отката: +- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Реверт коммита в ветке master, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта Выкат на staging из master автоматически), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. + +### Выкат на review + +#### Из pull request + +##### Автоматически Создание pull request автоматически вызывает выкат в отдельное review окружение. Название этого окружения связано с именем ветки. Дальнейшие коммиты в ветку, связанную с pull request автоматически вызывают выкат в review окружение. @@ -168,21 +182,22 @@ Pipeline выката в production-like окружение может быть - По закрытию или принятию PR. - Автоматически по истечению time-to-live с последнего выката на данное окружение (другими словами, при отсутствии активности в данном окружении). -### Выкат на review из ветки по шаблону автоматически +##### Автоматически после ручной активации -Создание pull request для ветки, подходящей под определённый паттерн автоматически вызывает выкат в отдельное review окружение. Название этого окружения связано с именем ветки. Дальнейшие коммиты в ветку, связанную с pull request автоматически вызывают выкат в review окружение. +Review-окружение для pull request создаётся после его ручной активации средствами CI/CD системы. С этого момента любой коммит в ветку, связанную с pull request, вызывает автоматический выкат на review окружение. После работы с review его можно деактивировать вручную средствами CI/CD системы. -Например, для паттерна `review_*` создание pull request для ветки `review_myfeature1` вызовет автоматическое создание соответствующего review окружения. +Pipeline выката в review-окружение может быть запущен только на коммите из ветки соответствующей этому окружению. Название этого окружения связано с именем ветки. Запуск pipeline для активации review окружения производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе, повесить label или вызов API. Варианты отката: - Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. - Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). Удаление review-окружения: +- Запуск pipeline для деактивации review окружения средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе, снять ранее повешенный label или вызов API. - По закрытию или принятию PR. - Автоматически по истечению time-to-live с последнего выката на данное окружение (другими словами, при отсутствии активности в данном окружении). -### Выкат на review из pull request по кнопке +##### По кнопке Pipeline выката в review-окружение может быть запущен вручную только на коммите из ветки соответствующей этому окружению. Название этого окружения связано с именем ветки. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе, повесить label или вызов API. @@ -194,17 +209,19 @@ Pipeline выката в review-окружение может быть запу - По закрытию или принятию PR. - Автоматически по истечению time-to-live с последнего выката на данное окружение (другими словами, при отсутствии активности в данном окружении). -### Выкат на review из pull request автоматически после ручной активации +#### Из ветки -Review-окружение для pull request создаётся после его ручной активации средствами CI/CD системы. С этого момента любой коммит в ветку, связанную с pull request, вызывает автоматический выкат на review окружение. После работы с review его можно деактивировать вручную средствами CI/CD системы. +##### Автоматически -Pipeline выката в review-окружение может быть запущен только на коммите из ветки соответствующей этому окружению. Название этого окружения связано с именем ветки. Запуск pipeline для активации review окружения производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе, повесить label или вызов API. +Создание pull request для ветки, подходящей под определённый паттерн автоматически вызывает выкат в отдельное review окружение. Название этого окружения связано с именем ветки. Дальнейшие коммиты в ветку, связанную с pull request автоматически вызывают выкат в review окружение. + +Например, для паттерна `review_*` создание pull request для ветки `review_myfeature1` вызовет автоматическое создание соответствующего review окружения. Варианты отката: - Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. - Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). Удаление review-окружения: -- Запуск pipeline для деактивации review окружения средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе, снять ранее повешенный label или вызов API. - По закрытию или принятию PR. - Автоматически по истечению time-to-live с последнего выката на данное окружение (другими словами, при отсутствии активности в данном окружении). + From ad636a20a211b66b52d535aa0ad9d97ead2bbef7 Mon Sep 17 00:00:00 2001 From: Alexey Igrychev Date: Fri, 16 Dec 2022 13:51:53 +0000 Subject: [PATCH 5/7] docs(ci/cd): add overview to workflows article Signed-off-by: Alexey Igrychev --- .../integration_with_ci_cd_systems/ci_cd_workflows.md | 7 ++++--- .../integration_with_ci_cd_systems/ci_cd_workflows.md | 7 ++++--- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md b/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md index f39dd6fd12..9980f9d49a 100644 --- a/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md +++ b/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md @@ -3,11 +3,12 @@ title: CI/CD workflows permalink: usage/integration_with_ci_cd_systems/ci_cd_workflows.html --- -## Ready-made workflow configurations +This article proposes several strategies for the whole workflow, and also discusses rollout options to different environments individually. The workflows are discussed on a principle level without reference to the CI/CD system, while the actual configuration can be found in the instructions: -In this section, we offer the user the selection of ready-made workflow configurations tailored to various use cases. These configurations are made up of the workflow blocks listed above. In the documentation, these ready-made configurations can also be referred to as workflow strategies. +- [GitLab CI/CD]({{ "/how_to/integration_with_ci_cd_systems/gitlab_ci_cd/workflows.html" | true_relative_url }}). +- [GitHub Actions]({{ "/how_to/integration_with_ci_cd_systems/github_actions/workflows.html" | true_relative_url }}). -The exact configuration for each type of the CI/CD system you can find in the documentation for that system. For example, GitLab CI/CD: link, GitHub Actions: link. +## Ready-made workflow configurations ### №1 Fast and Furious diff --git a/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md b/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md index 8212a533ca..9fd52f4071 100644 --- a/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md +++ b/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md @@ -3,11 +3,12 @@ title: Рабочие процессы CI/CD permalink: usage/integration_with_ci_cd_systems/ci_cd_workflows.html --- -## Готовые конфигурации workflow +В этой статье предлагается несколько стратегий всего рабочего процесса, а также рассматриваются варианты выката в различные окружения по отдельности. Рабочие процессы рассматриваются на принципиальном уровне без привязки к CI/CD-системе, а непосредственно конфигурацию можно найти в инструкциях: -Мы предлагаем пользователю на выбор несколько готовых конфигураций workflow для проекта. Эти конфигурации составлены из приведенных выше блоков workflow. В документации эти готовые конфигурации могут называться также стратегиями workflow. +- [GitLab CI/CD]({{ "/how_to/integration_with_ci_cd_systems/gitlab_ci_cd/workflows.html" | true_relative_url }}). +- [GitHub Actions]({{ "/how_to/integration_with_ci_cd_systems/github_actions/workflows.html" | true_relative_url }}). -Конкретные конфиги по каждой из конфигураций можно найти в инструкциях по конкретной CI/CD системе. Например, Gitlab CI: ссылка, Github Actions: ссылка. +## Готовые конфигурации рабочего процесса ### №1 Fast and Furious From dd4023ca271345717cbce99bbdaf1cbbf0bc5e42 Mon Sep 17 00:00:00 2001 From: Alexey Igrychev Date: Fri, 16 Dec 2022 14:00:32 +0000 Subject: [PATCH 6/7] docs(ci/cd): update links Signed-off-by: Alexey Igrychev --- .../github_actions/workflows.md | 22 ++--- .../gitlab_ci_cd/workflows.md | 22 ++--- .../ci_cd_workflows.md | 90 +++++++++---------- .../using_with_ci_cd_systems.md | 2 +- .../github_actions/workflows.md | 22 ++--- .../gitlab_ci_cd/workflows.md | 22 ++--- .../ci_cd_workflow_basics.md | 76 ++++++++-------- .../ci_cd_workflows.md | 86 +++++++++--------- 8 files changed, 169 insertions(+), 173 deletions(-) diff --git a/docs/pages_en/how_to/integration_with_ci_cd_systems/github_actions/workflows.md b/docs/pages_en/how_to/integration_with_ci_cd_systems/github_actions/workflows.md index ca2d6a9b88..a1a5e19a83 100644 --- a/docs/pages_en/how_to/integration_with_ci_cd_systems/github_actions/workflows.md +++ b/docs/pages_en/how_to/integration_with_ci_cd_systems/github_actions/workflows.md @@ -173,7 +173,7 @@ Now, let us explore the main strategies to deploy the review environment. #### 1. Manually -> This option implements the approach described in the [Deploy to review using a pull request at the click of a button]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#deploy-to-review-using-a-pull-request-at-the-click-of-a-button" | true_relative_url }}) section +> This option implements the approach described in the [Deploy to review using a pull request at the click of a button]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#deploy-to-review-using-a-pull-request-at-the-click-of-a-button" | true_relative_url }}) section In this approach, the user deploys and deletes the environment by assigning the appropriate label (`review_start` or `review_stop`) in the PR. @@ -217,7 +217,7 @@ labels: #### 2. Automatically using a branch name -> This option implements the approach described in the [Automatically deploy to review from a branch using a pattern]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#automatically-deploy-to-review-from-a-branch-using-a-pattern" | true_relative_url }}) section. +> This option implements the approach described in the [Automatically deploy to review from a branch using a pattern]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#automatically-deploy-to-review-from-a-branch-using-a-pattern" | true_relative_url }}) section. In the configuration below, the code is automatically released with every commit in the PR (if the name of the git branch contains the `review` prefix). @@ -241,7 +241,7 @@ on: #### 3. Semi-automatic mode using a label (recommended) -> This option implements the approach described in the [Automatically deploy to review using a pull request; manual triggering]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#automatically-deploy-to-review-using-a-pull-request-manual-triggering" | true_relative_url }}) +> This option implements the approach described in the [Automatically deploy to review using a pull request; manual triggering]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#automatically-deploy-to-review-using-a-pull-request-manual-triggering" | true_relative_url }}) Semi-automatic mode with a label is a comprehensive solution that combines the previous two options. @@ -267,7 +267,7 @@ In our case, these environments are the most important ones. Thus, the names of #### 1. Fast and Furious (recommended) -> This option implements the approaches described in the [Automatically deploy to production from master]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#automatically-deploy-to-production-from-master" | true_relative_url }}) and [Deploy to production-like using a pull request at the click of a button]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#deploy-to-production-like-using-a-pull-request-at-the-click-of-a-button" | true_relative_url }}) sections +> This option implements the approaches described in the [Automatically deploy to production from master]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#automatically-deploy-to-production-from-master" | true_relative_url }}) and [Deploy to production-like using a pull request at the click of a button]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#deploy-to-production-like-using-a-pull-request-at-the-click-of-a-button" | true_relative_url }}) sections The code is automatically deployed to **production** in response to any changes in master. At the same time, you can deploy an application to **staging** by clicking the button in the PR. @@ -280,7 +280,7 @@ Options for rolling back changes in production: #### 2. Push the button (*) -> This option implements the approaches described in the [Deploy to production from master at the click of a button]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#deploy-to-production-from-master-at-the-click-of-a-button" | true_relative_url }}) and [Automatically deploy to staging from master]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#automatically-deploy-to-staging-from-master" | true_relative_url }}) sections +> This option implements the approaches described in the [Deploy to production from master at the click of a button]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#deploy-to-production-from-master-at-the-click-of-a-button" | true_relative_url }}) and [Automatically deploy to staging from master]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#automatically-deploy-to-staging-from-master" | true_relative_url }}) sections {% include /en/how_to/integration_with_ci_cd_systems/github_actions/not_recommended_approach.md %} @@ -315,7 +315,7 @@ Options for rolling back changes in production: by rolling out a stable PR and t #### 3. Tag everything (*) -> This option implements the approaches described in the [Automatically deploy to production using a tag]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#automatically-deploy-to-production-using-a-tag" | true_relative_url }}) and [Deploy to staging from master at the click of a button]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#deploy-to-staging-from-master-at-the-click-of-a-button" | true_relative_url }}) sections +> This option implements the approaches described in the [Automatically deploy to production using a tag]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#automatically-deploy-to-production-using-a-tag" | true_relative_url }}) and [Deploy to staging from master at the click of a button]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#deploy-to-staging-from-master-at-the-click-of-a-button" | true_relative_url }}) sections {% include /en/how_to/integration_with_ci_cd_systems/github_actions/not_recommended_approach.md %} @@ -348,7 +348,7 @@ Options for rolling back changes in production: by assigning a new tag to the ol #### 4. Branch, branch, branch! -> This option implements the approaches described in the [Automatically deploy to production from a branch]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#automatically-deploy-to-production-from-a-branch" | true_relative_url }}) and [Automatically deploy to production-like from a branch]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#automatically-deploy-to-production-like-from-a-branch" | true_relative_url }}) sections +> This option implements the approaches described in the [Automatically deploy to production from a branch]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#automatically-deploy-to-production-from-a-branch" | true_relative_url }}) and [Automatically deploy to production-like from a branch]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#automatically-deploy-to-production-like-from-a-branch" | true_relative_url }}) sections The code is deployed to **production** automatically; rolling out to **staging** is performed in response to changes in the master branch. @@ -392,7 +392,7 @@ werf has an efficient built-in cleanup mechanism to avoid overflowing the contai Workflow details {:.no_toc} -> You can learn more about this workflow in the [article]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#1-fast-and-furious" | true_relative_url }}) +> You can learn more about this workflow in the [article]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#1-fast-and-furious" | true_relative_url }}) * Deploying to the review tier via the strategy [No. 3 Semi-automatic mode using a label (recommended)](#3-semi-automatic-mode-using-a-label-recommended). * Deploying to staging and production tiers via the strategy [No. 1 Fast and Furious (recommended)](#1-fast-and-furious-recommended). @@ -410,7 +410,7 @@ Workflow details Workflow details {:.no_toc} -> You can learn more about this workflow in the [article]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#2-push-the-button" | true_relative_url }}) +> You can learn more about this workflow in the [article]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#2-push-the-button" | true_relative_url }}) {% include /en/how_to/integration_with_ci_cd_systems/github_actions/not_recommended_approach.md %} @@ -430,7 +430,7 @@ Related configuration files ### Workflow components {:.no_toc} -> You can learn more about this workflow in the related [article]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#3-tag-everything" | true_relative_url }}) +> You can learn more about this workflow in the related [article]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#3-tag-everything" | true_relative_url }}) {% include /en/how_to/integration_with_ci_cd_systems/github_actions/not_recommended_approach.md %} @@ -450,7 +450,7 @@ Related configuration files ### Workflow details {:.no_toc} -> You can learn more about this workflow in the related [article]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#4-branch-branch-branch" | true_relative_url }}) +> You can learn more about this workflow in the related [article]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#4-branch-branch-branch" | true_relative_url }}) * Deploying to the review tier using the strategy [No. 2 Automatically using a branch name](#2-automatically-using-a-branch-name. * Deploying to staging and production tiers is carried out according to the strategy [No. 4 Branch, branch, branch!](#4-branch-branch-branch). diff --git a/docs/pages_en/how_to/integration_with_ci_cd_systems/gitlab_ci_cd/workflows.md b/docs/pages_en/how_to/integration_with_ci_cd_systems/gitlab_ci_cd/workflows.md index ff6bd76573..94a945ed90 100644 --- a/docs/pages_en/how_to/integration_with_ci_cd_systems/gitlab_ci_cd/workflows.md +++ b/docs/pages_en/how_to/integration_with_ci_cd_systems/gitlab_ci_cd/workflows.md @@ -214,7 +214,7 @@ Now, let us explore main strategies to deploy the review environment. #### 1. Manually -> This option implements the approach described in the section [Deploy to review using a pull request at the click of a button]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#deploy-to-review-using-a-pull-request-at-the-click-of-a-button" | true_relative_url }}) +> This option implements the approach described in the section [Deploy to review using a pull request at the click of a button]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#deploy-to-review-using-a-pull-request-at-the-click-of-a-button" | true_relative_url }}) With this approach, the user deploys and deletes the environment by clicking the button in the pipeline. @@ -252,7 +252,7 @@ Stop Review: #### 2. Automatically using a branch name -> This option implements the approach described in the section [Automatically deploy to review from a branch using a pattern]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#automatically-deploy-to-review-from-a-branch-using-a-pattern" | true_relative_url }}) +> This option implements the approach described in the section [Automatically deploy to review from a branch using a pattern]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#automatically-deploy-to-review-from-a-branch-using-a-pattern" | true_relative_url }}) In the configuration below, the code is automatically released with every commit in the MR if the name of the git branch has the `review-` prefix. @@ -288,7 +288,7 @@ Stop Review: #### 3. Semi-automatic mode using a label (recommended) -> This option implements the approach described in the section [Automatically deploy to review using a pull request; manual triggering]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#automatically-deploy-to-review-using-a-pull-request-manual-triggering" | true_relative_url }}) +> This option implements the approach described in the section [Automatically deploy to review using a pull request; manual triggering]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#automatically-deploy-to-review-using-a-pull-request-manual-triggering" | true_relative_url }}) Semi-automatic mode with a label is a comprehensive solution that combines the previous two options. @@ -345,7 +345,7 @@ In our case, these environments are the most important ones. Thus, the names of #### 1. Fast and Furious (recommended) -> This scenario implements the approaches described in [Automatically deploy to production from master]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#automatically-deploy-to-production-from-master" | true_relative_url }}) and [Deploy to production-like using a pull request at the click of a button]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#deploy-to-production-like-using-a-pull-request-at-the-click-of-a-button" | true_relative_url }}) sections. +> This scenario implements the approaches described in [Automatically deploy to production from master]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#automatically-deploy-to-production-from-master" | true_relative_url }}) and [Deploy to production-like using a pull request at the click of a button]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#deploy-to-production-like-using-a-pull-request-at-the-click-of-a-button" | true_relative_url }}) sections. The code is automatically deployed to **production** in response to any changes in master. At the same time, you can deploy an application to **staging** by clicking the button in the MR. @@ -376,7 +376,7 @@ Options for rolling back changes in production: #### 2. Push the button -> This scenario implements the approaches described in the [Deploy to production from master at the click of a button]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#deploy-to-production-from-master-at-the-click-of-a-button" | true_relative_url }}) and [Automatically deploy to staging from master]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#automatically-deploy-to-staging-from-master" | true_relative_url }}) sections +> This scenario implements the approaches described in the [Deploy to production from master at the click of a button]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#deploy-to-production-from-master-at-the-click-of-a-button" | true_relative_url }}) and [Automatically deploy to staging from master]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#automatically-deploy-to-staging-from-master" | true_relative_url }}) sections Deploying to **production** is triggered by clicking the button associated with the commit in master, and rolling out to **staging** is performed automatically in response to changes in master. @@ -406,7 +406,7 @@ Options for rolling back changes in production: #### 3. Tag everything (recommended) -> This scenario implements the approaches described in the [Automatically deploy to production using a tag]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#automatically-deploy-to-production-using-a-tag" | true_relative_url }}) and [Deploy to staging from master at the click of a button]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#deploy-to-staging-from-master-at-the-click-of-a-button" | true_relative_url }}) +> This scenario implements the approaches described in the [Automatically deploy to production using a tag]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#automatically-deploy-to-production-using-a-tag" | true_relative_url }}) and [Deploy to staging from master at the click of a button]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#deploy-to-staging-from-master-at-the-click-of-a-button" | true_relative_url }}) The rollout to **production** is triggered when the tag is assigned; deploying to **staging** is performed by clicking the button associated with the specific commit in master. @@ -437,7 +437,7 @@ Options for rolling back changes in production: #### 4. Branch, branch, branch! -> This scenario implements the approaches described in the [Automatically deploy to production from a branch]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#automatically-deploy-to-production-from-a-branch" | true_relative_url }}) and [Automatically deploy to production-like from a branch]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#automatically-deploy-to-production-like-from-a-branch" | true_relative_url }}) sections +> This scenario implements the approaches described in the [Automatically deploy to production from a branch]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#automatically-deploy-to-production-from-a-branch" | true_relative_url }}) and [Automatically deploy to production-like from a branch]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#automatically-deploy-to-production-like-from-a-branch" | true_relative_url }}) sections The code is deployed to **production** automatically; rolling out to **staging** is performed in response to changes in the master branch. @@ -504,7 +504,7 @@ The cleanup stage runs on a schedule only. You can define the schedule by openin ### Workflow Details {:.no_toc} -> You can read more about workflow scenarios in the [article]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#1-fast-and-furious" | true_relative_url }}) +> You can read more about workflow scenarios in the [article]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#1-fast-and-furious" | true_relative_url }}) * [Building and publishing](#building-and-publishing-application-images). * Deploying to the review tier via the strategy [No. 3 Semi-automatic mode using a label (recommended)](#3-semi-automatic-mode-using-a-label-recommended). @@ -608,7 +608,7 @@ Cleanup: ### Workflow Details {:.no_toc} -> You can read more about workflow scenarios in the [article]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#2-push-the-button" | true_relative_url }}) +> You can read more about workflow scenarios in the [article]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#2-push-the-button" | true_relative_url }}) * [Building and publishing](#building-and-publishing-application-images). * Deploying to the review tier via the strategy [No. 1 Manually](#1-manually). @@ -703,7 +703,7 @@ Cleanup: ### Workflow Details {:.no_toc} -> You can read more about workflow scenarios in the [article]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#3-tag-everything" | true_relative_url }}) +> You can read more about workflow scenarios in the [article]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#3-tag-everything" | true_relative_url }}) * [Building and publishing](#building-and-publishing-application-images). * Deploying to the review tier via the strategy [No. 1 Manually](#1-manually). @@ -796,7 +796,7 @@ Cleanup: ### Workflow Details {:.no_toc} -> You can read more about workflow scenarios in the [article]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#4-branch-branch-branch" | true_relative_url }}) +> You can read more about workflow scenarios in the [article]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#4-branch-branch-branch" | true_relative_url }}) * [Building and publishing](#building-and-publishing-application-images). * Deploying to the review tier via the strategy [No. 2 Automatically using a branch name](#2-automatically-using-a-branch-name). diff --git a/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md b/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md index 9980f9d49a..00fbb7451f 100644 --- a/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md +++ b/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflows.md @@ -63,7 +63,7 @@ Review environments are created and deleted dynamically as per the developers' r #### From master branch -##### Automatically +##### Automatically {#automatically-deploy-to-production-from-master} A merge request or a commit to the master branch triggers the pipeline to deploy directly to production. @@ -71,81 +71,81 @@ The state of the branch reflects the state of the environment at any given time. Rollback options: - Recommended: rollback via reverting the commit in the master branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. -- By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- By means of the CI/CD system; the user can [manually re-run the pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). -##### At the click of a button +##### At the click of a button {#deploy-to-production-from-master-at-the-click-of-a-button} -You can manually run a pipeline to deploy to production for a commit in the master branch only. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. +You can manually run a pipeline to deploy to production for a commit in the master branch only. The pipeline is triggered [manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) using the CI/CD system's tools, such as a dedicated button or an API call. Rollback options: -- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). -- By reverting a commit in the master branch and then [manually](#run-a-pipeline-manually) run the pipeline using the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the master is not consistent with the state of the environment at all times (as opposed to the automatic deployment). Thus, it does not make sense to revert exclusively for the rollback. +- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- By reverting a commit in the master branch and then [manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) run the pipeline using the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the master is not consistent with the state of the environment at all times (as opposed to the automatic deployment). Thus, it does not make sense to revert exclusively for the rollback. -#### From a specific branch +#### From a specific branch -##### Automatically +##### Automatically {#automatically-deploy-to-production-from-a-branch} -A merge request or a commit to the specific branch triggers the pipeline to deploy to production (this option is similar to the [master-automatically](#master-automatically), but involves a separate branch). +A merge request or a commit to the specific branch triggers the pipeline to deploy to production (this option is similar to the [master-automatically](#automatically-deploy-to-production-from-master), but involves a separate branch). The state of the specific branch is consistent with the state of the environment at any given time. Therefore, this option complies with the true CI/CD approach. Rollback options: - Recommended: rollback via reverting the commit in the branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. -- By means of the CI/CD system; the user can [manually run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "undo" button performs precisely these steps). +- By means of the CI/CD system; the user can [manually run the pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) on an old commit (e.g., in GitLab CI/CD, the "undo" button performs precisely these steps). - By reverting the commit in the master, then fast-forwarding merge to the specific branch. - By deleting the commit in the specific branch (delete the commit in git and then use the git push-force procedure). ##### At the click of a button -Manually run a pipeline to deploy to production for a commit to the specific branch only. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. +Manually run a pipeline to deploy to production for a commit to the specific branch only. The pipeline is triggered [manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) using the CI/CD system's tools, such as a dedicated button or an API call. Rollback options: -- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). -- By reverting the commit in the specific branch and then [manually](#run-a-pipeline-manually) run the pipeline using the means of the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the master is not consistent with the state of the environment at all times (as opposed to the automatic deployment). Thus, it does not make sense to revert exclusively for the rollback. +- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- By reverting the commit in the specific branch and then [manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) run the pipeline using the means of the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the master is not consistent with the state of the environment at all times (as opposed to the automatic deployment). Thus, it does not make sense to revert exclusively for the rollback. #### From tag -##### Automatically +##### Automatically {#automatically-deploy-to-production-using-a-tag} Creating a new tag automatically triggers the pipeline to deploy the code to the production environment on the basis of the commit associated with this tag. Rollback options: -- Recommended: by means of CI/CD system; [re-run the pipeline manually](#run-a-pipeline-manually) using the old tag. +- Recommended: by means of CI/CD system; [re-run the pipeline manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) using the old tag. - By creating a new tag linked to the old commit; the pipeline will be run automatically for the new tag. It is not the best option since it leads to the generation of unnecessary tags. -##### At the click of a button +##### At the click of a button {#deploy-to-production-using-a-tag-at-the-click-of-a-button} -The pipeline to deploy to the production environment can only be triggered using the existing tag in git. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. +The pipeline to deploy to the production environment can only be triggered using the existing tag in git. The pipeline is triggered [manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) using the CI/CD system's tools, such as a dedicated button or an API call. Rollback options: -- By means of the CI/CD system; [re-run the pipeline manually](#run-a-pipeline-manually) using the old tag. +- By means of the CI/CD system; [re-run the pipeline manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) using the old tag. ### Deploy to production-like environment #### From pull request -##### At the click of a button +##### At the click of a button {#deploy-to-production-like-using-a-pull-request-at-the-click-of-a-button} -The pipeline to deploy to production can be run on any commit to the pull request. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. +The pipeline to deploy to production can be run on any commit to the pull request. The pipeline is triggered [manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) using the CI/CD system's tools, such as a dedicated button or an API call. Rollback options: -- By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- By means of the CI/CD system; the user can [manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). #### From a specific branch -##### Automatically +##### Automatically {#automatically-deploy-to-production-like-from-a-branch} -A merge request or a commit to the specific branch triggers the pipeline to deploy to the production-like environment (this option is similar to [master-automatically](#master-automatically), but involves a separate branch). A separate branch is used for each specific production-like environment, such as staging or testing. +A merge request or a commit to the specific branch triggers the pipeline to deploy to the production-like environment (this option is similar to [master-automatically](#automatically-deploy-to-production-from-master), but involves a separate branch). A separate branch is used for each specific production-like environment, such as staging or testing. The state of the specific branch is consistent with the state of the environment at any given time. Therefore, this option complies with the true CI/CD approach. Rollback options: - Recommended: rollback via reverting the commit in the branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. -- By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- By means of the CI/CD system; the user can [manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). - Revert the commit in the master, then fast-forward merge to the specific branch. - Delete the commit in the specific branch (by deleting the commit in git and then using the git push-force procedure). -###### Example workflow for staging environment +###### Example workflow for staging environment {#automatically-deploy-to-staging-from-master} A merge request or a commit to the master branch triggers the pipeline to deploy directly to the staging environment. @@ -153,27 +153,27 @@ The state of the branch reflects the state of the environment at any given time. Rollback options: - Recommended: rollback via reverting the commit in the master branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. -- By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- By means of the CI/CD system; the user can [manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). -##### At the click of a button +##### At the click of a button {#automatically-deploy-to-production-like-at-the-click-of-a-button} -Manually run a pipeline to deploy to the production-like environment for a commit to the specific branch only. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button or an API call. +Manually run a pipeline to deploy to the production-like environment for a commit to the specific branch only. The pipeline is triggered [manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) using the CI/CD system's tools, such as a dedicated button or an API call. Rollback options: -- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). -- Revert the commit in the specific branch and then [manually](#run-a-pipeline-manually) run the pipeline using the means of the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the branch is not consistent with the state of the environment at all times (as opposed to the automatic deployment to the production-like environment). Thus, it does not make sense to revert exclusively for the purposes of a rollback. +- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- Revert the commit in the specific branch and then [manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) run the pipeline using the means of the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the branch is not consistent with the state of the environment at all times (as opposed to the automatic deployment to the production-like environment). Thus, it does not make sense to revert exclusively for the purposes of a rollback. -###### Example workflow for staging environment +###### Example workflow for staging environment {#deploy-to-staging-from-master-at-the-click-of-a-button} -The pipeline to deploy to staging can only be [run manually](#run-a-pipeline-manually) on a commit from the master branch. The pipeline is triggered manually using the CI/CD system's tools, such as a dedicated button or an API call. +The pipeline to deploy to staging can only be [run manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) on a commit from the master branch. The pipeline is triggered manually using the CI/CD system's tools, such as a dedicated button or an API call. Rollback options: -- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). -- Revert the commit in the master branch and then [manually](#run-a-pipeline-manually) run the pipeline using the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the master does not consistent with the state of the environment at all times (as opposed to the automatic deployment from master to staging). Thus, it does not make sense to revert exclusively for the rollback. +- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- Revert the commit in the master branch and then [manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) run the pipeline using the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the master does not consistent with the state of the environment at all times (as opposed to the automatic deployment from master to staging). Thus, it does not make sense to revert exclusively for the rollback. ### Deploy to review environment -#### From a specific branch (using a pattern) +#### From a specific branch (using a pattern) {#automatically-deploy-to-review-from-a-branch-using-a-pattern} Creating a pull request for a branch that matches some specific pattern automatically triggers a roll-out to a separate review environment. The name of this environment is associated with the name of the branch. Further commits to the branch associated with the pull request automatically trigger a roll-out to the review environment. @@ -181,7 +181,7 @@ For example, if you have a `review_*` pattern, then the creation of a pull reque Rollback options: - Recommended: rollback via reverting the commit in the branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. -- By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- By means of the CI/CD system; the user can [manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). Deleting the review environment: - By closing or merging a PR. @@ -195,34 +195,34 @@ Further commits to the branch tied to the pull request automatically trigger rol Rollback options: - Recommended: rollback via reverting the commit in the branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. -- By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- By means of the CI/CD system; the user can [manually re-run the pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). Deleting the review environment: - By closing or merging a PR. - Automatically when the time-lo-live period since the last deployment expires (in other words, if there is no activity in the environment). -##### Automatically with manual triggering +##### Automatically with manual triggering {#automatically-deploy-to-review-using-a-pull-request-manual-triggering} The review environment is created for the pull request after the pipeline is manually run by the means of the CI/CD system. From this point on, any commit to the branch tied to the pull request leads to an automatic roll-out to the review environment. After the work is complete, you can deactivate the review environment manually using the CI/CD system. -The pipeline to deploy to the review environment can only be run manually on a commit from the branch tied to this environment. The name of this environment is associated with the name of the branch. The pipeline to activate the environment is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button, an API call, or by assigning a label. +The pipeline to deploy to the review environment can only be run manually on a commit from the branch tied to this environment. The name of this environment is associated with the name of the branch. The pipeline to activate the environment is triggered [manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) using the CI/CD system's tools, such as a dedicated button, an API call, or by assigning a label. Rollback options: - Recommended: rollback via reverting the commit in the branch. In this case, the state of the branch is kept synchronized with the state of the environment, so this is the preferred option for preserving schema integrity. -- By means of the CI/CD system; the user can [manually](#run-a-pipeline-manually) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- By means of the CI/CD system; the user can [manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) run the pipeline on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). Deleting the review environment: -- The pipeline to deactivate the environment is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button, an API call, or by assigning a label. +- The pipeline to deactivate the environment is triggered [manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) using the CI/CD system's tools, such as a dedicated button, an API call, or by assigning a label. - By closing or merging a PR. - Automatically when the time-lo-live period since the previous deployment expires (in other words, if there is no activity in the environment). -##### At the click of a button +##### At the click of a button {#deploy-to-review-using-a-pull-request-at-the-click-of-a-button} -The pipeline to deploy to the review environment can only be run manually on a commit from the branch tied to this environment. The name of this environment is associated with the name of the branch. The pipeline is triggered [manually](#run-a-pipeline-manually) using the CI/CD system's tools, such as a dedicated button, an API call, or by assigning a label. +The pipeline to deploy to the review environment can only be run manually on a commit from the branch tied to this environment. The name of this environment is associated with the name of the branch. The pipeline is triggered [manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) using the CI/CD system's tools, such as a dedicated button, an API call, or by assigning a label. Rollback options: -- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline](#run-a-pipeline-manually) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). -- Revert the commit in the specific branch and then [manually](#run-a-pipeline-manually) run the pipeline using the means of the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the branch does not always correspond to the state of the environment (in contrast to "deploy automatically using the pull request" and "deploy automatically using the pull request and a pattern"), so it does not make sense to perform a revert solely for the rollback. +- Recommended: By means of the CI/CD system; the user can [manually re-run the pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) on an old commit (e.g., in GitLab CI/CD, the "rollback" button performs precisely these steps). +- Revert the commit in the specific branch and then [manually]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#run-a-pipeline-manually" | true_relative_url }}) run the pipeline using the means of the CI/CD system: either by hitting a button in the CI/CD or by an API call. We do not recommend this option because the state of the branch does not always correspond to the state of the environment (in contrast to "deploy automatically using the pull request" and "deploy automatically using the pull request and a pattern"), so it does not make sense to perform a revert solely for the rollback. Deleting the review environment: - By closing or merging a PR. diff --git a/docs/pages_en/usage/integration_with_ci_cd_systems/using_with_ci_cd_systems.md b/docs/pages_en/usage/integration_with_ci_cd_systems/using_with_ci_cd_systems.md index 2a27ff1b28..a2787bf4b8 100644 --- a/docs/pages_en/usage/integration_with_ci_cd_systems/using_with_ci_cd_systems.md +++ b/docs/pages_en/usage/integration_with_ci_cd_systems/using_with_ci_cd_systems.md @@ -66,7 +66,7 @@ docker login registry.mydomain.org/application -u USER -p PASSWORD ### Configure the destination environment for werf -Typically, an application is deployed into different [environments]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#environment" | true_relative_url }}) (`production`, `staging`, `testing`, etc.). +Typically, an application is deployed into different [environments]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#environments" | true_relative_url }}) (`production`, `staging`, `testing`, etc.). werf supports the optional `--env` param (or the `WERF_ENV` environment variable) that specifies the name of the environment in use. This environment name affects the [Kubernetes namespace]({{ "/usage/deploy/environments.html#kubernetes-namespace" | true_relative_url }}) and the [Helm release name]({{ "/usage/deploy/releases.html#release-name" | true_relative_url }}). It is recommended to find out the name of the environment as part of the CI/CD job (for example, using built-in environment variables of your CI/CD system) and set the werf `--env` parameter accordingly. diff --git a/docs/pages_ru/how_to/integration_with_ci_cd_systems/github_actions/workflows.md b/docs/pages_ru/how_to/integration_with_ci_cd_systems/github_actions/workflows.md index 18ae591a99..1f1faef24e 100644 --- a/docs/pages_ru/how_to/integration_with_ci_cd_systems/github_actions/workflows.md +++ b/docs/pages_ru/how_to/integration_with_ci_cd_systems/github_actions/workflows.md @@ -172,7 +172,7 @@ on: #### №1 Вручную -> Данный вариант реализует подход описанный в разделе [Выкат на review из pull request по кнопке]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-review-из-pull-request-по-кнопке" | true_relative_url }}) +> Данный вариант реализует подход описанный в разделе [Выкат на review из pull request по кнопке]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-review-из-pull-request-по-кнопке" | true_relative_url }}) При таком подходе пользователь выкатывает и удаляет окружение, проставляя соответствующий лейбл (`review_start` или `review_stop`) в PR. @@ -219,7 +219,7 @@ labels: #### №2 Автоматически по имени ветки -> Данный вариант реализует подход описанный в разделе [Выкат на review из ветки по шаблону автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-review-из-ветки-по-шаблону-автоматически" | true_relative_url }}) +> Данный вариант реализует подход описанный в разделе [Выкат на review из ветки по шаблону автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-review-из-ветки-по-шаблону-автоматически" | true_relative_url }}) В предложенном ниже варианте автоматический релиз выполняется для каждого коммита в PR, в случае, если имя git-ветки содержит `review`. @@ -242,7 +242,7 @@ on: #### №3 Полуавтоматический режим с лейблом (рекомендованный) -> Данный вариант реализует подход описанный в разделе [Выкат на review из pull request автоматически после ручной активации]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-review-из-pull-request-автоматически-после-ручной-активации" | true_relative_url }}) +> Данный вариант реализует подход описанный в разделе [Выкат на review из pull request автоматически после ручной активации]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-review-из-pull-request-автоматически-после-ручной-активации" | true_relative_url }}) Полуавтоматический режим с лейблом — это комплексное решение, объединяющие первые два варианта. @@ -269,7 +269,7 @@ pull_request: #### №1 Fast and Furious (рекомендованный) -> Данный вариант реализует подходы описанные в разделах [Выкат на production из master автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-production-из-master-автоматически" | true_relative_url }}) и [Выкат на production-like из pull request по кнопке]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-production-like-из-pull-request-по-кнопке" | true_relative_url }}) +> Данный вариант реализует подходы описанные в разделах [Выкат на production из master автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-production-из-master-автоматически" | true_relative_url }}) и [Выкат на production-like из pull request по кнопке]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-production-like-из-pull-request-по-кнопке" | true_relative_url }}) Выкат в **production** происходит автоматически при любых изменениях в master. Выполнить выкат в **staging** можно только проставив соответствующий лейбл в PR. @@ -281,7 +281,7 @@ pull_request: #### №2 Push the Button (*) -> Данный вариант реализует подходы описанные в разделах [Выкат на production из master по кнопке]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-production-из-master-по-кнопке" | true_relative_url }}) и [Выкат на staging из master автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-staging-из-master-автоматически" | true_relative_url }}) +> Данный вариант реализует подходы описанные в разделах [Выкат на production из master по кнопке]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-production-из-master-по-кнопке" | true_relative_url }}) и [Выкат на staging из master автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-staging-из-master-автоматически" | true_relative_url }}) {% include /ru/how_to/integration_with_ci_cd_systems/github_actions/not_recommended_approach.md %} @@ -318,7 +318,7 @@ curl \ #### №3 Tag everything (*) -> Данный вариант реализует подходы описанные в разделах [Выкат на production из тега автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-production-из-тега-автоматически" | true_relative_url }}) и [Выкат на staging из master по кнопке]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-staging-из-master-по-кнопке" | true_relative_url }}) +> Данный вариант реализует подходы описанные в разделах [Выкат на production из тега автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-production-из-тега-автоматически" | true_relative_url }}) и [Выкат на staging из master по кнопке]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-staging-из-master-по-кнопке" | true_relative_url }}) {% include /ru/how_to/integration_with_ci_cd_systems/github_actions/not_recommended_approach.md %} @@ -353,7 +353,7 @@ curl \ #### №4 Branch, branch, branch! -> Данный вариант реализует подходы описанные в разделах [Выкат на production из ветки автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-production-из-ветки-автоматически" | true_relative_url }}) и [Выкат на production-like из ветки автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-production-like-из-ветки-автоматически" | true_relative_url }}) +> Данный вариант реализует подходы описанные в разделах [Выкат на production из ветки автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-production-из-ветки-автоматически" | true_relative_url }}) и [Выкат на production-like из ветки автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-production-like-из-ветки-автоматически" | true_relative_url }}) Выкат в **production** происходит автоматически при любых изменениях в ветке production, а в **staging** при любых изменениях в ветке master. @@ -397,7 +397,7 @@ curl \ ### Детали workflow {:.no_toc} -> Подробнее про workflow можно почитать в отдельной [статье]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#1-fast-and-furious" | true_relative_url }}) +> Подробнее про workflow можно почитать в отдельной [статье]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#1-fast-and-furious" | true_relative_url }}) * Выкат на review контур по стратегии [№3 Полуавтоматический режим с лейблом (рекомендованный)](#3-полуавтоматический-режим-с-лейблом-рекомендованный). * Выкат на staging и production контуры осуществляется по стратегии [№1 Fast and Furious (рекомендованный)](#1-fast-and-furious-рекомендованный). @@ -415,7 +415,7 @@ curl \ ### Детали workflow {:.no_toc} -> Подробнее про workflow можно почитать в отдельной [статье]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#2-push-the-button" | true_relative_url }}) +> Подробнее про workflow можно почитать в отдельной [статье]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#2-push-the-button" | true_relative_url }}) {% include /ru/how_to/integration_with_ci_cd_systems/github_actions/not_recommended_approach.md %} @@ -435,7 +435,7 @@ curl \ ### Детали workflow {:.no_toc} -> Подробнее про workflow можно почитать в отдельной [статье]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#3-tag-everything" | true_relative_url }}) +> Подробнее про workflow можно почитать в отдельной [статье]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#3-tag-everything" | true_relative_url }}) {% include /ru/how_to/integration_with_ci_cd_systems/github_actions/not_recommended_approach.md %} @@ -455,7 +455,7 @@ curl \ ### Детали workflow {:.no_toc} -> Подробнее про workflow можно почитать в отдельной [статье]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#4-branch-branch-branch" | true_relative_url }}) +> Подробнее про workflow можно почитать в отдельной [статье]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#4-branch-branch-branch" | true_relative_url }}) * Выкат на review контур по стратегии [№2 Автоматически по имени ветки](#2-автоматически-по-имени-ветки). * Выкат на staging и production контуры осуществляется по стратегии [№4 Branch, branch, branch!](#4-branch-branch-branch). diff --git a/docs/pages_ru/how_to/integration_with_ci_cd_systems/gitlab_ci_cd/workflows.md b/docs/pages_ru/how_to/integration_with_ci_cd_systems/gitlab_ci_cd/workflows.md index e9891c5552..8c7001e79e 100644 --- a/docs/pages_ru/how_to/integration_with_ci_cd_systems/gitlab_ci_cd/workflows.md +++ b/docs/pages_ru/how_to/integration_with_ci_cd_systems/gitlab_ci_cd/workflows.md @@ -209,7 +209,7 @@ Stop Review: #### №1 Вручную -> Данный вариант реализует подход описанный в разделе [Выкат на review из pull request по кнопке]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-review-из-pull-request-по-кнопке" | true_relative_url }}) +> Данный вариант реализует подход описанный в разделе [Выкат на review из pull request по кнопке]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-review-из-pull-request-по-кнопке" | true_relative_url }}) При таком подходе пользователь выкатывает и удаляет окружение по кнопке в pipeline. @@ -248,7 +248,7 @@ Stop Review: #### №2 Автоматически по имени ветки -> Данный вариант реализует подход описанный в разделе [Выкат на review из ветки по шаблону автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-review-из-ветки-по-шаблону-автоматически" | true_relative_url }}) +> Данный вариант реализует подход описанный в разделе [Выкат на review из ветки по шаблону автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-review-из-ветки-по-шаблону-автоматически" | true_relative_url }}) В предложенном ниже варианте автоматический релиз выполняется для каждого коммита в MR, в случае, если имя git-ветки имеет префикс `review-`. @@ -284,7 +284,7 @@ Stop Review: #### №3 Полуавтоматический режим с лейблом (рекомендованный) -> Данный вариант реализует подход описанный в разделе [Выкат на review из pull request автоматически после ручной активации]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-review-из-pull-request-автоматически-после-ручной-активации" | true_relative_url }}) +> Данный вариант реализует подход описанный в разделе [Выкат на review из pull request автоматически после ручной активации]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-review-из-pull-request-автоматически-после-ручной-активации" | true_relative_url }}) Полуавтоматический режим с лейблом — это комплексное решение, объединяющие первые два варианта. @@ -343,7 +343,7 @@ Stop Review: #### №1 Fast and Furious (рекомендованный) -> Данный вариант реализует подходы описанные в разделах [Выкат на production из master автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-production-из-master-автоматически" | true_relative_url }}) и [Выкат на production-like из pull request по кнопке]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-production-like-из-pull-request-по-кнопке" | true_relative_url }}) +> Данный вариант реализует подходы описанные в разделах [Выкат на production из master автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-production-из-master-автоматически" | true_relative_url }}) и [Выкат на production-like из pull request по кнопке]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-production-like-из-pull-request-по-кнопке" | true_relative_url }}) Выкат в **production** происходит автоматически при любых изменениях в master. Выполнить выкат в **staging** можно по кнопке в MR. @@ -372,7 +372,7 @@ Deploy to Production: #### №2 Push the Button -> Данный вариант реализует подходы описанные в разделах [Выкат на production из master по кнопке]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-production-из-master-по-кнопке" | true_relative_url }}) и [Выкат на staging из master автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-staging-из-master-автоматически" | true_relative_url }}) +> Данный вариант реализует подходы описанные в разделах [Выкат на production из master по кнопке]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-production-из-master-по-кнопке" | true_relative_url }}) и [Выкат на staging из master автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-staging-из-master-автоматически" | true_relative_url }}) Выкат **production** осуществляется по кнопке у коммита в master, а выкат в **staging** происходит автоматически при любых изменениях в master. @@ -401,7 +401,7 @@ Deploy to Production: #### №3 Tag everything (рекомендованный) -> Данный вариант реализует подходы описанные в разделах [Выкат на production из тега автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-production-из-тега-автоматически" | true_relative_url }}) и [Выкат на staging из master по кнопке]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-staging-из-master-по-кнопке" | true_relative_url }}) +> Данный вариант реализует подходы описанные в разделах [Выкат на production из тега автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-production-из-тега-автоматически" | true_relative_url }}) и [Выкат на staging из master по кнопке]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-staging-из-master-по-кнопке" | true_relative_url }}) Выкат в **production** выполняется при проставлении тега, а в **staging** по кнопке у коммита в master. @@ -431,7 +431,7 @@ Deploy to Production: #### №4 Branch, branch, branch! -> Данный вариант реализует подходы описанные в разделах [Выкат на production из ветки автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-production-из-ветки-автоматически" | true_relative_url }}) и [Выкат на production-like из ветки автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#выкат-на-production-like-из-ветки-автоматически" | true_relative_url }}) +> Данный вариант реализует подходы описанные в разделах [Выкат на production из ветки автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-production-из-ветки-автоматически" | true_relative_url }}) и [Выкат на production-like из ветки автоматически]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#выкат-на-production-like-из-ветки-автоматически" | true_relative_url }}) Выкат в **production** происходит автоматически при любых изменениях в ветке production, а в **staging** при любых изменениях в ветке master. @@ -498,7 +498,7 @@ Cleanup: ### Детали workflow {:.no_toc} -> Подробнее про workflow можно почитать в отдельной [статье]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#1-fast-and-furious" | true_relative_url }}) +> Подробнее про workflow можно почитать в отдельной [статье]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#1-fast-and-furious" | true_relative_url }}) * [Сборка и публикация](#сборка-и-публикация-образов-приложения). * Выкат на review контур по стратегии [№3 Полуавтоматический режим с лейблом (рекомендованный)](#3-полуавтоматический-режим-с-лейблом-рекомендованный). @@ -601,7 +601,7 @@ Cleanup: ### Детали workflow {:.no_toc} -> Подробнее про workflow можно почитать в отдельной [статье]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#2-push-the-button" | true_relative_url }}) +> Подробнее про workflow можно почитать в отдельной [статье]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#2-push-the-button" | true_relative_url }}) * [Сборка и публикация](#сборка-и-публикация-образов-приложения). * Выкат на review контур по стратегии [№1 Вручную](#1-вручную). @@ -696,7 +696,7 @@ Cleanup: ### Детали workflow {:.no_toc} -> Подробнее про workflow можно почитать в отдельной [статье]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#3-tag-everything" | true_relative_url }}) +> Подробнее про workflow можно почитать в отдельной [статье]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#3-tag-everything" | true_relative_url }}) * [Сборка и публикация](#сборка-и-публикация-образов-приложения). * Выкат на review контур по стратегии [№1 Вручную](#1-вручную). @@ -789,7 +789,7 @@ Cleanup: ### Детали workflow {:.no_toc} -> Подробнее про workflow можно почитать в отдельной [статье]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#4-branch-branch-branch" | true_relative_url }}) +> Подробнее про workflow можно почитать в отдельной [статье]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflows.html#4-branch-branch-branch" | true_relative_url }}) * [Сборка и публикация](#сборка-и-публикация-образов-приложения). * Выкат на review контур по стратегии [№2 Автоматически по имени ветки](#2-автоматически-по-имени-ветки). diff --git a/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md b/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md index a8984c139d..73c6c535d2 100644 --- a/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md +++ b/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md @@ -11,35 +11,37 @@ permalink: usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html - Инструкция для [GitLab CI/CD]({{ "how_to/integration_with_ci_cd_systems/gitlab_ci_cd/workflows.html" | true_relative_url }}). - Инструкция для [Github Actions]({{ "how_to/integration_with_ci_cd_systems/github_actions/workflows.html" | true_relative_url }}). -## Основы +## Pipeline -> NOTICE: По тексту далее git можно интерпретировать как имя нарицательное для любой системы контроля версий, однако werf поддерживает лишь эту систему контроля версий. Предполагается знакомство читателя с такими терминами, связанными с git, как: ветка (branch), тег (tag), мастер (master), коммит (commit), слияние изменений (merge), rebase, реверт (revert), fast-forward merge, процедура git push-force. Рекомендуется ознакомиться и понять каждый из приведенных терминов для полного понимания материала данной статьи. - -### Окружение - -#### Production - -В этом окружении работает разрабатываемая система, это целевое окружение для всех изменений, которые делают разработчики системы. Этим окружением пользуются реальные пользователи в процессе эксплуатации системы. - -Существуют также так называемые _production-like_ окружения, особенность которых в том, что конфигурация выделенных для окружения ресурсов (инфраструктура, конфигурация железа, версии софта, операционная система, сетевая организация), а также внешние сервисы — по максимуму насколько возможно совпадают с production окружением. Есть нюансы, из-за которых различия могут быть, но в каждом конкретном _production-like_ окружении определяются свои допустимые риски связанные с различием с production окружением. Примеры таких окружений: [staging](#staging) и [testing](#testing) — рассмотрены далее. +С помощью git пользователь вносит изменения в кодовую базу проекта. Каждый коммит в гит активирует так называемый **pipeline** со стороны CI/CD системы. Pipeline разбит на стадии, которые могут запускаться последовательно или параллельно. -#### Staging +Главное назначение pipeline — донести внесённое в гит изменение до некоторого окружения. В случае непрохождения какой-то стадии pipeline прерывается и пользователь тем самым получает обратную связь. Коммит, который успешно проходит по всем необходимым стадиям попадает на некоторый контур/окружение. -Staging — это [production-like окружение](#production), в котором происходит финальная проверка перед выкатом на [production](#production). Staging даёт возможность полнее протестировать бизнес-функции приложения и обычно это то место, куда идут менеджеры, тестировщики, заказчики. +Бывают следующие основные типы стадий: + - Build-and-Publish — сборка образов приложения и их публикация в хранилище образов. + - Deploy — непосредственно выкат приложения на контур. + - Cleanup — очистка неиспользуемых образов и связанного кеша из хранилища. -В случае, если приложение связано с какими либо внешними сервисами, staging — это единственное окружение помимо [production](#production), где можно проверить как новая версия работает в связке с реальными версиями внешних систем. +### Pull request -#### Testing +Пользователь вносит изменения в кодовую базу путём создания коммитов в git и pull request-ов в CI/CD системе. Обычно pull request — это сущность, которая связывает коммит в git и pipeline (а также позволяет делать review, оставлять комментарии и пр.). В разных CI/CD системах pull request может называться по-разному (Merge Request в GitLab CI) или вообще отсутствовать (Jenkins). -Testing — это [production-like окружение](#production), цель которого: выявить возникшие у приложения проблемы на [production](#production) окружении. В данном окружении могут работать "долгие" автоматизированные тесты приложения, которые проверяют множество аспектов его работы. Чем больше различий между testing и production, тем больше рисков получить нерабочее приложение после очередного выката, поэтому рекомендуется максимально повторять production окружение (одинаковый софт, версии, библиотеки, IP-адреса и порты, железо и т.д.). +### Workflow -#### Review +Pipeline-ы и стадии внутри pipeline-ов могут быть активированы как автоматически, так и вручную. Способы активации pipeline-ов, их устройство, связь с гит, требуемые действия со стороны пользователя — всё это будет определяться так называемым workflow. +Возможно множество вариантов workflow для достижения одной и той же цели. Далее мы рассмотрим те варианты, которые можно реализовать с использованием werf. -Динамический (временный) контур, используемый разработчиками при разработке для оценки работоспособности написанного кода, первичной оценки работоспособности приложения и проведения таких экспериментов, которые нельзя делать на [production-like окружениях](#production). +### Варианты ручного запуска pipeline -Особенность review-окружений в том, что их можно создавать динамически в любых количествах (в разумных пределах, насколько позволяют ресурсы). Как правило, создание и удаление такого окружения инициируется разработчиком через CI/CD систему, также такое окружение может быть удалено автоматически после отсутствия активности в течение некоторого времени. +Ручной запуск pipeline предполагает: + - Нажатие кнопки в CI/CD системе (например Gitlab CI). + - Назначение label в CI/CD системе (например Gitlab CI или Github Actions). Label обычно назначается на pull request и снимается с pull request пользователем или автоматически CI/CD системой во время работы pipeline. + - Например, пользователь назначает label "run tests" на его pull request и CI/CD система автоматически запускает соответствующий pipeline. Во время работы этого pipeline label "run tests" снимается с pull request. Далее для перезапуска пользователь может опять назначить этот label. И т.д. + - Label используется как альтернатива кнопкам, либо в случаях когда кнопки не поддерживаются CI/CD системой (например, Github Actions). +Для review окружений назначение пользователем label является сигналом к активации review окружения, а его снятие (вручную/автоматом) — к деактивации. Вариант будет подробнее рассмотрен (далее)(#автоматом-для-pull-request-после-ручной-активации). + - Запрос через API CI/CD системы (например через HTTP по определённому url в Github Actions). -### Релизы и CI/CD +## Релизы и CI/CD **Релиз** — это оформленная версия приложения с какими-то изменениями с момента предыдущего релиза. @@ -49,37 +51,31 @@ Testing — это [production-like окружение](#production), цель В дальнейших разделах мы определим возможные варианты конфигураций workflow и насколько каждый из них соответствует подходам CI/CD. -### Что такое pipeline и workflow +## Окружения -С помощью git пользователь вносит изменения в кодовую базу проекта. Каждый коммит в гит активирует так называемый **pipeline** со стороны CI/CD системы. Pipeline разбит на стадии, которые могут запускаться последовательно или параллельно. +### Production -Главное назначение pipeline — донести внесённое в гит изменение до некоторого окружения. В случае непрохождения какой-то стадии pipeline прерывается и пользователь тем самым получает обратную связь. Коммит, который успешно проходит по всем необходимым стадиям попадает на некоторый контур/окружение. +В этом окружении работает разрабатываемая система, это целевое окружение для всех изменений, которые делают разработчики системы. Этим окружением пользуются реальные пользователи в процессе эксплуатации системы. -Бывают следующие основные типы стадий: - - Build-and-Publish — сборка образов приложения и их публикация в хранилище образов. - - Deploy — непосредственно выкат приложения на контур. - - Cleanup — очистка неиспользуемых образов и связанного кеша из хранилища. +Существуют также так называемые _production-like_ окружения, особенность которых в том, что конфигурация выделенных для окружения ресурсов (инфраструктура, конфигурация железа, версии софта, операционная система, сетевая организация), а также внешние сервисы — по максимуму насколько возможно совпадают с production окружением. Есть нюансы, из-за которых различия могут быть, но в каждом конкретном _production-like_ окружении определяются свои допустимые риски связанные с различием с production окружением. Примеры таких окружений: [staging](#staging) и [testing](#testing) — рассмотрены далее. -#### Pull request +### Staging -Пользователь вносит изменения в кодовую базу путём создания коммитов в git и pull request-ов в CI/CD системе. Обычно pull request — это сущность, которая связывает коммит в git и pipeline (а также позволяет делать review, оставлять комментарии и пр.). В разных CI/CD системах pull request может называться по-разному (Merge Request в GitLab CI) или вообще отсутствовать (Jenkins). +Staging — это [production-like окружение](#production), в котором происходит финальная проверка перед выкатом на [production](#production). Staging даёт возможность полнее протестировать бизнес-функции приложения и обычно это то место, куда идут менеджеры, тестировщики, заказчики. -#### Workflow +В случае, если приложение связано с какими либо внешними сервисами, staging — это единственное окружение помимо [production](#production), где можно проверить как новая версия работает в связке с реальными версиями внешних систем. -Pipeline-ы и стадии внутри pipeline-ов могут быть активированы как автоматически, так и вручную. Способы активации pipeline-ов, их устройство, связь с гит, требуемые действия со стороны пользователя — всё это будет определяться так называемым workflow. -Возможно множество вариантов workflow для достижения одной и той же цели. Далее мы рассмотрим те варианты, которые можно реализовать с использованием werf. +### Testing -### Варианты ручного запуска pipeline +Testing — это [production-like окружение](#production), цель которого: выявить возникшие у приложения проблемы на [production](#production) окружении. В данном окружении могут работать "долгие" автоматизированные тесты приложения, которые проверяют множество аспектов его работы. Чем больше различий между testing и production, тем больше рисков получить нерабочее приложение после очередного выката, поэтому рекомендуется максимально повторять production окружение (одинаковый софт, версии, библиотеки, IP-адреса и порты, железо и т.д.). -Ручной запуск pipeline предполагает: - - Нажатие кнопки в CI/CD системе (например Gitlab CI). - - Назначение label в CI/CD системе (например Gitlab CI или Github Actions). Label обычно назначается на pull request и снимается с pull request пользователем или автоматически CI/CD системой во время работы pipeline. - - Например, пользователь назначает label "run tests" на его pull request и CI/CD система автоматически запускает соответствующий pipeline. Во время работы этого pipeline label "run tests" снимается с pull request. Далее для перезапуска пользователь может опять назначить этот label. И т.д. - - Label используется как альтернатива кнопкам, либо в случаях когда кнопки не поддерживаются CI/CD системой (например, Github Actions). -Для review окружений назначение пользователем label является сигналом к активации review окружения, а его снятие (вручную/автоматом) — к деактивации. Вариант будет подробнее рассмотрен (далее)(#автоматом-для-pull-request-после-ручной-активации). - - Запрос через API CI/CD системы (например через HTTP по определённому url в Github Actions). +### Review + +Динамический (временный) контур, используемый разработчиками при разработке для оценки работоспособности написанного кода, первичной оценки работоспособности приложения и проведения таких экспериментов, которые нельзя делать на [production-like окружениях](#production). + +Особенность review-окружений в том, что их можно создавать динамически в любых количествах (в разумных пределах, насколько позволяют ресурсы). Как правило, создание и удаление такого окружения инициируется разработчиком через CI/CD систему, также такое окружение может быть удалено автоматически после отсутствия активности в течение некоторого времени. -### Стадия тестирования +## Стадия тестирования Для правильной организации CI/CD критично во время внесения изменений в кодовую базу проекта получать быструю обратную связь в автоматическом режиме с помощью тестов. Причём стадию тестирования можно разбить на 2 условных этапа: на первичном этапе тесты проходят быстро и покрывают большую часть функций, на вторичном этапе тесты могут работать долго и проверять больше аспектов приложение. Первичные тесты обычно запускаются автоматически и их прохождение является обязательным условием для допуска изменений к релизу. diff --git a/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md b/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md index 9fd52f4071..5ff7b8807b 100644 --- a/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md +++ b/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflows.md @@ -59,7 +59,7 @@ permalink: usage/integration_with_ci_cd_systems/ci_cd_workflows.html #### Из master ветки -##### Автоматически +##### Автоматически {#выкат-на-production-из-master-автоматически} Merge или коммит в ветку master вызывает pipeline выката непосредственно на production. @@ -67,81 +67,81 @@ Merge или коммит в ветку master вызывает pipeline вык Варианты отката: - Рекомендованный: откат через реверт коммита в ветке master. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. -- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Средствами CI/CD системы, повторный [ручной вызов pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). -##### По кнопке +##### По кнопке {#выкат-на-production-из-master-по-кнопке} -Pipeline выката в production может быть запущен вручную только на коммите из ветки master. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. +Pipeline выката в production может быть запущен вручную только на коммите из ветки master. Запуск pipeline производится средствами CI/CD системы [вручную]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}): кнопка в CI/CD системе или вызов API. Варианты отката: -- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). -- Реверт коммита в ветке master, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта master-автоматом), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. +- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Реверт коммита в ветке master, затем запуск pipeline средствами CI/CD системы [вручную]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта master-автоматом), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. -#### Из произвольной ветки +#### Из произвольной ветки -##### Автоматически +##### Автоматически {#выкат-на-production-из-ветки-автоматически} -Merge или коммит в специальную ветку вызывает pipeline выката непосредственно на production (вариант похож на [master-автоматически](#master-автоматически), но используется отдельная ветка). +Merge или коммит в специальную ветку вызывает pipeline выката непосредственно на production (вариант похож на [master-автоматически](#выкат-на-production-из-master-автоматически), но используется отдельная ветка). Состояние специальной ветки в любой момент времени отражает состояние окружения. Поэтому данный вариант является соответствующим подходу true CI/CD. Варианты отката: - Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. -- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Средствами CI/CD системы, повторный [ручной вызов pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). - Реверт коммита в master, затем fast-forward merge в специальную ветку. - Удаление коммита в специальной ветке (через удаление коммита в git, затем процедура git push-force). ##### По кнопке -Pipeline выката в production может быть запущен вручную только на коммите из специальной ветки. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. +Pipeline выката в production может быть запущен вручную только на коммите из специальной ветки. Запуск pipeline производится средствами CI/CD системы [вручную]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}): кнопка в CI/CD системе или вызов API. Варианты отката: -- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). -- Реверт коммита в ветке, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта master-автоматом), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. +- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Реверт коммита в ветке, затем запуск pipeline средствами CI/CD системы [вручную]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта master-автоматом), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. #### Из тега -##### Автоматически +##### Автоматически {#выкат-на-production-из-тега-автоматически} Создание нового тега автоматически вызывает pipeline выката на production-окружение из коммита, связанного с этим тегом. Варианты отката: -- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом теге. +- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}) на старом теге. - Создание нового тега на старый коммит, далее автоматический вызов pipeline выката для нового тега. Не предпочтительный вариант, т.к. плодятся лишние теги. ##### По кнопке -Pipeline выката в production-окружение может быть вызван только на существующем теге в git. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. +Pipeline выката в production-окружение может быть вызван только на существующем теге в git. Запуск pipeline производится средствами CI/CD системы [вручную]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}): кнопка в CI/CD системе или вызов API. Варианты отката: -- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом теге. +- Средствами CI/CD системы, повторный [ручной вызов pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}) на старом теге. ### Выкат на production-like #### Из pull request -##### По кнопке +##### По кнопке {#выкат-на-production-like-из-pull-request-по-кнопке} -Pipeline выката в production может быть запущен на любом коммите в pull request. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. +Pipeline выката в production может быть запущен на любом коммите в pull request. Запуск pipeline производится средствами CI/CD системы [вручную]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}): кнопка в CI/CD системе или вызов API. Варианты отката: -- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Средствами CI/CD системы, повторный [ручной вызов pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). #### Из ветки -##### Автоматически +##### Автоматически {#выкат-на-production-like-из-ветки-автоматически} -Merge или коммит в специальную ветку вызывает pipeline выката непосредственно на production-like окружение (вариант похож на [master-автоматически](#master-автоматически), но используется отдельная ветка). Для каждого конкретного production-like окружения, как то: staging или testing — используется отдельная ветка. +Merge или коммит в специальную ветку вызывает pipeline выката непосредственно на production-like окружение (вариант похож на [master-автоматически](#выкат-на-production-из-master-автоматически), но используется отдельная ветка). Для каждого конкретного production-like окружения, как то: staging или testing — используется отдельная ветка. Состояние специальной ветки в любой момент времени отражает состояние окружения. Поэтому данный вариант является соответствующим подходу true CI/CD. Варианты отката: - Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. -- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Средствами CI/CD системы, повторный [ручной вызов pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). - Реверт коммита в master, затем fast-forward merge в специальную ветку. - Удаление коммита в специальной ветке (через удаление коммита в git, затем процедура git push-force). -###### Пример рабочего процесса для staging +###### Пример рабочего процесса для staging {#выкат-на-staging-из-master-автоматически} Merge или коммит в ветку master вызывает pipeline выката непосредственно на staging окружение. @@ -149,23 +149,23 @@ Merge или коммит в ветку master вызывает pipeline вык Варианты отката: - Рекомендованный: откат через реверт коммита в ветке master. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. -- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Средствами CI/CD системы, повторный [ручной вызов pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). ##### По кнопке -Pipeline выката в production-like окружение может быть запущен вручную только на коммите из специальной ветки. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. +Pipeline выката в production-like окружение может быть запущен вручную только на коммите из специальной ветки. Запуск pipeline производится средствами CI/CD системы [вручную]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}): кнопка в CI/CD системе или вызов API. Варианты отката: -- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). -- Реверт коммита в ветке, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние ветки не всегда соответствует состоянию окружения (в отличие от варианта Выкат на production-like из ветки автоматически), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. +- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Реверт коммита в ветке, затем запуск pipeline средствами CI/CD системы [вручную]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние ветки не всегда соответствует состоянию окружения (в отличие от варианта Выкат на production-like из ветки автоматически), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. -###### Пример рабочего процесса для staging +###### Пример рабочего процесса для staging {#выкат-на-staging-из-master-по-кнопке} -Pipeline выката в staging может быть запущен вручную только на коммите из ветки master. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. +Pipeline выката в staging может быть запущен вручную только на коммите из ветки master. Запуск pipeline производится средствами CI/CD системы [вручную]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}): кнопка в CI/CD системе или вызов API. Варианты отката: -- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). -- Реверт коммита в ветке master, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта Выкат на staging из master автоматически), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. +- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Реверт коммита в ветке master, затем запуск pipeline средствами CI/CD системы [вручную]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта Выкат на staging из master автоматически), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. ### Выкат на review @@ -177,34 +177,34 @@ Pipeline выката в staging может быть запущен вручну Варианты отката: - Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. -- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Средствами CI/CD системы, повторный [ручной вызов pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). Удаление review-окружения: - По закрытию или принятию PR. - Автоматически по истечению time-to-live с последнего выката на данное окружение (другими словами, при отсутствии активности в данном окружении). -##### Автоматически после ручной активации +##### Автоматически после ручной активации {#выкат-на-review-из-pull-request-автоматически-после-ручной-активации} Review-окружение для pull request создаётся после его ручной активации средствами CI/CD системы. С этого момента любой коммит в ветку, связанную с pull request, вызывает автоматический выкат на review окружение. После работы с review его можно деактивировать вручную средствами CI/CD системы. -Pipeline выката в review-окружение может быть запущен только на коммите из ветки соответствующей этому окружению. Название этого окружения связано с именем ветки. Запуск pipeline для активации review окружения производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе, повесить label или вызов API. +Pipeline выката в review-окружение может быть запущен только на коммите из ветки соответствующей этому окружению. Название этого окружения связано с именем ветки. Запуск pipeline для активации review окружения производится средствами CI/CD системы [вручную]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}): кнопка в CI/CD системе, повесить label или вызов API. Варианты отката: - Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. -- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Средствами CI/CD системы, повторный [ручной вызов pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). Удаление review-окружения: -- Запуск pipeline для деактивации review окружения средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе, снять ранее повешенный label или вызов API. +- Запуск pipeline для деактивации review окружения средствами CI/CD системы [вручную]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}): кнопка в CI/CD системе, снять ранее повешенный label или вызов API. - По закрытию или принятию PR. - Автоматически по истечению time-to-live с последнего выката на данное окружение (другими словами, при отсутствии активности в данном окружении). -##### По кнопке +##### По кнопке {#выкат-на-review-из-pull-request-по-кнопке} -Pipeline выката в review-окружение может быть запущен вручную только на коммите из ветки соответствующей этому окружению. Название этого окружения связано с именем ветки. Запуск pipeline производится средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе, повесить label или вызов API. +Pipeline выката в review-окружение может быть запущен вручную только на коммите из ветки соответствующей этому окружению. Название этого окружения связано с именем ветки. Запуск pipeline производится средствами CI/CD системы [вручную]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}): кнопка в CI/CD системе, повесить label или вызов API. Варианты отката: -- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). -- Реверт коммита в ветке, затем запуск pipeline средствами CI/CD системы [вручную](#варианты-ручного-запуска-pipeline): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние ветки не всегда соответствует состоянию окружения (в отличие от вариантов "автоматом для pull-request" и "автоматом для pull-request по паттерну"), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. +- Рекомендованный: средствами CI/CD системы, повторный [ручной вызов pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Реверт коммита в ветке, затем запуск pipeline средствами CI/CD системы [вручную]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}): кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние ветки не всегда соответствует состоянию окружения (в отличие от вариантов "автоматом для pull-request" и "автоматом для pull-request по паттерну"), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката. Удаление review-окружения: - По закрытию или принятию PR. @@ -212,7 +212,7 @@ Pipeline выката в review-окружение может быть запу #### Из ветки -##### Автоматически +##### Автоматически {#выкат-на-review-из-ветки-по-шаблону-автоматически} Создание pull request для ветки, подходящей под определённый паттерн автоматически вызывает выкат в отдельное review окружение. Название этого окружения связано с именем ветки. Дальнейшие коммиты в ветку, связанную с pull request автоматически вызывают выкат в review окружение. @@ -220,7 +220,7 @@ Pipeline выката в review-окружение может быть запу Варианты отката: - Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы. -- Средствами CI/CD системы, повторный [ручной вызов pipeline](#варианты-ручного-запуска-pipeline) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). +- Средствами CI/CD системы, повторный [ручной вызов pipeline]({{ "usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html#варианты-ручного-запуска-pipeline" | true_relative_url }}) на старом коммите (например, в Gitlab CI кнопка "откатить" по факту выполняет именно эти шаги). Удаление review-окружения: - По закрытию или принятию PR. From a81a0c76e225e0ae65c0bac8f9997ea09f1c822c Mon Sep 17 00:00:00 2001 From: Alexey Igrychev Date: Fri, 16 Dec 2022 15:57:33 +0000 Subject: [PATCH 7/7] docs(ci/cd): small improvements for basics Signed-off-by: Alexey Igrychev --- .../ci_cd_workflow_basics.md | 27 ++---- .../ci_cd_workflow_basics.md | 88 +++++++++---------- 2 files changed, 50 insertions(+), 65 deletions(-) diff --git a/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md b/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md index e835f09e6d..01aaab854e 100644 --- a/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md +++ b/docs/pages_en/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md @@ -15,29 +15,28 @@ We also recommend you to read one the following guides about configuring the spe ## Basics -> NOTICE: In the text below, the term "git" can be interpreted as a common name for any version control system. However, werf supports only the Git version control system. We suppose our readers are familiar with the following git-related terms: branch, tag, master, commit, merge, rebase, fast-forward merge, and the git push-force procedure. To fully appreciate this article, readers are advised to get a good understanding of these terms. - -### Environment +### Environments #### Production Generally, end users interact with an application in the production environment. It is also the target environment for all application code changes made by application developers. -Also, there are so-called _production-like_ environments. Production-like environments are separate from production but have the same hardware and software configuration, network infrastructure, operating system, software versions, etc. In the real world, there may be some differences, though. Still, each project defines its acceptable risks related to the difference between production-like and production environments. Examples of production-like environments – [staging](#staging) and [testing](#testing) – are provided below. +#### Production-like -#### Staging +Production-like environments are separate from production but have the same hardware and software configuration, network infrastructure, operating system, software versions, etc. In the real world, there may be some differences, though. Still, each project defines its acceptable risks related to the difference between production-like and production environments. +##### Staging -Staging is a [production-like environment](#production) serving as a playground to examine your application before deploying it to production. Also, staging is the place to test new business functionality by managers, testers, and customers. End users do not interact with the staging environment in any way. +Staging is an environment serving as a playground to examine your application before deploying it to production. Also, staging is the place to test new business functionality by managers, testers, and customers. End users do not interact with the staging environment in any way. If your application uses some external services, then staging is the only environment typically (besides the production itself) that uses the same set of external services APIs and versions. -#### Testing +##### Testing -Testing is a [production-like environment](#production) with the following goal: to reveal problems with the new version of an application that may arise in the production environment. Some long-running application tests may use this environment to perform full-fledged application testing in a production-like environment. The higher the difference between testing and production environments, the higher the risk of deploying a buggy application to the production environment. That's why we recommend making a production-like environment as close as possible to a production one (same software versions, libraries, operating system, IP-addresses and ports, hardware, etc.). +Testing is an environment with the following goal: to reveal problems with the new version of an application that may arise in the production environment. Some long-running application tests may use this environment to perform full-fledged application testing in a production-like environment. The higher the difference between testing and production environments, the higher the risk of deploying a buggy application to the production environment. That's why we recommend making a production-like environment as close as possible to a production one (same software versions, libraries, operating system, IP-addresses and ports, hardware, etc.). #### Review -Review is a dynamic (temporary) environment used by application developers to test newly written code and conduct experiments not allowed in [production-like environments](#production). +Review is a dynamic (temporary) environment used by application developers to test newly written code and conduct experiments not allowed in [production-like environments](#production-like). It is possible to dynamically create an arbitrary number of review environments (as resources permit). Application developer usually creates and terminates such an environment using a CI/CD system. Also, a review environment could be automatically removed after a period of inactivity. @@ -78,17 +77,9 @@ You can run a pipeline manually by one of the following methods: - By assigning a label in a CI/CD system (e.g., GitLab CI/CD or GitHub Actions). A label is usually assigned to/withdrawn from the pull request by the user or automatically by the CI/CD system while the pipeline is running. - For example, the user assigns the "run tests" label to his pull request, and the CI/CD system automatically triggers the corresponding pipeline. While this pipeline is running, the "run tests" label is revoked from the pull request. Then the user can assign this label again to restart the process, and so on. - Label serves as an alternative to buttons or is used in cases when the CI/CD system does not support buttons (e.g., GitHub Actions). - For review environments, assigning a label by the user is a signal to activate the review environment, and removing it (manually or automatically) is a signal to deactivate it. This option will be discussed in more detail (later) (#automatically-deploy-to-review-using-a-pull-request-manual-triggering). + For review environments, assigning a label by the user is a signal to activate the review environment, and removing it (manually or automatically) is a signal to deactivate it. - By sending a request to the API of the CI/CD system (for example, via HTTP at a specific url in GitHub Actions). ### The testing stage To implement a proper CI/CD, it is critical to automatically get instant feedback when making changes to the project codebase. The testing stage can be divided into two nominal stages: during the primary stage, tests run fast and cover most of the functions; during the secondary stage, tests can run for a prolonged time and verify more aspects of the application. Generally, primary tests are run automatically, and passing them is a prerequisite for changes to be released. - -## Further reading - -We recommend you to read the guide for your specific CI/CD system: - - The [GitLab CI/CD]({{ "how_to/integration_with_ci_cd_systems/gitlab_ci_cd/workflows.html" | true_relative_url }}) guide. - - The [GitHub Actions]({{ "how_to/integration_with_ci_cd_systems/github_actions/workflows.html" | true_relative_url }}) guide. - -If you want to learn more about how to create a workflow, or no instructions exist for your particular CI/CD system, then you can read the following sections where the [workflow components](#workflow-components-for-various-environments) and [ready-made workflow configurations](#ready-made-workflow-configurations) are defined. After reading them, you will be able to choose a ready-made configuration (or create your own) and implement it for your CI/CD system using werf. diff --git a/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md b/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md index 73c6c535d2..fe957aad33 100644 --- a/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md +++ b/docs/pages_ru/usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.md @@ -11,80 +11,74 @@ permalink: usage/integration_with_ci_cd_systems/ci_cd_workflow_basics.html - Инструкция для [GitLab CI/CD]({{ "how_to/integration_with_ci_cd_systems/gitlab_ci_cd/workflows.html" | true_relative_url }}). - Инструкция для [Github Actions]({{ "how_to/integration_with_ci_cd_systems/github_actions/workflows.html" | true_relative_url }}). -## Pipeline +## Основы -С помощью git пользователь вносит изменения в кодовую базу проекта. Каждый коммит в гит активирует так называемый **pipeline** со стороны CI/CD системы. Pipeline разбит на стадии, которые могут запускаться последовательно или параллельно. - -Главное назначение pipeline — донести внесённое в гит изменение до некоторого окружения. В случае непрохождения какой-то стадии pipeline прерывается и пользователь тем самым получает обратную связь. Коммит, который успешно проходит по всем необходимым стадиям попадает на некоторый контур/окружение. +### Окружение -Бывают следующие основные типы стадий: - - Build-and-Publish — сборка образов приложения и их публикация в хранилище образов. - - Deploy — непосредственно выкат приложения на контур. - - Cleanup — очистка неиспользуемых образов и связанного кеша из хранилища. +#### Production -### Pull request - -Пользователь вносит изменения в кодовую базу путём создания коммитов в git и pull request-ов в CI/CD системе. Обычно pull request — это сущность, которая связывает коммит в git и pipeline (а также позволяет делать review, оставлять комментарии и пр.). В разных CI/CD системах pull request может называться по-разному (Merge Request в GitLab CI) или вообще отсутствовать (Jenkins). - -### Workflow +В этом окружении работает разрабатываемая система, это целевое окружение для всех изменений, которые делают разработчики системы. Этим окружением пользуются реальные пользователи в процессе эксплуатации системы. -Pipeline-ы и стадии внутри pipeline-ов могут быть активированы как автоматически, так и вручную. Способы активации pipeline-ов, их устройство, связь с гит, требуемые действия со стороны пользователя — всё это будет определяться так называемым workflow. -Возможно множество вариантов workflow для достижения одной и той же цели. Далее мы рассмотрим те варианты, которые можно реализовать с использованием werf. +#### Production-like -### Варианты ручного запуска pipeline +Конфигурация выделенных для окружения ресурсов (инфраструктура, конфигурация железа, версии софта, операционная система, сетевая организация), а также внешние сервисы — по максимуму насколько возможно совпадают с production окружением. Есть нюансы, из-за которых различия могут быть, но в каждом конкретном _production-like_ окружении определяются свои допустимые риски связанные с различием с production окружением. -Ручной запуск pipeline предполагает: - - Нажатие кнопки в CI/CD системе (например Gitlab CI). - - Назначение label в CI/CD системе (например Gitlab CI или Github Actions). Label обычно назначается на pull request и снимается с pull request пользователем или автоматически CI/CD системой во время работы pipeline. - - Например, пользователь назначает label "run tests" на его pull request и CI/CD система автоматически запускает соответствующий pipeline. Во время работы этого pipeline label "run tests" снимается с pull request. Далее для перезапуска пользователь может опять назначить этот label. И т.д. - - Label используется как альтернатива кнопкам, либо в случаях когда кнопки не поддерживаются CI/CD системой (например, Github Actions). -Для review окружений назначение пользователем label является сигналом к активации review окружения, а его снятие (вручную/автоматом) — к деактивации. Вариант будет подробнее рассмотрен (далее)(#автоматом-для-pull-request-после-ручной-активации). - - Запрос через API CI/CD системы (например через HTTP по определённому url в Github Actions). +##### Staging -## Релизы и CI/CD +Staging — это окружение, в котором происходит финальная проверка перед выкатом на [production](#production). Staging даёт возможность полнее протестировать бизнес-функции приложения и обычно это то место, куда идут менеджеры, тестировщики, заказчики. -**Релиз** — это оформленная версия приложения с какими-то изменениями с момента предыдущего релиза. +В случае, если приложение связано с какими либо внешними сервисами, staging — это единственное окружение помимо [production](#production), где можно проверить как новая версия работает в связке с реальными версиями внешних систем. -В каскадном (или водопадном) подходе к разработке софта релизы обычно делаются редко и содержат множество изменений. Доставка таких релизов в окружения также происходит редко, но в этот момент все усилия команды тратятся на слежение за новой версией, исправление ошибок, проверку что всё прошло успешно. Обычно это отдельный и очень ответственный этап разработки, и пока он длится, новых изменений никто не делает (а если и делает, то пока нет возможности доставить их пользователю до нового релиза). Новая версия ещё не была проверена в реальной жизни, или была проверена тестами, но этого всё равно может быть недостаточно — с этим связаны большие риски, что новая версия приложения не заработает. +##### Testing -В CI/CD подходе релизы делаются часто, и релизы могут содержать мало изменений. Поощряется, чтобы разработчики разбивали новые фичи на такие куски, которые можно сразу обкатать на production-like или production окружениях. Более того, разработчики, которые прониклись таким подходом, сами хотят как можно быстрее пустить новый код в работу и получить обратную связь — после этого опираясь на проверенный код проще делаются новые изменения. До конца доделанным можно считать лишь тот код, который не только написан, но и задействован в production. +Testing — это окружение, цель которого: выявить возникшие у приложения проблемы на [production](#production) окружении. В данном окружении могут работать "долгие" автоматизированные тесты приложения, которые проверяют множество аспектов его работы. Чем больше различий между testing и production, тем больше рисков получить нерабочее приложение после очередного выката, поэтому рекомендуется максимально повторять production окружение (одинаковый софт, версии, библиотеки, IP-адреса и порты, железо и т.д.). -В дальнейших разделах мы определим возможные варианты конфигураций workflow и насколько каждый из них соответствует подходам CI/CD. +#### Review -## Окружения +Динамический (временный) контур, используемый разработчиками при разработке для оценки работоспособности написанного кода, первичной оценки работоспособности приложения и проведения таких экспериментов, которые нельзя делать на [production-like окружениях](#production-like). -### Production +Особенность review-окружений в том, что их можно создавать динамически в любых количествах (в разумных пределах, насколько позволяют ресурсы). Как правило, создание и удаление такого окружения инициируется разработчиком через CI/CD систему, также такое окружение может быть удалено автоматически после отсутствия активности в течение некоторого времени. -В этом окружении работает разрабатываемая система, это целевое окружение для всех изменений, которые делают разработчики системы. Этим окружением пользуются реальные пользователи в процессе эксплуатации системы. +### Релизы и CI/CD -Существуют также так называемые _production-like_ окружения, особенность которых в том, что конфигурация выделенных для окружения ресурсов (инфраструктура, конфигурация железа, версии софта, операционная система, сетевая организация), а также внешние сервисы — по максимуму насколько возможно совпадают с production окружением. Есть нюансы, из-за которых различия могут быть, но в каждом конкретном _production-like_ окружении определяются свои допустимые риски связанные с различием с production окружением. Примеры таких окружений: [staging](#staging) и [testing](#testing) — рассмотрены далее. +**Релиз** — это оформленная версия приложения с какими-то изменениями с момента предыдущего релиза. -### Staging +В каскадном (или водопадном) подходе к разработке софта релизы обычно делаются редко и содержат множество изменений. Доставка таких релизов в окружения также происходит редко, но в этот момент все усилия команды тратятся на слежение за новой версией, исправление ошибок, проверку, что всё прошло успешно. Обычно это отдельный и очень ответственный этап разработки, и пока он длится, новых изменений никто не делает (а если и делает, то пока нет возможности доставить их пользователю до нового релиза). Новая версия ещё не была проверена в реальной жизни, или была проверена тестами, но этого всё равно может быть недостаточно — с этим связаны большие риски, что новая версия приложения не заработает. -Staging — это [production-like окружение](#production), в котором происходит финальная проверка перед выкатом на [production](#production). Staging даёт возможность полнее протестировать бизнес-функции приложения и обычно это то место, куда идут менеджеры, тестировщики, заказчики. +В CI/CD подходе релизы делаются часто, и релизы могут содержать мало изменений. Поощряется, чтобы разработчики разбивали новые фичи на такие куски, которые можно сразу обкатать на production-like или production окружениях. Более того, разработчики, которые прониклись таким подходом, сами хотят как можно быстрее пустить новый код в работу и получить обратную связь — после этого опираясь на проверенный код проще делаются новые изменения. До конца доделанным можно считать лишь тот код, который не только написан, но и задействован в production. -В случае, если приложение связано с какими либо внешними сервисами, staging — это единственное окружение помимо [production](#production), где можно проверить как новая версия работает в связке с реальными версиями внешних систем. +В дальнейших разделах мы определим возможные варианты конфигураций workflow и насколько каждый из них соответствует подходам CI/CD. -### Testing +### Что такое pipeline и workflow -Testing — это [production-like окружение](#production), цель которого: выявить возникшие у приложения проблемы на [production](#production) окружении. В данном окружении могут работать "долгие" автоматизированные тесты приложения, которые проверяют множество аспектов его работы. Чем больше различий между testing и production, тем больше рисков получить нерабочее приложение после очередного выката, поэтому рекомендуется максимально повторять production окружение (одинаковый софт, версии, библиотеки, IP-адреса и порты, железо и т.д.). +С помощью git пользователь вносит изменения в кодовую базу проекта. Каждый коммит в гит активирует так называемый **pipeline** со стороны CI/CD системы. Pipeline разбит на стадии, которые могут запускаться последовательно или параллельно. -### Review +Главное назначение pipeline — донести внесённое в гит изменение до некоторого окружения. В случае непрохождения какой-то стадии pipeline прерывается и пользователь тем самым получает обратную связь. Коммит, который успешно проходит по всем необходимым стадиям попадает на некоторый контур/окружение. -Динамический (временный) контур, используемый разработчиками при разработке для оценки работоспособности написанного кода, первичной оценки работоспособности приложения и проведения таких экспериментов, которые нельзя делать на [production-like окружениях](#production). +Бывают следующие основные типы стадий: + - Build-and-Publish — сборка образов приложения и их публикация в хранилище образов. + - Deploy — непосредственно выкат приложения на контур. + - Cleanup — очистка неиспользуемых образов и связанного кеша из хранилища. -Особенность review-окружений в том, что их можно создавать динамически в любых количествах (в разумных пределах, насколько позволяют ресурсы). Как правило, создание и удаление такого окружения инициируется разработчиком через CI/CD систему, также такое окружение может быть удалено автоматически после отсутствия активности в течение некоторого времени. +#### Pull request -## Стадия тестирования +Пользователь вносит изменения в кодовую базу путём создания коммитов в git и pull request-ов в CI/CD системе. Обычно pull request — это сущность, которая связывает коммит в git и pipeline (а также позволяет делать review, оставлять комментарии и пр.). В разных CI/CD системах pull request может называться по-разному (Merge Request в GitLab CI) или вообще отсутствовать (Jenkins). -Для правильной организации CI/CD критично во время внесения изменений в кодовую базу проекта получать быструю обратную связь в автоматическом режиме с помощью тестов. Причём стадию тестирования можно разбить на 2 условных этапа: на первичном этапе тесты проходят быстро и покрывают большую часть функций, на вторичном этапе тесты могут работать долго и проверять больше аспектов приложение. Первичные тесты обычно запускаются автоматически и их прохождение является обязательным условием для допуска изменений к релизу. +#### Workflow -## Что читать дальше +Pipeline-ы и стадии внутри pipeline-ов могут быть активированы как автоматически, так и вручную. Способы активации pipeline-ов, их устройство, связь с гит, требуемые действия со стороны пользователя — всё это будет определяться так называемым workflow. +Возможно множество вариантов workflow для достижения одной и той же цели. Далее мы рассмотрим те варианты, которые можно реализовать с использованием werf. -Дальше рекомендуется ознакомиться с инструкцией по вашей CI/CD системе: - - Инструкция для [GitLab CI/CD]({{ "how_to/integration_with_ci_cd_systems/gitlab_ci_cd/workflows.html" | true_relative_url }}). - - Инструкция для [Github Actions]({{ "how_to/integration_with_ci_cd_systems/github_actions/workflows.html" | true_relative_url }}). +### Варианты ручного запуска pipeline -Если вы хотите узнать больше подробностей по методике составления workflow или для вашей CI/CD системы не нашлось инструкции, тогда можно ознакомится с дальнейшими разделами где определяются [составляющие workflow](#составляющие-workflow-для-отдельных-окружений) и [готовые конфигурации workflow](#готовые-конфигурации-workflow). После этого вы будете готовы выбрать готовую конфигурацию или составить свою и реализовать её для вашей CI/CD системы с использованием werf. +Ручной запуск pipeline предполагает: + - Нажатие кнопки в CI/CD системе (например Gitlab CI). + - Назначение label в CI/CD системе (например Gitlab CI или Github Actions). Label обычно назначается на pull request и снимается с pull request пользователем или автоматически CI/CD системой во время работы pipeline. + - Например, пользователь назначает label "run tests" на его pull request и CI/CD система автоматически запускает соответствующий pipeline. Во время работы этого pipeline label "run tests" снимается с pull request. Далее для перезапуска пользователь может опять назначить этот label. И т.д. + - Label используется как альтернатива кнопкам, либо в случаях когда кнопки не поддерживаются CI/CD системой (например, Github Actions). +Для review окружений назначение пользователем label является сигналом к активации review окружения, а его снятие (вручную/автоматом) — к деактивации. + - Запрос через API CI/CD системы (например через HTTP по определённому url в Github Actions). +### Стадия тестирования +Для правильной организации CI/CD критично во время внесения изменений в кодовую базу проекта получать быструю обратную связь в автоматическом режиме с помощью тестов. Причём стадию тестирования можно разбить на 2 условных этапа: на первичном этапе тесты проходят быстро и покрывают большую часть функций, на вторичном этапе тесты могут работать долго и проверять больше аспектов приложение. Первичные тесты обычно запускаются автоматически и их прохождение является обязательным условием для допуска изменений к релизу.