docs(cd): improve description for continuous deployment

README.md

@@ -53,7 +53,8 @@ We strongly recommend you configure your editor to match our coding styles. You
 
 ## Deployment
 
+### Release to Production
 For site administrators, please refer to [document/deploy_docker_prod.md](/document/deploy_docker_prod.md).
 
 ### Continuous Deployment
-Currently this is only for continuous deployment on staging server, please refer to [document/continuous_deployment.md](/document/continuous_deployment.md).
+Currently, continuous deployment is only integrated on PyCon's staging server, please refer to [document/continuous_deployment.md](/document/continuous_deployment.md) for the setup.

document/continuous_deployment.md

@@ -2,6 +2,33 @@
 
 The following describes how to setup continuous deployment for staging server. This setup presumes the site administrators have site deployment practices based on the docker production deployment [document/deploy_docker_prod.md](/document/deploy_docker_prod.md).
 
+# Introduction of CI/CD, GitHub Actions, Ansible and related settings
+Continuous integration (CI)
+- Refers to the build and unit testing stages of the software release process. Every revision that is committed triggers an automated build and test.
+
+Continuous delivery / Continuous Deployment (CD)
+- Usually as the next step for Continuous Integration, the code revision is built and tested in the application is automatically released to the production environment.
+
+GitHub Actions
+- A CI/CD platform or service provided by GitHub. It provides public runners with limited compute minutes to run CI/CD workflows defined at `.github/workflows` directory. We can also provision custom Github Actions runner to perform CI/CD task.
+
+Ansible
+- An automation tool that utilize *playbook* and *inventory* to manage production servers (nodes), such as sending commands, file transfers, system maintenance without manually setup via SSH/Remote session for it.
+
+Github Settings for secrets and variables
+- CI/CD workflows for Github Actions often obtain sensitive information, credentials or variable. In project settings, Github provides secrets vault and variable holder to store these information in the secure manner and able to retrieve and use these values when the workflows run.
+
+## High level comparison of CI/CD in this project
+| Conventional - Release | Github Actions + Ansible - Release |
+|-----------|------------|
+| `ENV` values managed by site admin | `ENV` values are set in project settings (secrets) |
+| Site admin solely manage the production server | Site admin gives rights to github actions to deploy release to the production server |
+| Site admin knows every deployment steps for docker | Deployment steps are defined in Ansible playbook (so everyone can understand deployment steps) |
+| Site admin runs commands in a SSH session | Ansible runs the commands to server as defined by the playbook |
+| Only admins have the server IP and private key | Server IP and private key are securely kept at github settings |
+| Release is manual | Release automatically once code merges to `master` branch |
+| Things are executed by hands | Things are executed by Github Actions' runner |
+
 ## Requirements for Staging Server
 The staging server should have the following installed:
 - Docker 17.09+ (since we use `--chown` flag in the COPY directive)
@@ -42,7 +69,7 @@ Reference
  - `base64 -i key.pem` (mac)
  - `cat key.pem | base64` (linux)
 
-## Review
+## CD Workflow Rules
 ### Events that triggers the pipeline
 1. When the PR merges to `master`
  - no authorization needed, as PRs normally reviewed before merge