DevOps是近几年非常流行的系统研发管理模式，很多公司都或多或少在践行DevOps。那么，今天就说说特来电云平台在DevOps方面的实践吧。

说DevOps，不得不说DevOps的具体含义。那么，DevOps是什么呢？是开发+运维么？每个人都DevOps的理解都不尽相同，下面是一组对DevOps的定义，通过这组定义，我们基本可以看清DevOps是干啥的。在这众多的解释中，我认为有一种解释可以更贴切：DevOps是一种能力，具备此能力的团队可以高质量、快速的交付软件产品或服务。这个总结定义道出了DevOps的精神和根本内涵。

一组过程、方法与系统的统称。用于促进开发、运维和质量保障部门之间的沟通、协作与整合。

DevOps是一种文化转变，或者说是一个鼓励更好地交流和协作（即团队合作）以便于更快地构建可靠性更高、质量更好的软件的运动。

DevOps是一种工程模式，本质上是一种分工，通过对开发、运维、测试，配管等角色职责的分工，实现工程效率最大化，进而满足业务的需求。

DevOps主要解决两个方面的问题：

• 按时、快速、高质量的交付软件产品和服务
  
  

• 通过流程的自动化，节省成本
  
  

说到这里，我们不仅要问到：DevOps与敏捷开发什么关系？看上去，他们是如此的相似呢。那么再要说说敏捷。敏捷开发到底什么意思？这仅仅意味着快速吗？简单来说，敏捷开发意味着更多的迭代：更早更频繁地发布产品更新。先把东西做出来，而不是像过去那样过于忧虑产品是否完美。这就是那个“永远beta版”的概念，30天把原型快速搞出来，然后看看人们到底怎么想。敏捷的字面意思就是快速改变的能力。DevOps关注点已经不仅仅是快速改变的能力，他更关注的是如何移除浪费。其实，DevOps是一种敏捷开发的方法，但已超越了敏捷。DevOps是软件开发生命周期（SDLC）从瀑布式到敏捷再到精益的发展。DevOps超越了敏捷，它的关注点是从SDLC中移除浪费。通常情况下，发现浪费或者瓶颈的形式包括：不一致的环境，人工的构建和部署流程，差的质量和测试实践，IT部门之间缺少沟通和理解，频繁的中断和失败的协定以及那些需要珍贵的资源、花费重要的时间和金钱才能保持系统运行的全套问题。

在DevOps的能力闭环中，关注的是：

• 更早、更频繁地发布产品更新,永远beta版,更快速的响应变化。
  
  

• 依托自动化工具（测试、部署），把开发、测试、发布、部署的过程整合，实现即时交付。
  
  

如要具备此能力，就要求DevOps的涉众：开发、测试、运维，求同存异，为组织目标共同担当，紧密配合，提升产品交付能力。启用DevOps会对我们的带来各种变革，总体来说主要有三个方面。DevOps的核心是角色的分工，而不是组织架构变化，垂直化的组织架构不代表可以实现DevOps所需要的分工模式，横向的组织架构也不代表传统的分工模式。DevOps的目标是工程效率最大化，它本身也只是一种方法论，是为了实现工程效率最大化的目标而存在的。

特来电云平台在实践DevOps时，核心思路是通过无人值守的、全过程的自动化（自动构建、自动打包、自动部署、自动测试、自动发布），实现软件研发、部署的流水线式作业。

当开发人员CheckIn代码后，会触发相关应用的自动构建，构建的过程会编译源代码并执行单元测试。单元测试是控制产品质量的第一道大闸，我们要求所有的单元测试必须100%通过，并且所有应用程序要从下面五个方面编写单元测试脚本：内部核心类的公共方法、服务方法（HSF、SG）、符合场景测试、性能测试、破坏性测试。当单元测试执行通过后，会对产出物进行自动打包。因为特来电云平台采用了微软.net技术路线，整个持续集成的过程，我们全部是基于微软的TFS搭建。当然，TFS中没有自动打包的特性，此特性是基于自主开发的补丁管理平台实现的。通过补丁平台不仅仅能制作补丁，还能够为服务器安装补丁。下面是一个公共技术部持续集成的面板。

持续集成结束产出的补丁包，会依次、自动部署到普通测试环境、准生产测试环境、压测环境中进行各类自动化测试。普通测试环境，主要进行接口的自动化测试；准生产测试环境，主要进行接口自动化测试和UI的自动化测试；压力测试环境主要进行性能测试和破坏性测试。当三类测试环境的自动化全部通过，管理员审批通过后， 补丁包首先会在上海数据中心灰度发布上线，24H后在北京数据中心发布上线。持续交付也是基于微软TFS中的Release搭建，但是集成了很多特来电自主研发的系统。三类测试环境和生成环境都部署了特来电自主研发的分布式运维管理平台、补丁安装工具。通过分布式运维管理平台，可以调动500+台服务按照一定的规则更新补丁，此过程也是无人值守的。另外，三类测试环境分别部署了特来电服务治理平台，通过此平台实现接口测试、UI测试、压力测试，并自动出具测试结果和测试报告。限于篇幅，分布式运维管理平台和服务治理平台，后续给大家详细介绍。

下面是基于TFS搭建的持续交付的运行效果图：

在搭建CI、CD的过程中，有非常多的坑需要踩，有技术方面的，也有管理方面的。晒一下重要的建议，希望可以帮助到大家。

1.要有清晰的产品分层结构。

2.清晰、明确的程序集引用关系：nuget、公共目录

3.较全面的自动化测试代码

4.全面的接口测试、UI自动化测试，否则持续集成就变成补丁发布工具

原创：扣丁学堂

