懂得：详解CI、CD & CD

ainio

　　当我们在谈论现代的软件编译和发布流程的时候，经常会听到CI 和CD这样的缩写短语。CI很容易理解，就是持续集成。但是CD既可以指代码持续交付，也可理解为代码持续部署。CI和CD之间有很多相似的部分，但是也有很大的区别。这里我们将给大家介绍它们之间的区别和联系。[b][url=http:///www.jfrogchina.com/pipelines]持续发布[/url][/b]的其他知识和内容也可以到网站具体了解一下，我们是领域内专业的企业平台，欢迎您的关注和了解！
[align=center]

                               
登录/注册后可看大图

[/align]

　　在持续集成环境中，开发人员将会频繁的提交代码到主干。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证。这样做是基于之前

　　持续集成过程中很重视自动化测试验证结果，以保障所有的提交在合并主线之后的质量问题，对可能出现的一些问题进行预警。

　　持续交付就是讲我们的应用发布出去的过程。这个过程可以确保我们尽可能快的实现交付。这就意味着除了自动化测试，我们还需要有自动化的发布流，以及通过一个按键就可以随时随地实现应用的部署上线。

　　通过持续交付，您可以决定每天，每周，每两周发布一次，这完全可以根据自己的业务进行设置。

　　但是，如果您真的希望体验持续交付的优势，就需要先进行小批量发布，尽快部署到生产线，以便在出现问题时方便进行故障排除。

　　如果我们想更加深入一步的话，就是持续部署了。通过这个方式，任何修改通过了所有已有的工作流就会直接和客户见面。没有人为干预（没有一键部署按钮），只有当一个修改在工作流中构建失败才能阻止它部署到产品线。

　　持续部署是一个很优秀的方式，可以加速与客户的反馈循环，但是会给团队带来压力，因为不再有“发布日”了。开发人员可以专注于构建软件，他们看到他们的修改在他们完成工作后几分钟就上线了。基本上，当开发人员在主分支中合并一个提交时，这个分支将被构建、测试，如果一切顺利，则部署到生产环境中。

　　当然，正如我所说，他们每部分都更加接近生产环境。你可以构建自己的持续集成环境，然后，一旦团队适应，你可以添加持续交付流，最后，可以添加持续部署流到整个工作流中。

　　举例CI, CD and CD 流水线

　　你需要具备哪些条件:

　　你能获得什么呢？:

　　需要具备什么条件？:

　　你能收获什么？:

　　需要具备的条件:

　　可以获得什么？:

　　如前所述，您可以采用持续集成，持续交付和持续部署。你怎么做取决于你的需求和你的业务情况。如果你刚刚开始一个项目，并且还没有客户，那么你就可以去创建这些工作流，最好是将这三个方面都实现，并且在你的项目迭代和需求增长中同时迭代它们。如果您已经有一个生产项目，那么您可以一步一步地分阶段去实现他们。