You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/concepts/deployment.md
+18-10Lines changed: 18 additions & 10 deletions
Original file line number
Diff line number
Diff line change
@@ -4,22 +4,30 @@ sidebar_position: 3
4
4
5
5
# Deployment
6
6
7
-
Gitploy provides two types of deployment: Deploy and Rollback.
7
+
## Deploy & Rollback
8
8
9
-
## Deploy
9
+
### Deploy
10
+
**Gitploy provides an intuitive UI that allows users to deploy a specific `ref`.** The UI provides three types of `ref`: *commit*, *branch*, and *tag*. The UI shows a list of options for each type. For example, the UI shows the current commit list with information such as SHA, description, committer if the user selects a commit.
10
11
11
-
Deploying is the primary feature of Gitploy. When you deploy, you have to select the environment and the reference. You can choose one of the environments defined in the configuration file (i.e. `deploy.yml`). You can select a commit, branch, or tag for reference.
12
+
When the user selects `ref`, an icon indicating the commit's status appears on the right, and you can check the subset of contexts by clicking the icon. This information can be handy if you use the `required_contexts` field, which specifies a subset of contexts that must be `success`.
12
13
13
-
When you deploy the ref, Gitploy post the deployment to GitHub, and Github dispatch the event to external services.
14
+
After that, when you click the deploy button, Gitploy sends a deployment request to GitHub. The selected `ref` is used as a request parameter when requesting. And other parameters are filled with `deploy.yml` field values.
14
15
15
-

16
+

16
17
17
-
## Rollback
18
+
### Rollback
19
+
We generally run `git revert` and merge the code to roll back. But in this process, we must wait for CI for a long time, which causes an impact on users. Therefore, the rollback must be done quickly and accurately.
18
20
19
-
Rollback is the best way to recover while you fix the problems, and Gitploy supports the rollback. You can choose one of the deployed references for the environment to roll back.
21
+
**Gitploy provides a quick and easy one-click rollback.** The UI shows a list of completed deployments of which status is `success` when the user selects a runtime environment. And the first option is just the previous deployment.
20
22
21
-
When you roll back to the specific reference, Gitploy posts a new deployment with the reference from the rollbacked deployment. *Note that if the reference of the rollbacked deployment is a branch, Gitploy automatically references the commit SHA to avoid deploying the head of the branch.*
23
+
After that, when the user clicks rollback, Gitploy fetches the payload from the previous deployment and sends a deployment request with the payload to Github. The `ref`from the previous distribution is used in this case. *However, if the ref of the previous deployment is a branch, Gitploy uses SHA to prevent the head of the branch from being deployed.* And `auto_merge: false` is set internally to avoid merge conflicts when rollback.
22
24
23
-
For best practice, you should lock the environment to block deploying by others until finishing to fix the problems. Gitploy provide the 'lock' feature in UI and Chatops.
24
25
25
-

26
+

27
+
28
+
## Deployment Status
29
+
Gitploy provides the UI to view the status after deployment. If you click `View Detail` of the deployment history on the Home tab, the link will take you to the page.
30
+
31
+
The page allows you to follow up on the changes through the status field. Each status has a description, update time, and a `View` link. The `View` link, when clicked, takes you directly to a deployment tooling and displays details.
0 commit comments