DevOps是近几年非常流行的系统研发管理模式，很多公司都或多或少在践行DevOps。那么，今天就说说特来电云平台在DevOps方面的实践吧。

说DevOps，不得不说DevOps的具体含义。那么，DevOps是什么呢？是开发+运维么？每个人都DevOps的理解都不尽相同，下面是一组对DevOps的定义，通过这组定义，我们基本可以看清DevOps是干啥的。在这众多的解释中，我认为有一种解释可以更贴切：DevOps是一种能力，具备此能力的团队可以高质量、快速的交付软件产品或服务。这个总结定义道出了DevOps的精神和根本内涵。

一组过程、方法与系统的统称。用于促进开发、运维和质量保障部门之间的沟通、协作与整合。

DevOps是一种文化转变，或者说是一个鼓励更好地交流和协作（即团队合作）以便于更快地构建可靠性更高、质量更好的软件的运动。

DevOps是一种工程模式，本质上是一种分工，通过对开发、运维、测试，配管等角色职责的分工，实现工程效率最大化，进而满足业务的需求。

DevOps主要解决两个方面的问题：

• 按时、快速、高质量的交付软件产品和服务
  
  

• 通过流程的自动化，节省成本
  
  

说到这里，我们不仅要问到：DevOps与敏捷开发什么关系？看上去，他们是如此的相似呢。那么再要说说敏捷。敏捷开发到底什么意思？这仅仅意味着快速吗？简单来说，敏捷开发意味着更多的迭代：更早更频繁地发布产品更新。先把东西做出来，而不是像过去那样过于忧虑产品是否完美。这就是那个“永远beta版”的概念，30天把原型快速搞出来，然后看看人们到底怎么想。敏捷的字面意思就是快速改变的能力。DevOps关注点已经不仅仅是快速改变的能力，他更关注的是如何移除浪费。其实，DevOps是一种敏捷开发的方法，但已超越了敏捷。DevOps是软件开发生命周期（SDLC）从瀑布式到敏捷再到精益的发展。DevOps超越了敏捷，它的关注点是从SDLC中移除浪费。通常情况下，发现浪费或者瓶颈的形式包括：不一致的环境，人工的构建和部署流程，差的质量和测试实践，IT部门之间缺少沟通和理解，频繁的中断和失败的协定以及那些需要珍贵的资源、花费重要的时间和金钱才能保持系统运行的全套问题。

在DevOps的能力闭环中，关注的是：

• 更早、更频繁地发布产品更新,永远beta版,更快速的响应变化。
  
  

• 依托自动化工具（测试、部署），把开发、测试、发布、部署的过程整合，实现即时交付。
  
  

如要具备此能力，就要求DevOps的涉众：开发、测试、运维，求同存异，为组织目标共同担当，紧密配合，提升产品交付能力。启用DevOps会对我们的带来各种变革，总体来说主要有三个方面。DevOps的核心是角色的分工，而不是组织架构变化，垂直化的组织架构不代表可以实现DevOps所需要的分工模式，横向的组织架构也不代表传统的分工模式。DevOps的目标是工程效率最大化，它本身也只是一种方法论，是为了实现工程效率最大化的目标而存在的。

特来电云平台在实践DevOps时，核心思路是通过无人值守的、全过程的自动化（自动构建、自动打包、自动部署、自动测试、自动发布），实现软件研发、部署的流水线式作业。

当开发人员CheckIn代码后，会触发相关应用的自动构建，构建的过程会编译源代码并执行单元测试。单元测试是控制产品质量的第一道大闸，我们要求所有的单元测试必须100%通过，并且所有应用程序要从下面五个方面编写单元测试脚本：内部核心类的公共方法、服务方法（HSF、SG）、符合场景测试、性能测试、破坏性测试。当单元测试执行通过后，会对产出物进行自动打包。因为特来电云平台采用了微软.net技术路线，整个持续集成的过程，我们全部是基于微软的TFS搭建。当然，TFS中没有自动打包的特性，此特性是基于自主开发的补丁管理平台实现的。通过补丁平台不仅仅能制作补丁，还能够为服务器安装补丁。下面是一个公共技术部持续集成的面板。

持续集成结束产出的补丁包，会依次、自动部署到普通测试环境、准生产测试环境、压测环境中进行各类自动化测试。普通测试环境，主要进行接口的自动化测试；准生产测试环境，主要进行接口自动化测试和UI的自动化测试；压力测试环境主要进行性能测试和破坏性测试。当三类测试环境的自动化全部通过，管理员审批通过后， 补丁包首先会在上海数据中心灰度发布上线，24H后在北京数据中心发布上线。持续交付也是基于微软TFS中的Release搭建，但是集成了很多特来电自主研发的系统。三类测试环境和生成环境都部署了特来电自主研发的分布式运维管理平台、补丁安装工具。通过分布式运维管理平台，可以调动500+台服务按照一定的规则更新补丁，此过程也是无人值守的。另外，三类测试环境分别部署了特来电服务治理平台，通过此平台实现接口测试、UI测试、压力测试，并自动出具测试结果和测试报告。限于篇幅，分布式运维管理平台和服务治理平台，后续给大家详细介绍。

下面是基于TFS搭建的持续交付的运行效果图：

在搭建CI、CD的过程中，有非常多的坑需要踩，有技术方面的，也有管理方面的。晒一下重要的建议，希望可以帮助到大家。

1.要有清晰的产品分层结构。

2.清晰、明确的程序集引用关系：nuget、公共目录

3.较全面的自动化测试代码

4.全面的接口测试、UI自动化测试，否则持续集成就变成补丁发布工具

原创：扣丁学堂