diff --git a/content/docs/0.8.x/automated_operations/remediation/index.md b/content/docs/0.8.x/automated_operations/remediation/index.md index 8b5f77de2..a5ea3228a 100644 --- a/content/docs/0.8.x/automated_operations/remediation/index.md +++ b/content/docs/0.8.x/automated_operations/remediation/index.md @@ -8,6 +8,38 @@ keywords: [0.8.x-automated-operations] The remediation config describes a remediation workflow in a declarative manner. Hence, it only defines what needs to be done and leaves all the details to other components. +## Declare a remediation sequence in shipyard + +The definition of a remediation sequence is done in a so-called [Shipyard](../../manage/shipyard) file. + +**Example**: Simple shipyard file with a remediation sequence in a single stage +```yaml +apiVersion: "spec.keptn.sh/0.2.0" +kind: "Shipyard" +metadata: + name: "shipyard-sockshop" +spec: + stages: + - name: "production" + sequences: + - name: "remediation" + triggeredOn: + - event: "production.remediation.finished" + selector: + match: + evaluation.result: "fail" + tasks: + - name: "get-action" + - name: "action" + - name: "evaluation" + triggeredAfter: "10m" + properties: + timeframe: "10m" +``` + +*Note*: Remediations can also be used in combination with [multi stage delivery](../../continuous_delivery/multi_stage) workflows. + + ## Configure Remediation Below is an example of a declarative remediation config: @@ -96,4 +128,4 @@ spec: ```console keptn add-resource --project=sockshop --stage=production --service=serviceXYZ --resource=remediation.yaml --resourceUri=remediation.yaml - ``` \ No newline at end of file + ``` diff --git a/content/docs/0.8.x/continuous_delivery/multi_stage/index.md b/content/docs/0.8.x/continuous_delivery/multi_stage/index.md index c077ea391..e7c10f244 100644 --- a/content/docs/0.8.x/continuous_delivery/multi_stage/index.md +++ b/content/docs/0.8.x/continuous_delivery/multi_stage/index.md @@ -5,23 +5,13 @@ weight: 1 keywords: [0.8.x-cd] --- -The definition of a multi-stage delivery manifests in a so-called **shipyard**. It can hold multiple stages with dedicated and opinionated delivery tasks to execute. Following this declarative approach, there is no need to write imperative pipeline code. Keptn takes the shipyard and creates a sequence for multi-stage delivery. -## Declare Shipyard (before creating a project) -* A shipyard is defined at the level of a project. This means that all services in a project share the same shipyard definition. +## Declare a multi-stage delivery sequence in shipyard -* A shipyard defines the stages each deployment has to go through until it is released in the final stage, e.g., the production stage. +The definition of a multi-stage delivery manifests in a so-called [Shipyard](../../manage/shipyard) file. It can hold multiple stages with dedicated and opinionated delivery tasks to execute. -* A shipyard can consist of any number of stages; but at least one. A stage must have at least the name property. - -* A stage can consist of any number of sequences; but at least one. - -### Definition of Stage - -A stage is declared by its name. This name will be used for the branch in the Git repository and Kubernetes namespace to which services at this stage will be deployed to. - -**Example of a shipyard with three stages:** +**Example**: Simple shipyard file with a delivery sequence in the two stages `dev` and `production`, whereas `dev` uses a direct deployment and `prod` uses blue-green deployment: ```yaml apiVersion: spec.keptn.sh/0.2.0 @@ -31,19 +21,27 @@ metadata: spec: stages: - name: "dev" - - name: "hardening" + sequences: + - name: "delivery" + tasks: + - name: "deployment" + properties: + deploymentstrategy: "direct" + - name: "release" + - name: "production" + sequences: + - name: "delivery" + triggeredOn: + - event: "dev.delivery.finished" + tasks: + - name: "deployment" + properties: + deploymentstrategy: "blue_green_service" + - name: "release" ``` -### Definition of Sequence in a Stage - -After defining stages, sequences can be added to a stage. A sequence is an ordered list of tasks that are triggered sequentially. A `sequence` consists of the following properties: - -* `name`: A unique name of the sequence -* `on` (optional): An array of events that trigger the sequence. -* `tasks`: An array of tasks executed by the sequence in the declared order. - -**Example:** Extended shipyard with a delivery sequence in all three stage: +**Example:** Extended shipyard with a delivery sequence in three stages `dev`, `hardening` and `production` in combination with tests: ```yaml apiVersion: spec.keptn.sh/0.2.0 @@ -57,7 +55,14 @@ spec: - name: "delivery" tasks: - name: "deployment" + properties: + deploymentstrategy: "direct" + - name: "test" + properties: + teststrategy: "functional" + - name: "evaluation" - name: "release" + - name: "hardening" sequences: - name: "delivery" @@ -65,7 +70,14 @@ spec: - event: "dev.delivery.finished" tasks: - name: "deployment" + properties: + deploymentstrategy: "blue_green_service" + - name: "test" + properties: + teststrategy: "functional" + - name: "evaluation" - name: "release" + - name: "production" sequences: - name: "delivery" @@ -73,51 +85,12 @@ spec: - event: "hardening.delivery.finished" tasks: - name: "deployment" + properties: + deploymentstrategy: "blue_green_service" - name: "release" ``` -### Reserved Keptn Tasks - -Keptn supports a set of opinionated tasks for declaring a delivery or remediation sequence: - -* approval -* deployment -* evaluation -* release -* remediation -* rollback -* test - -#### Approval - -The approval task intercepts the sequence and waits for a required approval (e.g., before deploying an artifact into the next stage). The approval strategy can be defined based on the evaluation result `pass` and `warning`. Keptn supports the following approval strategies for the evaluation results `pass` and `warning`: - - * `automatic`: The artifact is deployed automatically. - * `manual`: The user is asked for approval before triggering the deployment. - -This allows combinations as follows: - -| | Evaluation result: pass | Evaluation result: warning | Behavior | -|--------------------------|-----------------------------------|--------------------------------------------|-----------| -| **Skip approval task:** | pass:automatic | warning:automatic | Regardless of the evaluation result, the approval task is skipped | -| **Depending on evaluation result:** | pass:automatic | warning:manual | If the evaluation result is a **warning**, an approval is required | -| **Depending on evaluation result:** | pass:manual | warning:automatic | If the evaluation result is a **pass**, an approval is required | -| **Mandatory approval task:** | pass:manual | warning:manual | Regardless of the evaluation result, an approval is required | - -Per default, an `automatic` approval strategy is used for evaluation result `pass` and `warning`. - -**Usage:** - -``` -- name: approval - properties: - pass: automatic - warning: manual -``` - -
**Example:** Extended shipyard with a mandatory approval task in production - -

