Dotnet 项目手动部署到AWS 和Github action CICD 流程总结
.NET 项目手动部署到 AWS
材料准备
前端 build 后的 zip 文件（文章中称为 frontend.zip）
后端 publish 后的文件（文章中称为 backend.zip）
工具选择
后端应用：AWS Elastic Beanstalk
前端静态文件：S3
部署步骤
1. 部署后端
选择 Beanstalk 服务，上传后端文件，配置对应的 properties 参数（类似环境变量）。
然后选择服务器大小、CPU 类型，配置安全组等。
配置成功后会获得一个 domain URL 地址，这是云上访问后端的地址。
2. 设置数据库
使用 AWS 的 RDS 部署关系型数据库 SQL Server。
设置相关参数，最关键的是数据库 master 账号的用户名和密码要记住，后续连接数据库时会用到。
数据库设置好后会有一个 domain URL，这就是数据库服务器的地址，要用在 connection string 里面，例如：
"ConnectionStrings": { "RecamDb": "Server=数据库URL,1433;Database=数据库名字;User Id=数据库账号名;Password=数据库密码;...其他参数"
}
3. 部署前端
运行 build 命令后会得到一个 dist 文件夹，这是前端文件的压缩版。
将此文件上传到 S3 bucket，配置好 properties 等设置。bucket 创建好后会有一个 URL：Bucket website endpoint，这就是前端网页的访问入口。
此时点击页面无法打开，因为 index.html 不知道去哪里访问后端。
4. 配置前端环境变量
将第一步 Beanstalk 获得的 domain URL 信息添加到前端的环境配置文件中，这样前端就知道去哪里 fetch 后端数据了：
VITE_API_BASE_URL=你的beanstalk URL网址
这个变量名 VITE_API_BASE_URL 可以自定义，用于后面 fetch 后端接口的变量名。
注意：商业开发中，开发环境和生产环境要分开。
环境变量会设置两个版本，在本地开发运行 npm run dev 会自动连接 dev 环境变量后端。当部署到云端时，运行 build 命令，React 框架会自动选择生产环境变量进行打包。用户访问云端前端时，会自动连接云上配置的后端，而不是开发时用的本地后端。
前后端都部署完成后，就可以访问 S3 bucket 网址。如果前后端服务器连接正常，就能正常打开应用界面了。
Part 02: CI/CD
前言
如果项目有改动每次都手动部署会很麻烦，我们可以通过 CI/CD 自动化这个过程。
工具与材料
工具：GitHub Actions
材料：
GitHub 中的 workflow（template），即 deploy.yml 文件
AWS secret key
流程说明
当有 PR（pull request）到主分支，或其他请求符合 GitHub Actions 中设置的 "on" 触发条件时，就会启动 CI 流程。deploy.yml 文件定义了具体的执行步骤，甚至可以添加逻辑代码判断或调用 marketplace 中现成的脚本（比如 Beanstalk 的自动部署脚本）。
CI 完成后，通常需要人工审核代码。审核通过后进入 CD 步骤，实现自动部署。我们不再需要手动将修改后的 zip 文件上传到 Beanstalk，CD 命令会自动执行。
它是怎么执行的？
我们需要将 Beanstalk 的密钥相关信息提供给它，它通过 AWS API 访问 Beanstalk 资源并执行相应操作。
AWS 密钥生成
在 AWS 中，如果您不是超级用户，管理员会通过 IAM 为您设置操作相关资源的权限。有了权限后，可以在 Beanstalk 中设置外部访问的 key（类似 token），叫做 access key。
将这个 access key 放在 GitHub Actions 的 workflow 中，当 access key 信息验证通过后，它就能代表您对 Beanstalk 执行所有被授权的操作。
完整流程
这就是完整的 CI/CD 流程。在某些商业场景下，部署到生产环境成功后，可能还会对生产环境进行相应的测试。