From 885d42332d614537b43c637ea82c989592ac9fd1 Mon Sep 17 00:00:00 2001 From: guoguangwu Date: Fri, 10 Nov 2023 15:48:27 +0800 Subject: [PATCH] fix: typo Signed-off-by: guoguangwu --- docs/rfcs/0007-deployment-chain.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rfcs/0007-deployment-chain.md b/docs/rfcs/0007-deployment-chain.md index 78479ff3df..8c18768eb3 100644 --- a/docs/rfcs/0007-deployment-chain.md +++ b/docs/rfcs/0007-deployment-chain.md @@ -23,7 +23,7 @@ Use-case <3>: chain of deployments contains application deployed across multiple All the above requirements share the same thing in the context, that is: it can be done by users' deployment for their applications as PipeCD applications one by one and make trigger those deployments manually via console or make trigger via pull requests to those application configurations separately, but this all manual stub are tedious and difficult to manage smoothly. With this new __PipeCD deployment chain__ feature, all of those manual steps will be replaced, to keep the good point of using a CD system. # Detailed design -The idea is to keep the PipeCD application deployment as a unit of deployment as is, but add __a way to enable users to manipulate a deployment chain based on the state of the last sucessfully run deployment__. +The idea is to keep the PipeCD application deployment as a unit of deployment as is, but add __a way to enable users to manipulate a deployment chain based on the state of the last successfully run deployment__. A canonical flow would look as below: 1. Users trigger to run their first application (the first application in their deployment chain) via the web console or pull requests as usual