问题陈述：
当TCS只是一个原型时，捆绑他们的应用程序并将其与测试团队共享非常简单。编码人员可以仅通过电子邮件将链接发送到在其开发机器上运行的应用程序。但是随着应用程序及其开发团队的增长，这不再可行。手动测试和将更改部署到代码库成为团队的瓶颈。如果没有可靠的，几乎自动的过程来构建测试和更新其基于微服务的应用程序，TCS便无法扩展到他们梦they以求的水平。因此，他们使用Google的无服务器CI / CD平台Cloud Build和开源连续交付平台Spinnaker实施了CI / CD管道。
TCS必须使用CI / CD管道解决此打包交付问题。一旦他们更改了代码，将如何以可扩展的方式将其部署到用户?
解决方案：
因此，TCS实施了基于标签的门控CI / CD管道。这使他们能够快速迭代和测试代码库。该管道的高级步骤如下。开发人员更改代码并将其推送到存储库。 Cloud Build会检测到更改，构建Docker映像，测试该映像并将该映像推送到工件注册表。 Spinnaker会检测到该映像，将其部署到暂存环境，然后测试部署。毕竟，测试已经通过，发布管理器可以手动批准构建并将映像部署到生产环境。
让我们看一下每个步骤。首先，该团队已经在使用Git来管理其源代码。在游戏开发人员中很常见，他们将二进制资产存储在其他位置，并在构建时将其拉出。
使用Git，开发人员可以在测试后将代码库的新分支合并回主分支，然后签出代码库的新分支来进行工作。这使开发人员可以轻松地与其他开发人员合作，并为他们提供工作流程中的很多灵活性。
TCS利用Git标签来创建CI / CD管道，每当将新标签推入Git存储库时，该管道便会启动。他们使用Cloud Build生成应用程序二进制文件，并设置触发器以监视带有以字母“ v”为前缀的Git标签的任何提交。此外，要使用特定标签提交，触发器可以在分支或拉取中查找提交。要求。然后，它会自动开始构建和测试新的Docker映像，并将其推送到工件注册表-您的组织可以在单个位置管理容器映像和语言包。
一旦Spinnaker在工件注册表中检测到新图像，就开始了最后的处理过程。从那里，Spinnaker会将映像部署到按比例缩小的暂存环境中，以进行集成测试。这些初步测试使TCS能够最大程度地减少故障。
一旦这些测试通过，便允许建筑工程师稍稍翻转一下并将新图像推送到生产环境中，从而使TCS的听众可以使用该新功能。
在Git，Cloud Build，工件注册表和Spinnaker之间，TCS能够开发一种自动的，基于门的，基于标签的，连续集成和部署的管道，从而为其容器化环境提供更快的迭代，更大的灵活性和可靠性。随着他们的游戏获得了更多的观众和好评，这一流水线使TCS可以顺畅地扩大规模并迅速添加新功能。