+**Example:** Extended shipyard with two delivery sequence with varying deployment strategies (e.g., `delivery` is used for a Java-service, whereas `delivery-direct` is used for a database): ```yaml apiVersion: spec.keptn.sh/0.2.0 @@ -129,176 +102,20 @@ spec: - name: "production" sequences: - name: "delivery" - tasks: - - name: "deployment" - - name: "approval" - properties: - pass: "manual" - warning: "manual" - - name: "release" -``` - -

-
- -#### Deployment - -Defines the deployment strategy used to deploy a new version of a service. Keptn supports deployment strategies of type: - - * `direct`: Deploys a new version of a service by replacing the old version of the service. - * `blue_green_service`: Deploys a new version of a service next to the old one. After a successful validation of this new version, it replaces the old one and is marked as stable (i.e., it becomes the `primary`-version). - -**Usage:** - -``` -- name: deployment - properties: - deploymentstrategy: blue_green_service -``` - -
**Example:** Extended shipyard with direct deployment in dev and blue/green deployment in hardening and production - - -

- -```yaml -apiVersion: spec.keptn.sh/0.2.0 -kind: "Shipyard" -metadata: - name: "shipyard-sockshop" -spec: - stages: - - name: "dev" - sequences: - - name: "delivery" - tasks: - - name: "deployment" - properties: - deploymentstrategy: "direct" - - name: "evaluation" - - name: "release" - - - name: "hardening" - sequences: - - name: "delivery" - triggeredOn: - - event: "dev.delivery.finished" - tasks: - - name: "deployment" - properties: - deploymentstrategy: "blue_green_service" - - name: "evaluation" - - name: "release" - - - name: "production" - sequences: - - name: "delivery" - triggeredOn: - - event: "staging.delivery.finished" tasks: - name: "deployment" properties: deploymentstrategy: "blue_green_service" - name: "release" -``` - -

