Add the document for the serialization field (#47)

* Add the document for serialization

* Embold essential sentence

* Reorder the fields of 'deploy.yml'

Author: Noah Lee

docs/concepts/deploy.yml.md

@@ -39,7 +39,7 @@ envs:
 
 ### Deployable Ref
 
-The `ref` can be any named branch, tag, or SHA. But sometimes, a `ref` must be specific branches or tags. You can verify a `ref` matched with the format by configuring the `deployable_ref` field. And this configuration also supports a regular expression.
+The `ref` can be any named branch, tag, or SHA. But sometimes, a `ref` must be specific branches or tags. **You can verify a `ref` matched with the regular expression** by configuring the `deployable_ref` field. 
 
 ```yaml title="deploy.yml"
 envs:
@@ -48,7 +48,7 @@ envs:
 ```
 
 ### Deploy Freeze Window
-If you want to prevent deployments for a particular period, such as during a planned vacation period or out of working time, you can configure the `frozen_windows` field. During a deploy freeze period, users can not execute any deployment. 
+**If you want to prevent deployments for a particular period**, such as during a planned vacation period or out of working time, you can configure the `frozen_windows` field. During a deploy freeze period, users can not execute any deployment. 
 
 And this configuration uses the cron expression to handle repetitive periods. You can check the detail in the [documentation](../references/deploy.yml.md).
 
@@ -66,8 +66,17 @@ envs:
         location: Asia/Seoul
 ```
 
+### Serialization
+**Serialization forces only one deployment to run for the same environment.** If deployment is running for a specific environment, users cannot deploy until the deployment is finished. In particular, serialization is helpful in long-running deployment strategies, such as canary deployments, as it prevents other deployments.
+
+```yaml title="deploy.yml"
+envs:
+  - name: production
+    serialization: true
+```
+
 ### Review
-If you require a specific person, such as a service owner or product manager, to review what is deployed before deployment, you can configure the `review` field. You can list up users as reviewers under the `review` field. Then Gitploy requests a review to users by sending a notification when a deployment is triggered.
+**If you require a specific person, such as a service owner or product manager, to review what is deployed before deployment**, you can configure the `review` field. You can list up users as reviewers under the `review` field. Then Gitploy requests a review to users by sending a notification when a deployment is triggered.
 
 ```yaml title="deploy.yml"
 envs:

docs/references/deploy.yml.md

@@ -17,15 +17,16 @@ Field                    |Type                     |Required  |Description
 `name`                   |*string*                 |`true`    |This field is the runtime environment such as `production`, `staging`, and `qa`. 
 `task`                   |*string*                 |`false`   |This field is used by the deployment system to distinguish the kind of deployment. Default is `deploy`. (*Only for GitHub*) 
 `description`            |*string*                 |`false`   |This field is the short description of the deployment. (*Only for GitHub*)
-`auto_merge`             |*boolean*                |`false`   |This field is used to ensure that the requested ref is not behind the repository's default branch. If the ref is behind the default branch for the repository, we will attempt to merge it for you. Default is `true`, but Gitploy set `false` for rollback. (*Only for GitHub*)
+`auto_merge`             |*boolean*                |`false`   |This field is used to ensure that the requested ref is not behind the repository's default branch. If the ref is behind the default branch for the repository, GitHub will attempt to merge it for you. Default is `true`, but Gitploy set `false` for rollback. (*Only for GitHub*)
 `required_contexts`      |*[]string*               |`false`   |This field allows you to specify a subset of contexts that must be success. Defaults to all unique contexts. (*Only for GitHub*)
 `payload`                |*object* or *string*     |`false`   |This field is JSON payload with extra information about the deployment. Default is `null`. (*Only for GitHub*)
-`dyanmic_payload`        |*[Dynamic Payload](#dynamic-payload)*     |`false`   |This field dynamically generates JSON payload about the deployment.(*Only for `GitHub`*)
+`dyanmic_payload`        |*[Dynamic Payload](#dynamic-payload)*     |`false`   |This field dynamically generates JSON payload about the deployment.(*Only for GitHub*)
 `production_environment` |*boolean*                |`false`   |This field specifies whether this runtime environment is production or not. Default is `true`.
-`deployable_ref`         |*string*                 |`false`   |This field specifies which the ref(branch, SHA, tag) is deployable or not. It supports the regular expression `re2`. 
 `auto_deploy_on`         |*string*                 |`false`   |This field controls auto-deployment behaviour given a ref(branch, SHA, tag). If any new push events are detected on this event, the deployment will be triggered. It supports the regular expression ([re2](https://github.com/google/re2/wiki/Syntax)). E.g. `refs/heads/main` or `refs/tags/v.*`
-`review`                 |*[Review](#review)*      |`false`   |This field configures reviewers.
+`deployable_ref`         |*string*                 |`false`   |This field specifies which the ref(branch, SHA, tag) is deployable or not. It supports the regular expression `re2`. 
 `frozen_windows`         |*[\][Frozen Window](#frozen-window)* |`false`   |This field configures to add a frozen window to prevent unintended deployment for the environment.
+`serialization`         |*boolean*                 |`false`   |This field forces only one deployment to run for the environment.
+`review`                 |*[Review](#review)*      |`false`   |This field configures reviewers.
 
 ## Review