说一说：什么是CICD？_1

liukai · 发表于 2022-4-30 10:44:38

　　如果你经历体验过传统的应用发布，你可能就会觉得CICD有足够吸引你的地方，反之亦然。一般一个研发体系中都会存在多个角色：开发、测试、运维。当时我们的应用发布模式可以能是这样的：xray的具体问题可以到我们网站了解一下，也有业内领域专业的客服为您解答问题，值得您的信赖！

　　「开发团队」在开发环境中完成软件开发，单元测试，测试通过，提交到代码版本管理库;

　　「开发同学」通知运维同学项目可以发布了，然后运维同学下载代码进行打包和构建，生成应用制品;

　　「运维同学」使用部署脚本将生成的制品部署到测试环境，并提示测试同学可以进行产品的测试;

　　「测试同学」开始进行手动、自动化测试，测试完成后提醒运维同学可以进行预生产环境部署;

　　「运维同学」开始进行预生产环境部署，然后测试同学进行测试，测试完成后，开始部署生产环境。

　　当然我描述的可能只是其中的一部分，手动操作很多、出现的问题很多。上面看似很流畅的过程，其实每次构建或发布都可能会出现问题。未对每次提交验证、构建环境不一致：开发人员本地测试成功后提交代码，运维同学下载代码进行编译却出现了错误。

　　「存在的问题:」

　　「错误发现不及时」: 很多错误在项目的早期可能就存在，到最后集成的时候才发现问题;

　　「人工低级错误发生」: 产品和服务交付中的关键活动全都需要手动操作;

　　「团队工作效率低」: 需要等待他人的工作完成后才能进行自己的工作;

　　「开发运维对立」: 开发人员想要快速更新，运维人员追求稳定，各自的针对的方向不同。

　　经过上述问题我们需要作出改变，如何改变？

　　软件开发的连续方法基于自动执行脚本，以最大程度地减少在开发应用程序时引入错误的机会。

　　从开发新代码到部署新代码，他们几乎不需要人工干预，甚至根本不需要干预。

　　它涉及到在每次小的迭代中就不断地构建，测试和部署代码更改，从而减少了基于错误或失败的先前版本开发新代码的机会。

　　此方法有三种主要方法，每种方法都将根据最适合您的策略的方式进行应用。

　　在传统软件开发过程中，集成通常发生在每个人都完成了各自的工作之后。在项目尾声阶段，通常集成还要痛苦的花费数周或者数月的时间来完成。持续集成是一个将集成提前至开发周期的早期阶段的实践方式，让构建、测试和集成代码更经常反复地发生。

　　开发人员通常使用一种叫做的工具来做构建和集成。持续集成要求史蒂夫和安妮能够自测代码。分别测试各自代码来保证它能够正常工作，这些测试通常被称为单元测试（Unit tests）。

　　代码集成以后，当所有的单元测试通过，史蒂夫和安妮就得到了一个绿色构建（Green Build）。这表明他们已经成功地集成在一起，代码正按照测试预期地在工作。然而，尽管集成代码能够成功地一起工作了，它仍未为生产做好准备，因为它没有在类似生产的环境中测试和工作。

　　CI是需要对开发人员每次的代码提交进行构建测试验证。确定每次提交的代码都是可以正常编译测试通过的。在没有持续集成服务器的时候，我们可以写一个程序来监听版本控制系统的状态，当出现了动作则触发相应的脚本运行编译构建等步骤。现在有了专业的持续集成服务器后，我们借助持续集成服务器来实现版本控制系统中代码提交触发构建测试等验证步骤。

　　持续合并开发人员正在开发编写的所有代码的一种做法。通常一天内进行多次合并和提交代码，从存储库或生产环境中进行构建和自动化测试，以确保没有集成问题并及早发现任何问题。

　　「开发人员提交代码的时候一般先在本地测试验证，只要开发人员提交代码到版本控制系统就会触发一条提交流水线，对本次提交进行验证。」

　　Continuous Delivery (CD) 持续交付是持续集成的延伸，将集成后的代码部署到类生产环境，确保可以以可持续的方式快速向客户发布新的更改。如果代码没有问题，可以继续手工部署到生产环境中。

　　「持续交付CD」：是基于持续集成的基础上，将集成后的代码自动化的发布到各个环境中测试（DEV TEST UAT STAG），确定可以发布生产版本。这里我们可以借用制品库实现制品的管理，根据环境类型创建对应的制品库。「一次构建，到处运行」。

　　开发环境发布：我们可以将开发环境产出的制品部署进行测试，没有问题后上传到测试环境的制品库中。

　　测试环境发布：此时通知测试人员可以进行测试环境发布测试，获取测试环境制品库中的制品，发布到测试环境验证。验证通过将制品上传到预生产环境制品库。

　　预生产环境发布：获取预生产环境制品，进行部署测试。测试成功后可以将制品上传到生产库中。

　　手动部署生产环境。

　　持续交付是超越持续集成的一步。不仅会在推送到代码库的每次代码更改时都进行构建和测试，而且，作为附加步骤，即使部署是手动触发的，它也可以连续部署。此方法可确保自动检查代码，但需要人工干预才能从策略上手动触发更改的部署。

　　如果真的想获得持续交付的好处，应该尽早部署到生产环境，以确保可以小批次发布，在发生问题时可以轻松排除故障。于是有了持续部署。

　　通常可以通过将更改自动推送到发布系统来随时将软件发布到生产环境中。持续部署会更进一步，并自动将更改推送到生产中。类似于持续交付，持续部署也是超越持续集成的进一步。不同之处在于，您无需将其手动部署，而是将其设置为自动部署。部署您的应用程序完全不需要人工干预。

　　「持续部署CD」：是基于持续交付的基础上，将在各个环境经过测试的应用自动化部署到生产环境。其实各个环境的发布过程都是一样的。应用发布到生产环境后，我们需要对应用进行健康检查、添加应用的监控项、应用日志管理。

　　我们通常将这个在不同环境发布和测试的过程叫做部署流水线，持续部署是在持续交付的基础上，把部署到生产环境的过程自动化。