-
-#### Evaluation - -Defines the quality evaluation that is executed to verify the quality of a deployment based on its SLOs/SLIs. - -**Usage:** -``` -- name: evaluation -``` - -#### Release - -Defines the releasing task that is executed after a successful deployment happened. This means that production traffic is shifted towards the new deployment in this task. - -**Usage:** -``` -- name: release -``` - -#### Remediation - -Defines whether remediation actions are enabled or not. - -**Usage:** -``` -- name: remediation -``` - -#### Rollback - -Defines the rollback task that is executed when a rollback shall be triggered. - -**Usage:** -``` -- name: rollback -``` - -#### Test - -Defines the test strategy used to validate a deployment. Keptn supports tests of type: - - * `functional`: Test a deployment based on functional tests. - * `performance`: Test a deployment based on performance/load tests. - -**Usage:** -``` -- name: test - properties: - teststrategy: functional -``` - -
**Example:** Extended shipyard with functional tests in dev and performance tests in hardening - - -

- -```yaml -apiVersion: spec.keptn.sh/0.2.0 -kind: "Shipyard" -metadata: - name: "shipyard-sockshop" -spec: - stages: - - name: "dev" - sequences: - - name: "delivery" + - name: "delivery-direct" tasks: - name: "deployment" properties: deploymentstrategy: "direct" - - name: "test" - properties: - teststrategy: "functional" - - name: "evaluation" - name: "release" +``` - - name: "staging" - sequences: - - name: "delivery" - triggeredOn: - - event: "dev.delivery.finished" - tasks: - - name: "deployment" - properties: - deploymentstrategy: "blue_green_service" - - name: "test" - properties: - teststrategy: "performance" - - name: "evaluation" - - name: "release" - -``` - -

-
## Create project with multi-stage delivery diff --git a/content/docs/0.8.x/manage/project/index.md b/content/docs/0.8.x/manage/project/index.md index be0e84416..c8947c309 100644 --- a/content/docs/0.8.x/manage/project/index.md +++ b/content/docs/0.8.x/manage/project/index.md @@ -6,14 +6,16 @@ keywords: [0.8.x-manage] aliases: --- -In Keptn, a project is a structure that allows organizing your services. A project is stored as a repository and contains branches representing the multi-stage environment (e.g., dev, staging, and production stage). In other words, the separation of stage configurations is based on repository branches. +In Keptn, a project is a structure that allows organizing your services. A project is stored as a git repository and contains branches representing the multi-stage environment (e.g., dev, staging, and production stage). +In other words, the separation of stage configurations is based on git repository branches. ## Create a project -To describe the stages of a project, a **shipyard** is needed that specifies multi-stage delivery workflow as shown by an example below. +To create a project, you can use the CLI command [keptn create project](../../reference/cli/commands/keptn_create_project) and pass a shipyard file. -**Note:** To learn more about a shipyard, see [declare shipyard before creating a project](../../continuous_delivery/multi_stage/#declare-shipyard-before-creating-a-project). +**Note**: To learn more about the shipyard specification, please have a look at [shipyard section](../shipyard/) and the [the Keptn spec](https://github.com/keptn/spec/blob/0.2.1/shipyard.md). +The simplest shipyard.yaml file with a single stage and no sequences defined would look like this: ```yaml apiVersion: spec.keptn.sh/0.2.0 kind: "Shipyard" @@ -21,50 +23,14 @@ metadata: name: "shipyard-sockshop" spec: stages: - - name: "dev" - sequences: - - name: "delivery" - tasks: - - name: "deployment" - properties: - deploymentstrategy: "direct" - - name: "test" - properties: - teststrategy: "functional" - - name: "evaluation" - - name: "release" - - - name: "staging" - sequences: - - name: "delivery" - triggers: - - "dev.delivery.finished" - tasks: - - name: "deployment" - properties: - deploymentstrategy: "blue_green_service" - - name: "test" - properties: - teststrategy: "performance" - - name: "evaluation" - - name: "release" - - - name: "production" - sequences: - - name: "delivery" - triggers: - - "staging.delivery.finished" - tasks: - - name: "deployment" - properties: - deploymentstrategy: "blue_green_service" - - name: "release" + - name: "single-stage" ``` * **Recommended approach for Keptn in production:** Create a project with the Keptn CLI using a Git upstream: ```console keptn create project PROJECTNAME --shipyard=FILEPATH --git-user=GIT_USER --git-token=GIT_TOKEN --git-remote-url=GIT_REMOTE_URL ``` + See [Git based upstream](../../manage/git_upstream/) for more information. * **Demo/Lab setting:** Create a project with the Keptn CLI without a Git upstream and **no** backup: ```console @@ -82,4 +48,28 @@ To delete a Keptn project, the [keptn delete project](../../reference/cli/comman ## Update a project -Updating a project is currently supported by following the steps of [deleting a project](#delete-a-project) and [creating the project](#create-a-project) with updated settings. +Updating a project can either be achieved by [deleting a project](#delete-a-project) and [creating the project](#create-a-project) with updated settings, or by adapting it directly in the Git *upstream* repository. + +* If you do not have a Git upstream set for your project, please set one since it is the recommended way of using Keptn: [configure Git upstream](../../manage/git_upstream/#create-keptn-project-or-set-git-upstream). + +* If you do not have a Git repository to set an *upstream*, you can update the shipyard using: + + ``` + keptn add-resource --project=PROJECT --resource=./shipyard.yaml --resourceUri=./shipyard.yaml + ``` + +:warning: Only modify your shipyard in ways mentioned in this section. + +:warning: Make sure to have no running sequence while you are updating the shipyard. Otherwise, running sequences will be updated. + +The following updates of shipyard.yaml are currently supported by Keptn: + +* Add/Remove a task to/from a task sequence +* Add/Remove a task sequence to/from a stage +* Define a trigger for a sequence + +In contrast, the following updates are not supported by Keptn: + +* Add/Remove a stage + +Please have a look at the [shipyard section](../shipyard/#updating-a-shipyard) for more information regarding updating a shiypard file. diff --git a/content/docs/0.8.x/manage/shipyard/index.md b/content/docs/0.8.x/manage/shipyard/index.md index 962f699f5..e16198404 100644 --- a/content/docs/0.8.x/manage/shipyard/index.md +++ b/content/docs/0.8.x/manage/shipyard/index.md @@ -1,29 +1,308 @@ --- -title: Customize a Shipyard -description: Adapt the Shipyard depending on your processes. +title: Shipyard +description: Information about shipyard, sequences and tasks to define processes and workflows. weight: 25 keywords: [0.8.x-manage] aliases: --- -After creating a project, you can change the shipyard as explained here. +## Declare Shipyard (before creating a project) -The most convenient way to change your shipyard is by directly adapting it in the Git *upstream* repository. +* A shipyard is defined at the level of a project. This means that all services in a project share the same shipyard definition. -* If you do not have a Git upstream set for your project, please set one since it is the recommended way of using Keptn: [configure Git upstream](../../manage/git_upstream/#create-keptn-project-or-set-git-upstream). +* A shipyard defines the stages each deployment has to go through until it is released in the final stage, e.g., the production stage. -* If you do not have a Git repository to set an *upstream*, you can update the shipyard using: +* A shipyard can consist of any number of stages; but at least one. A stage must have at least the name property. - ``` - keptn add-resource --project=PROJECT --resource=./shipyard.yaml --resourceUri=./shipyard.yaml - ``` +* A stage can consist of any number of sequences; but at least one. -:warning: Only modify your shipyard in ways mentioned in this section. -:warning: Make sure to have no running sequence while you are updating the shipyard. Otherwise, running sequences will be updated. +### Definition of Stage +A stage is declared by its name. This name will be used for the branch in the Git repository and Kubernetes namespace to which services at this stage will be deployed to. -## Add/Remove a task to/from a task sequence +**Example of a shipyard with three stages:** + +```yaml +apiVersion: spec.keptn.sh/0.2.0 +kind: "Shipyard" +metadata: + name: "shipyard-sockshop" +spec: + stages: + - name: "dev" + - name: "hardening" + - name: "production" +``` + +### Definition of Sequence in a Stage + +After defining stages, sequences can be added to a stage. A sequence is an ordered list of tasks that are triggered sequentially. A `sequence` consists of the following properties: + +* `name`: A unique name of the sequence +* `triggeredOn` (optional): An array of events that trigger the sequence. +* `tasks`: An array of tasks executed by the sequence in the declared order. + +**Example:** Extended shipyard with a delivery sequence in all three stage: + +```yaml +apiVersion: spec.keptn.sh/0.2.0 +kind: "Shipyard" +metadata: + name: "shipyard-sockshop" +spec: + stages: + - name: "dev" + sequences: + - name: "delivery" + tasks: + - name: "deployment" + - name: "release" + + - name: "hardening" + sequences: + - name: "delivery" + triggeredOn: + - event: "dev.delivery.finished" + tasks: + - name: "deployment" + - name: "release" + + - name: "production" + sequences: + - name: "delivery" + triggeredOn: + - event: "hardening.delivery.finished" + tasks: + - name: "deployment" + - name: "release" +``` + +### Reserved Keptn Tasks + +Keptn supports a set of opinionated tasks for declaring a delivery or remediation sequence: + +* action +* approval +* deployment +* evaluation +* get-action +* release +* rollback +* test + + +#### Action + +The action task indicates that a remediation action should be executed by an action provider. It is used within a [remediation workflow](../../automated_operations/remediation). + +**Usage:** + +``` +- name: action +``` + +#### Approval + +The approval task intercepts the sequence and waits for a required approval (e.g., before deploying an artifact into the next stage). The approval strategy can be defined based on the evaluation result `pass` and `warning`. Keptn supports the following approval strategies for the evaluation results `pass` and `warning`: + +* `automatic`: The artifact is deployed automatically. +* `manual`: The user is asked for approval before triggering the deployment. + +This allows combinations as follows: + +| | Evaluation result: pass | Evaluation result: warning | Behavior | +|--------------------------|-----------------------------------|--------------------------------------------|-----------| +| **Skip approval task:** | pass:automatic | warning:automatic | Regardless of the evaluation result, the approval task is skipped | +| **Depending on evaluation result:** | pass:automatic | warning:manual | If the evaluation result is a **warning**, an approval is required | +| **Depending on evaluation result:** | pass:manual | warning:automatic | If the evaluation result is a **pass**, an approval is required | +| **Mandatory approval task:** | pass:manual | warning:manual | Regardless of the evaluation result, an approval is required | + +Per default, an `automatic` approval strategy is used for evaluation result `pass` and `warning`. + +**Usage:** + +``` +- name: approval + properties: + pass: automatic + warning: manual +``` + +
**Example:** Extended shipyard with a mandatory approval task in production + +

+ +```yaml +apiVersion: spec.keptn.sh/0.2.0 +kind: "Shipyard" +metadata: + name: "shipyard-sockshop" +spec: + stages: + - name: "production" + sequences: + - name: "delivery" + tasks: + - name: "deployment" + - name: "approval" + properties: + pass: "manual" + warning: "manual" + - name: "release" +``` + +

+
+ +#### Deployment + +Defines the deployment strategy (see [Continuous Delivery](../../continuous_delivery/)) used to deploy a new version of a service. Keptn supports deployment strategies of type: + +* `direct`: Deploys a new version of a service by replacing the old version of the service. +* `blue_green_service`: Deploys a new version of a service next to the old one. After a successful validation of this new version, it replaces the old one and is marked as stable (i.e., it becomes the `primary`-version). +* `user_managed` (experimental): Deploys a new version of a service by fetching the current helm-chart from the git repo, and just updating certain values. + +**Usage:** + +``` +- name: deployment + properties: + deploymentstrategy: blue_green_service +``` + +``` +- name: deployment + properties: + deploymentstrategy: direct +``` + +``` +- name: deployment + properties: + deploymentstrategy: user_managed +``` + +#### Evaluation + +Defines the quality evaluation that is executed to verify the quality of a deployment based on its SLOs/SLIs. + +**Usage:** +``` +- name: evaluation +``` + +#### Get-Action + +The get-action task is used to extract the desired remediation action from a remediation.yaml within a [remediation workflow](../../automated_operations/remediation). + +**Usage:** + +``` +- name: get-action +``` + +#### Release + +Defines the releasing task that is executed after a successful deployment happened. This means that production traffic is shifted towards the new deployment in this task. + +**Usage:** +``` +- name: release +``` + +#### Get-Action + +Defines the task to retrieve the next remediation action. + +**Usage:** +``` +- name: get-action +``` + +#### Action + +Defines the execution of a remediation action retrieved by `get-action`. + +**Usage:** +``` +- name: action +``` + +#### Rollback + +Defines the rollback task that is executed when a rollback shall be triggered. + +**Usage:** +``` +- name: rollback +``` + +#### Test + +Defines the test strategy used to validate a deployment. Keptn supports tests of type: + +* `functional`: Test a deployment based on functional tests. +* `performance`: Test a deployment based on performance/load tests. + +**Usage:** +``` +- name: test + properties: + teststrategy: functional +``` + +
**Example:** Extended shipyard with functional tests in dev and performance tests in hardening + + +

+ +```yaml +apiVersion: spec.keptn.sh/0.2.0 +kind: "Shipyard" +metadata: + name: "shipyard-sockshop" +spec: + stages: + - name: "dev" + sequences: + - name: "delivery" + tasks: + - name: "deployment" + properties: + deploymentstrategy: "direct" + - name: "test" + properties: + teststrategy: "functional" + - name: "evaluation" + - name: "release" + + - name: "staging" + sequences: + - name: "delivery" + triggeredOn: + - event: "dev.delivery.finished" + tasks: + - name: "deployment" + properties: + deploymentstrategy: "blue_green_service" + - name: "test" + properties: + teststrategy: "performance" + - name: "evaluation" + - name: "release" + +``` + +

+
+ + +## Updating a Shipyard + +This section provides examples on how to update a shipyard file. + +### Add/Remove a task to/from a task sequence If you want to add or remove an additional task to a sequence, you can do this by adding/removing the task directly in the shipyard: @@ -78,7 +357,7 @@ spec: **Result:** The next time this sequence gets triggered by Keptn, the task will be executed meaning that a `sh.keptn.event.[task].triggered` event is sent out. Make sure to have a Keptn-service that listens to this event type and can execute it. -## Add/Remove a task sequence to/from a stage +### Add/Remove a task sequence to/from a stage If you want to add or remove an additional task sequence to a stage, you can do this by adding/removing the sequence directly in the shipyard: @@ -105,7 +384,7 @@ spec: - name: "release" ``` -**Use-case:** I would like to add an additional delivery process to the production stage that allows rolling-out a hotfix without testing and evaluation. +**Use-case 1:** I would like to add an additional delivery process to the production stage that allows rolling-out a hotfix without testing and evaluation. *Updated shipyard:* @@ -143,7 +422,49 @@ spec: keptn trigger delivery --project= --service= --image= --tag= --sequence=hotfix-delivery ``` -## Define a trigger for a sequence +**Use-case 2:** I would like to add a remediation sequence to the production stage that allows executing remediation actions when problems occur. + +*Updated shipyard:* + +``` +apiVersion: "spec.keptn.sh/0.2.0" +kind: "Shipyard" +metadata: + name: "shipyard-sockshop" +spec: + stages: + - name: "production" + sequences: + - name: "delivery" + tasks: + - name: "deployment" + properties: + deploymentstrategy: "blue_green_service" + - name: "test" + properties: + teststrategy: "functional" + - name: "evaluation" + - name: "release" + + + - name: "remediation" + triggeredOn: + - event: "production.remediation.finished" + selector: + match: + evaluation.result: "fail" + tasks: + - name: "get-action" + - name: "action" + - name: "evaluation" + triggeredAfter: "10m" + properties: + timeframe: "10m" +``` + +**Result:** After extending the shipyard as shown above, remediations should be executed when a problem event is retrieved (see [remediation workflow](../../automated_operations/remediation)). + +### Define a trigger for a sequence An advanced and powerful feature of the shipyard is that you can define *triggers* to kick-off a sequence. Therefore, a sequence offers the `triggeredOn` property where a list of events can be specified. The event type you can list there are events that refer to the status of a sequence execution. Their name follows the pattern: diff --git a/content/docs/0.8.x/quality_gates/get_started/index.md b/content/docs/0.8.x/quality_gates/get_started/index.md index 8f72002ec..b328b85c3 100644 --- a/content/docs/0.8.x/quality_gates/get_started/index.md +++ b/content/docs/0.8.x/quality_gates/get_started/index.md @@ -50,7 +50,7 @@ For the `easyBooking` application, the Keptn entities of a project, stage, and s * `stage`: *quality_assurance* * `service`: *booking* & *payment* (For the sake of simplicity, a quality gate will be configured for `booking` only.) -For defining the stage(s) but also the tasks a service has to go through, a [Shipyard](../../continuous_delivery/multi_stage/#declare-shipyard-before-creating-a-project) file is needed. Since a quality gate should be configured for the *quality_assurance* environment only, the corresponding Shipyard for the *easyBooking* project looks as follows: +For defining the stage(s) but also the tasks a service has to go through, a [Shipyard](../../manage/shipyard) file is needed. Since a quality gate should be configured for the *quality_assurance* environment only, the corresponding Shipyard for the *easyBooking* project looks as follows: ```yaml apiVersion: "spec.keptn.sh/0.2.0"