Github continuous deployment (CD) best practices-Alibaba Cloud Developer Community

You can use GitHub to create a custom continuous deployment (CD) workflow in the GitHub repository.

About continuous deployment

continuous Deployment (CD) uses automation to publish and deploy software updates. As part of a typical CD process, the code is automatically built and tested before deployment.

Continuous deployment is usually combined with continuous integration. For more information about continuous integration see about continuous integration ".

About continuous deployment using GitHub Actions

you can set up GitHub operation workflow to deploy your software products. To verify that your product works as expected, your workflow can build code in your repository and run your tests before deployment.

You can configure the CD workflow when GitHub events occur (for example, when new code is pushed to the default branch of the repository), as scheduled, run it manually or when an external event occurs Webhook using the repository scheduling. For more information about when a workflow can be run see events that trigger a workflow ".

The features provided by GitHub Actions allow you to better control deployment. For example, you can use environments to require approval of jobs to continue, restrict which branches can trigger workflows, or restrict access to secrets. You can use concurrency to limit a CD pipeline to a maximum of one ongoing deployment and one pending deployment. For more information about these features, see deploy with GitHub operations and deploy with environment ".

Using environments for deployment

you can use protection rules and secrets to configure the environment. Before running or accessing environment secrets, workflow jobs that reference the environment must comply with any environment protection rules.

What are environments?

The environment is used to describe general deployment targets, such as production, temporary storage, or development. When GitHub Actions workflow is deployed to the environment, the environment is displayed on the repository home page. For more information about viewing deployment environments, see View deployment history ".

You can use protection rules and secrets to configure the environment. When a workflow job references an environment, the job will not start until all environmental protection rules are passed. The job cannot access the secrets defined in the environment until all environmental protection rules are passed.

Environment protection rules

environmental protection rules require specific conditions to continue operations that reference the environment. You can use environmental protection rules to require manual approval, delay operations, or restrict the environment to certain branches.

Required reviewers

use the required reviewers to require specific personnel or teams to approve workflow jobs that reference the environment. You can list up to six users or teams as reviewers. The reviewer must have at least the read permission on the repository. Only a required reviewer needs to approve the job to continue.

Environment secrets

secrets stored in the environment can only be used to reference workflow jobs in the environment. If the environment requires approval, the job cannot access environment secrets until one of the required reviewers approves.

Using an environment

each job in a workflow can reference an environment. Before sending jobs that reference the environment to the running program, you must pass any protection rules configured for the environment. Only after the job is sent to the running program can the job access the confidential environment.

When the workflow references the environment, the environment appears in the deployment of the repository. For more information about viewing current and previous deployments see View deployment history ".

You can specify an environment for each job in a workflow. To do this, add a jobs .. environment key followed by the environment name.

For example, this workflow uses an environment called production.

When the preceding workflow runs, the deployment job follows any rules configured for the production environment. For example, if the environment requires a reviewer, the job is suspended until one of the reviewers approves the job.

You can also specify a URL for the environment. The specified URL is displayed on the Repository Deployment page (by clicking environment access on the repository home page) and the workflow running visualization diagram. If a pull request triggers a workflow, the URL is also displayed as the View deployment button in the pull request timeline.

How environments relate to deployments

when a workflow job that references the environment runs, it creates a deployment object and sets the environment property to your environment name. As the workflow progresses, it also creates a deployment status object, where the environment attribute is set to your environment name, the environment_url attribute is set to the URL of the environment (if specified in the workflow), and set the state attribute to work.

You can access these objects through REST API or GraphQL API. You can also subscribe to these webhook events.