总结

在CI设置完成后，Tailwind Gears的两支试点团队接下来的任务是自动化软件的部署和发布过程。

第一支团队负责一些仍然托管在本地的Web应用程序。团队决定将这些应用程序迁移到云中的托管Kubernetes服务，而不是自动化本地部署。集群实例、网络和其他云资源已经由IT部门在上一个sprint中设置好了。因此，团队可以轻松地将部署转移到分阶段的部署流程。他们先部署到测试实例，并运行所有自动化测试。同时，他们还添加了一个curl测试，用于调用一个检查数据库和后端可访问性的网站，以确保一切按预期工作。如果所有测试通过，部署将自动滚动更新到生产环境，确保用户零停机时间。

这些Web应用程序的一些代码（包含共享内容）需要调整以适应云环境。这些代码也包含在其他团队的Web应用程序中。团队决定将这些代码迁移到GitHub Packages（JavaScript使用NPM，.NET使用NuGet），并采用独立的发布周期和语义版本控制，以便将来其他团队迁移到云时能够轻松重用这些代码。

第二支团队开发面向硬件产品的软件，这些硬件用于执行安全关键功能。因此，开发过程受严格监管。他们需要对所有更改进行端到端追溯。由于所有要求已经导入到GitHub问题中，并通过嵌套问题进行链接，这个问题已经解决。团队只需要在提交消息中引用最低级别的问题即可。除了端到端追溯外，团队还存在一些未自动化的测试文档，涵盖不同层次的要求，此外还有一些风险管理文档。为了确保在发布产品之前满足所有这些标准，要求的审阅者会在部署到生产环境前手动批准发布，以确保所有要求都已到位，从而确保合规性。结合受保护的分支和代码所有者（所有要求的文档已经转换为Markdown格式），这样可以减少一次性发布的工作量。

硬件上的二进制文件安装由公司拥有的自定义工具执行，该工具在生产机器上运行，用于从文件共享中提取二进制文件。这种方式对端到端追溯不够理想，并且依赖于日志文件。部署到测试环境是手动进行的，这意味着二进制文件的分发方式并不一致。为了改进这一点，团队将二进制文件与工具一起打包到一个Docker容器中，并将镜像发布到GitHub Packages的容器注册表中。然后，可以使用该Docker镜像将版本传输到测试机器和组装过程中。

以下是本章中提到的一些参考资料，您可以通过这些资源获得更多关于我们讨论的主题的信息：