如何用CI/CD更快地交付代码

您的开发团队被要求向客户和员工使用的生产应用程序交付更频繁的改进。
团队首先讨论如何更频繁地发布版本。随着变化的加快，它必须考虑的一般性问题有:
•生产应用的稳定性
•减少缺陷
•改善安全
目前必须解决的一些具体问题包括:
•在发布之前，构建和测试就会失败
•QA测试是手工的，执行时间太长
•将应用程序推入生产环境的手动步骤太多了
持续集成和持续交付的devops实践(称为CI/CD)可以解决许多这样的问题。
您从持续集成开始，持续集成是一种开发方法，在这种方法中，代码集成发生得更频繁，软件构建是自动化的。以下是实现持续集成的一些步骤:
每天将代码检入到Git代码存储库中，并关注可以更容易地推向生产环境的小的增量代码更改
自动化一些关键测试，并确保每一个构建都是成功的，只有这些测试通过。换句话说，确保持续集成包括持续测试。
完全自动化构建，以包括所有软件组件，并在Git中将新代码合并到开发分支时触发构建。
实现更快、更频繁的代码发布的下一个方法是投资于持续交付。持续交付是将代码更改推送到开发、测试或生产环境，并执行使用新代码运行应用程序所需的任何步骤的自动化。
为了实现持续交付，您必须更改一些设置，以使它们更加自动化。
例如，应该将所有数据库连接、API端点、用户名、密码和其他参数设置为环境变量，并为目标环境加密和分配值。
您还应该使用容器技术(如Docker或Kubernetes)打包应用程序及其依赖项。
然后实现可以在交付过程中运行的自动化测试——包括性能和安全测试。
并且您必须自动化所有的交付步骤，并有同等的回滚步骤，以防交付失败。
整个过程的结果称为CI/CD管道。
定义了CI/CD管道之后，需要确保它按预期交付。您可以通过监视代码质量度量，例如缺乏率和重新打开率来做到这一点。
随着许多基础设施和部署的自动化和建立在更标准化的体系结构上，您的操作工程师可以将更多的时间集中在改进应用程序性能或解决安全风险上。
您还应该有度量，称为kpi，用于演示关键业务影响。一定要监控你的kpi，以评估你的交付，并确定进一步改进的机会。
由于采用了持续集成、持续测试和持续开发，您的团队现在可以对日常部署计划中的小改进进行优先级排序，同时在较长时间内开发新功能。