本篇需要探讨的是Devops相关工具链以及CI/CD在Devops中的重要位置 :
虽然我们强调，devops并不是一系列工具的组合。但是脱离了工具的Devops就脱离了Devops的精髓所在，在Devops的世界里，工具链就像是一把双刃剑，如何根据企业自身的特点选择合适的工具链，成了能否达成Devops最终目的的最重要的手段。
我们以"流水线部署"的概念来组织下本篇内容：此过程包含了开发人员提交代码到代码实际投入正式生产环境之间的步骤。
既然为流水线部署，那么对应着一个流程以及关键节点，那么我们以一张图来表述下这个流程：
一、Devops流水线部署的工具链中两大模块:
1. 持续集成（Continuous Integration，CI）:
定义：频繁地将代码集成到主分支。
工具：版本控制系统，CI 工具等
流程：
• 持续集成服务器得到新提交的通知或者定期检查是否有新提交
• 在检测到新的提交时，持续集成服务器运行构建脚本
• 构建成功，则持续集成服务器运行自动化测试；若构建失败，则同一分之上的其他提交也无法构建，因此需要及时的解决构建的问题
• 持续集成服务器把器运行结果提供给相关责任人
1.1 代码管理工具的选择：
每天都会有大量的开发人员需要将代码合并到主分支，这时候就需要一个合适的工具来做版本控制，常用的版本控制工具有GitHub、GitLab、BitBucket、SubVersion等，关于这些工具的选择，没有一个绝对的天平。选择一个最适合的，不管我们用什么样的代码管理工具，都是为了减少整个流程的时间，如果因为强制使用某种工具导致效率下降，也是得不偿失的。
目前主流的代码管理工具有GitHub，GitLab，SVN 等等。
下面简要列一下Git和SVN的区别：
• Git属于分布式管理，SVN属于集中式管理，Git中每个克隆(clone)的版本库都是平等的，你可以从任何一个版本库的克隆来创建属于你自己的版本库，而SVN只能从中央仓库获取到代码。
• Git提交完全在本地完成，无须别人给你授权，SVN则需要再服务器上开放上传权限。当然，Git如果需要把代码合到别人的仓库，任然需要发起一个PR，获得别人的同意后，才能合并。
• Git分支切换特别的快，因为他只是切换头指针，而不是重新拉取整个分支的代码
• Git的版本号则更进一步，版本号是全球唯一的;SVN则维护一个全局版本号，并且版本号是连续的，可以预判下一个版本号
• Git的内容完整性要优于SVN
总的来说，Git适合分布式开发，公共服务器压力和数据量都不会太大；SVN易于管理，集中式服务器更能保证安全性，适合开发人数不多的项目开发，且服务器压力太大，数据库容量暴增
1.2 持续集成工具的选择：持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。
目前流行的的持续集成工具有很多，在此列一些常用的工具，并列出一些优缺点，让大家再选择的时候有个参照。
• Jenkins：请允许我皮一下Jenkins，毕竟对于大家来说，Jenkins并不陌生，一个跨平台的CI工具，它通过GUI界面和控制台命令进行配置。相信是各大公司目前用的最多的系统集成工具，因其灵活性，强大的插件扩展而闻名。但是其最主要的一个特点是，Jenkins可以在多台机器上进行构建，拥有一个Master和多个Slave的模式，让整个Jenkins的任务分配清晰明确，且分布式的结构，使得对于多任务的处理有一定的抗压能力。当然，学习它可能要花费一些时间，但是如果你需要一个灵活的持续集成解决方案，那么学习如何使用它将是非常值得的。
• GitLab CI ：GitLab托管在GitLab.com上，GitLab.com提供了免费的托管服务，并且提供了git仓库存储和管理功能，如访问控制，问题跟踪，代码评论等。GitLab CI能与GitLab完全集成，可以通过使用GitLab API轻松地作为项目的钩子,当代码集成完成后，立即触发开始下一阶段的任务。
• TeamCity : 来自于JetBrains的成熟CI工具，提供了所有CI功能，但仅限于20个配置和3个构建代理，因此，需要购买一些扩展的功能，因此，如果你习惯于使用WebStorm等工具，那么，可以考虑下购买
• Travis CI ： 侧重于托管的工具，对于GitHub上托管的开源项目的构建几乎都是免费的，它通过.travis.yml文件进行配置，并且支持多种语言
• Go CD ： 它设计的理念就是支持流水线，消除了构建过程的瓶颈，并能够并行地执行任务，支持Windows，Mac和一些Linux发行版。
• Bamboo ： 能够很好地支持JIRA 和BitBucket ，可以免费试用30天。
• CircleCI ： 目前仅支持Github管理，它能够支持的语言包括：Java, Ruby/Rails, Python, Node.js, PHP,等。但是对于其容器，是需要付费的，但是总的来说并不是很贵。
那么，对于你和你的团队来说，如何选择一个合适的CI工具？
• 是否符合你和你公司的Devops框架：每个公司都有一套属于自己定义的Devops流程，如果整个工具并不兼容你的流水线，那么无论这个工具再好，也会成为你这套流程能否带来效益的关键。
• 你团队的熟练程度：如果你的Team大多熟悉TeamCity ，请不要强制他们使用Jenkins或者其他工具，并不是热门的都是好的。
• 是否支持Docker：虽然说Docker在整个Devops流程里面不是必须的， 但是Docker革新了我们分发应用程序的方式，我们无法忽视它在整个行业的地位，因此，能否很好的支持Docker，也是整个Devops流程自动化程度的一个重要衡量标准
• 界面是否友好，配置的复杂程度：一个工具的易用程度决定了它是否能选择的重要指标之一，任何一个好的CI工具的主要作用之一就是使构建过程更容易，因此UI操作不应该很难或复杂。
2. 持续部署（Continuous Deployment，CD）:
定义：代码通过评审以后，自动部署到生产环境。
工具：Aws ECS/ECR ， CloudFormation
部署总体目标：对用户产生最小影响（服务延迟/中断等）的情况下，将服务的升级版本投入到生产环境中。
2.1部署策略：
• 蓝/绿部署（虚拟机总量翻倍）：全量部署，包含N台提供版本原始服务的机器，以及N台提供新版本服务的机器，服务路由可以通过DNS一步切换，在试用期后，配置了原始版本的N台服务器会从系统中移除，不再提供服务。如果在试用期内，新版本的服务有任何问题发生，则可以及时切回到原始版本。当然，从成本方面看，我们需要在试用期内提供相同数量的N台机器以部署新版本，若是一个大的项目，可能是上百台虚拟机资源，准备阶段和测试阶段也颇为耗时，而且成本也会翻倍。
特点是：全量部署。
• 滚动升级（虚拟机总量不变）：将少量的新版本的虚拟机一次性全部部署到生产环境，同时关闭响应数量的原始版本的虚拟机。例如，部署一台新版本的VM，就关闭一台原始版本的VM。该策略花费不多，但是会引入一些一致性问题。该部署方式跟蓝/绿部署主要区别是，全量替换还是增量替换。
特点是：增量部署。
• 金丝雀测试部署：在生产环境的少量虚拟机上部署新的服务，并对特定用户开放。这些特定用户可能是随机采样的用户，也有可能是开发的成员等等。我们应该严格监控金丝雀，一旦发现错误，则应立即回滚。如果一段时间内运行正常，那么可以将其他机器一并升级为最新版本。
如图：1 为大部分用户的请求流向
2 为金丝雀数据流向
特点是：金丝雀数目少于提供给Customer的服务器。
• A/B测试部署：在生产环境中部署服务的两个不同版本，可能是新旧版本共存，或者两个新版本共存，要么呈现了不同的用户界面，要么呈现了不同的行为，测试用户的偏好。如果某个版本在业务量上（比如访问量等）呈现出更好的行为，那么整个版本就成为发布版本，另一个版本则作废。
如图：1 为A服务用户的请求流向
2 为B服务用户的请求流向
特点是：A,B数目相同。
2.2 部署工具：目前我们有大量的部署工具，在这里简单说一下AWS平台的部署工具ECS/ECR 与Docker：
我们都知道，如日中天的Docker无处不在，Docker作为一个image的存在，需要一些VM或者PC来支撑的它的运行，我们通常会通过Docker的镜像中心来获取一些已经打包好的镜像，拉到本地运行，或者自己打包一个docker镜像，托管至Docker镜像中心。对于AWS来说，也提供了一个Docker的存储仓库（ECR）以及部署（ECS）的环境，我们可以在本地把做好的Docker镜像托管至AWS的存储仓库ECR,然后定义一系列的Task将这些服务发布到ECS上去。
二、总结：
有一个适当的部署流水线对于快速创建和部署系统是非常重要的，流水线至少需要包含五个步骤：代码提交-测试(第一轮)-构建-测试(第二轮)-部署。每个步骤需要在不同的环境中执行，并使用一组不同的配置参数。系统在流水线中移动时，你可以根据其状态判断流水线中那个环节出了问题，这样可以很快的定位和处理问题，从而可以提升其性能和可靠性。
对于CI/CD的工具选择，原则上应该建立各种工具对应的环境以便使他们的活动是可靠且可追溯的，部署流水线中的每个步骤都有一组自动化测试以及相应的测试框架。
对于部署必须注意的一个事项就是可回滚，以便在新版本出现问题的时候能够迅速回滚到之前的版本，目前市场上有各种部署管理工具。轻量级容器和镜像管理工具的出现有助于开发人员更容易部署到生产环境中去~
关于Devops，我们有很多的横切点需要关注，所谓的横切点，例如 监控，安全审计等，这些内容将在下一章和大家一起探讨。
