DevOps - 使SAAS持续交付

提到Devops我们不得不先切分一下Dev（开发）和Ops（运维）这两个角色。 在计算机产生早起，由于计算机使用范围的限制，硬件生产、软件开发及软硬件的维护都是来自相同的人员或团队，所以两个角色自然融合，本身就是一体的。 随着计算机使用领域和范围延入了各行各业，产品需求越来越复杂，人们更精细化的拆分了整个研发的生命周期，形成了更专注于开发测试的Dev角色和面向部署运维的Ops角色。

       如今为了更快速交付价值，传统瀑布式开发模型转型敏捷开发。同时一款优秀的产品通常也都是一个有规模的体系工程，需要产品、研发、测试、运维更和谐的团队沟通和更合理有效的配合流程，然而对开发团队的要求是通过快速实现新的功能交付价值，而运维团队则希望能提供给用户最稳定最可信任的生产环境，两个团队提供给用户的价值衡量指标不同，自然工作重点也不相同，这种矛盾也导致配合中出现了巨大的浪费。 为了缩小开发与运维之间存在着信息"鸿沟"，能够更快地构建可靠性更高、质量更好的软件，DevOps的理念随之产生，它并不代表一个角色，一个资格或一个头衔，而是开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程和方法的一个集合、一种文化，也是从瀑布式到敏捷再到精益的发展必然。

       近年来中国企业应用采用SAAS模式已经是大势所趋。但产品生产过程中出现的种种问题：不一致的运行环境、过多的人工参与依赖构建和部署，改动引起不可控的质量，各个环节沟通和理解不到位等，导致了个人或团队经常出现工作中断，配合效率低下。所以如何结合SAAS和DevOps高效发展产品也将是大多数企业快速成长必然经历的过程。

• 全局把握
  团队对DevOps有统一的认识和相同的思维方式，描绘愿景，使DevOps的目标清晰。各角色深入理解相互的工作内容，打破隔阂，比如Dev角色要清楚部署架构、部署流程；如何保障安全性和高可用性；对性能指标、压力情况和监控报警的结果更要作为工作重点。Ops角色也要对开发所使用的语言、框架、工具等有所了解，如何管理源码及分支、如何编译打包部署更要不仅仅接手命令的使用，要深入理解原理和过程，甚至Ops也要参与需求的技术评审，提出技术实现可能带来的运维风险。团队有了统一的思想并能及时沟通协作，有助于技术或工具的合理选型及应用， 制定统一的规范，标准化流程。
• 代码和运行环境
  管理好源码和分支是研发团队保障信息安全、高效协作的基础。我们采用Git作为源码管理工具，并引入多年来业界总结出的Git使用最佳实践，也定义了适合自己的源码命名规则及版本号规范。更合理的branches为敏捷开发提供了高效运转的可行性，但也对各个branch的运行环境带来巨大的挑战。我们根据敏捷生命周期不同时期的要求，拆分了四套（Develop、Test、Staging、Production）运行环境。
  Develop主要给feature branches提供环境。一次敏捷迭代会完成多个（几个或几十个）新feature，每个feature都需要有单独的运行时来保证feature之间互不影响，开发和测试环境单纯，所以Develop环境是由多个运行时组成的，根据新feature数量来决定。我们采用docker技术将运行时容器化，开发人员完全可以依据需要随时产生一个运行时，并在使用完毕后销毁它。
  Test主要给develop branch提供环境。当一次迭代中某个新feature已经开发并测试完成，这个feature就可以将源码merge到develop branch上并进入下一周期——集成测试，Test就提供了一个或多个新feature集成环境。
  Staging是一套预发布环境。它和Production在环境配置方面保持高度一致，用户数据则是production环境中混淆脱敏的数据。在Test环境完成集成测试后发布Staging环境中进入性能、压力及数据完整性方面的测试，同时公司内部也是通过这个环境完成产品新功能的培训和体验的。
  Production是生产环境。提供给用户使用SAAS服务的最终环境。
• 持续集成和自动化
  每一次源代码提交都应该立即构建、测试来验证功能并保证新代码的正确性及和旧代码是否能成功集成在一起，持续集成将整个过程快速不断的反馈和修正。要达到持续集成的能力，不单是管理好源代码，还需要更多的工具和准则：使用code style对源代码编写规范化；maven进行构建；利用nexus建立本地私服来对各种环境的编译和部署提供统一的依赖库。更重要的是面对如此复杂多样的环境过多的人工参与会使出错的几率大大提升，为了降低浪费，我们要将各个环境尽可能的自动化：构建部署自动化、测试自动化（自动化单元测试、自动化集成接口测试、自动化功能测试），使用jenkins来建立jobs将所有的自动化环境串联起来。我们对Develop和Test环境设置了持续集成规则，任何feature branch代码的提交将触发jenkins一系列jobs的执行，检查、构建、测试最终部署到指定的docker容器中；同样Test环境每天早上从develop branch上检测出变更的代码进入jobs，自动化完成各个粒度的测试。当然持续集成过程中任何问题都会邮件通知给相应的人员处理。
• 持续交付
  交付成果给客户使用时每次迭代的目标，在持续集成的基础上，将集成后的代码部署到真实运行环境中，使得交付物尽早的得到验证和反馈，无论输出的好坏都是有价值。持续的交付可以不堆积问题马上调整，也为产品下一次迭代提供优化的空间。

•        计算机领域新概念都是在面临之前的困境和挑战中孕育而生的，这些概念不仅是人类经验积累和智慧的结晶，也为行业提供了统一的新思想和解决方案。如今DevOps已经离我们不再遥远，正是革新团队尝试新理念的好时机。IT服务能力在今天已经成为企业的核心竞争力，为了在激烈的市场竞争中占有优势，研发团队甚至整个公司都应该作出快速并积极的响应。也许在实践中还要结合实际进行探索和试错，但我们坚信只要方向正确，就要坚持走下去。

转载于:https://my.oschina.net/jumpLee/blog/1529083