CI,CDandCD
在我们谈论什么是CI,CDandCD之前，先引用一下行业内的定义：
第一个CI，表示持续集成（Continuousintegration）
第二个CD，表示持续交付（ContinuousDelivery）
第三个CD，表示持续部署（ContinuousDeployment）
在阐述三个术语及之间关系前，先来看一张图，这张图已经很清楚地阐述了它们之间的关系。
什么是持续集成（Continuousintegration）
在持续集成（Continuousintegration）环境中，开发人员将会频繁的提交代码到主干。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证。这样做是基于之前持续集成过程中很重视自动化测试验证结果，以保障所有的提交在合并主线之后的质量问题，对可能出现的一些问题进行预警。
什么是持续交付（ContinuousDelivery）
在持续集成（Continuousintegration）的基础上，将集成后的代码部署到测试、预生产环境中验证的过程。
它可以让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。
什么是持续部署（ContinuousDeployment）
在持续交付（ContinuousDelivery）的基础上，将最后一个生产环境交付转换为全自动化的过程。
持续部署是一个很优秀的方式，可以加速与客户的反馈循环，但是会给团队带来压力，因为不再有“发布日”了。开发人员可以专注于构建软件，他们看到他们的修改在他们完成工作后几分钟就上线了。基本上，当开发人员在主分支中合并一个提交时，这个分支将被构建、测试，如果一切顺利，则部署到生产环境中。
持续集成工具选型考量
在决策的时候，通常多数人都会把重点放在工具的特性上。但是要记住，虽然特性的确重要，但还有其他指标需要考虑，下面这五个指标在评估工具时最有帮助：
特性
可靠性
寿命
目标环境
易用性
特性
说到CI服务器的特性，应当考虑该工具与版本控制系统的集成、处理构建平台（例如Ant和Maven）的能力以及提供反馈和报告的能力。而且不要忘记检查其他特性，例如构建标号和管理项目的依赖项。最后，在需要做一些特定的增强时，理解产品的可扩展性会很有帮助。
从特性的角度来说，以上提到的几点在选择所需要的正确的CI服务器时，至关重要。
产品可靠性
因为下载和使用开源CI服务器很简单，所以可以试用产品来判断它的可靠性。而且，在工具的可靠性和它在市场上的时间之间，通常存在一些相关性。使用新产品时，就会冒着有未发现的bug的风险。而且，用户群是发现工具出现的问题的优秀资源。大量的问题贴子或者过多的复杂问题，就表示用户对这个工具的意见较大。
因为我这里讨论的服务器是开源的，所以很容易发现下载的人数，这也会是产品健康程度的一个指示。用户少可能意味着反馈渠道少，可能需要换个地方看看。
寿命前景
在下载CI服务器之前，了解这个服务器未来的前景会有帮助。简单地说，使用已经死亡或正走向死亡的产品不是个好主意。可以检查该工具已经出现了多少年、在它的用户群中是否有正常数量的活动。就像可以从用户群来判断产品的可靠性一样，活跃的社区是工具未来前景良好的征兆。
目标环境
CI服务器不能在所有环境下工作。需要考虑服务器支持哪个操作系统以及具体的系统需求。例如，如果工具是用最新版本的Python编写的，那么需要确定这个版本Python能够用于自己的操作系统。
易用性
产品的易用性可能是最主观的指标。有些人愿意手工修改配置文件，而有些人想让所有管理任务都在应用程序中执行，例如Web控制台。有些服务器要求从一个屏幕单击到下一个屏幕来执行简单的管理，而其他服务器则提供了直观的向导。
如果想理解CI服务器的具体细节，那么漂亮的管理Web表单就不重要了；但是，如果人手不足、工作繁忙，那么可能不会想在管理CI服务器上花太多时间。
持续交付工具对比
WIKI上有一个各种工具的比较，他主要从BUild，平台支持，SCM等方面考虑。
持续集成工具在Docker中的应用
在Docker环境中进行持续集大致的流程如下（但需要考量一些事项）：
开发者提交代码：是否需要利用诸如GitlabCI来完成代码质量、健壮性的自动化测试
镜像构建：是否需要将业务的代码集成到镜像中，额外带来的地问题就是安全隐患，但有个好处，就是回滚更容易
上传镜像至私有仓库：镜像是否需要一系列漏洞扫描、内容信任、同步等机制
容器部署：是否需要多编排工具（Kubernetes、Mesos/Marathon...）的部署能力
我们的决择
在实际环境中，我们已经实现了生产环境95%，测试%的应用容器化。
容器化历程时间可以追溯到年，我们的发布平台提供了两套编排工具（Kubernetes、Mesos/Marathon）的发布支持能力。结合各种DevOps技术栈，我们已经实现了持续集成（Continuousintegration）、持续交付（ContinuousDelivery）、持续部署（ContinuousDeployment）的三个过程。
对于持续交付工具来说，我们更注重于CI/CD工具的轻量化和解耦能力。该结论是我在实践中，经经反反复复的验证，结合时下DevOps技术栈的特性确定的。其基于以下几点考量：
持续交付工具只是一种工具，其无非只是做了一层封装而已
持续交付工具本身也有学习成本，那么这样就很考验团队成员知识体系的储备了
过多，甚至是“滥用”持续交付工具特性组件，只会给技术栈的切换增加难度，我们要的是平滑切换
回归最原始的持续交付模式，结合时下DevOps技术栈提供的ResetfulAPI接口，一切皆能脚本化
在无任何持续交付工具的支持下，也能自实现应用上线全流程
自托管发布脚本，基于RestfulAPI接口，对接各种持续交付工具。在持续交付工具不可用的情况下，快速恢复
基于以上考量，最终我们的持续交付技术栈为：GitLab+Jenkins+Shell运维最基础的技能+其它DevOps技术栈
转载请注明：http://www.0431gb208.com/sjszyzl/1857.html
