# Release eks-provider is now deployed by ArgoCD Release process involves: * Build Docker image * Push Docker image to cloud container registry * Deploy eks-provider to the regional controlplane ## Release Process **TLDR;** the steps for releasing eks-provider are: 1. Cut a release branch from main branch using the [GitHub Action](https://github.com/tidbcloud/infra-provider/actions/workflows/cut-branches.yaml). **The name entered to the GitHub Action should in this form `release-0.30`**. This `Action` will trigger docker image build and auto send a PR to [app-delivery](https://github.com/tidbcloud/app-delivery) to bump `staging` env eks-provider image version. Which would automatically deploy the new version to staging environment. 2. When the new version is verified in staging environment and ready to release to prod environment. Create a release tag from the release branch. For example, create a git tag from `new-arch/release-0.30` branch. The tag should be named like `new-arch/v0.30.0`. **It's recommended to create the release tag using GitHub [Release Page](https://github.com/tidbcloud/infra-provider/releases/new)** so we can add some release notes. A prod GitHub Action pipeline will be triggered to bump the version of prod eks-provider image in [app-delivery](https://github.com/tidbcloud/app-delivery) 3. **The automated PR in app-deliverly for prod requires to be approved manually**. Besides, there are maybe some config changes (like bumping tidb operator's verion etc.), if so **you can append them to the PR**. For hotfix PR, it needs to be cherry-picked to the recent release branch, and then create a new git tag from the release branch. ## Deep Dive into Details Mostly the above steps is enough to do a release. But in case you want to know more details about how these steps work under the hood, this section is for you. ### Build & Push Docker Image Currently, third-party component helm charts that will be deployed into dataplane are embeded in the eks-provider docker image. They are managed in [helm-charts](../../helm-charts). To make change of helm be human-readable, please use plaintext files instead of a .tgz file when adding or updating a helm pkg. The Docker image will be pushed to `${aws-account}.dkr.ecr.${region}.amazonaws.com/tidbcloud/eks-provider` by GitHub Action. The pipelines are defined in * * * ### Deploy eks-provider eks-provider is deployed regionally in every Regional Controlplane (historically called Seed Cluster). Each region's eks-provider only manages the corresponding region's dataplane and clusters. Currently, when a new commit merged into main branch of infra-provider. This [Action](https://github.com/tidbcloud/infra-provider/actions/workflows/all-dev-cd.yaml) will automatically call the [Action](https://github.com/tidbcloud/app-delivery/actions/workflows/bump-eks-provider-version.yaml) in [app-deliver](https://github.com/tidbcloud/app-delivery) to bump eks-provider image version in dev environment. When a new release branch named in this form `new-arch/release-0.30` is created, this [Action](https://github.com/tidbcloud/infra-provider/actions/workflows/new-arch-staging-cd.yml) will trigger app-delivery to bump staging environment eks-provider docker image version. When a new release tag named in this form `new-arch/v0.30.0` is created, this [Action](https://github.com/tidbcloud/infra-provider/actions/workflows/new-arch-prod-cd.yml) will trigger app-delivery to bump prod environment eks-provider docker image version. These GitHub Actions are just helpers for release. But code release is a bit different from application deployment. We can change the deployment without code changes and releases. And for better reliability and reduce risks, we should deploy gradually by dev -> staging -> prod. And since we deploy eks-provider regionally, we should also avoid deploy in all regions at the same time. GitHub Action helpers can hardly satisfy this process. When needed, we can manually send PR to app-delivery to deploy into all environments and regions gradually. For example: 1. Bump version of dev-us-west-2 environment to verify if the new code works 2. If the above succeed, bump all other dev environments image version 3. Bump one staging region 4. Bump all other staging environment image version 5. Bump 1 prod region 6. Bump 2 prod regions 7. Bump 4 prod regions 8. Bump 8 prod regions 9. ... For deployment configuration changes, we can do the same process.