最近终于摆脱了项目的束缚，不用再面对强势的甲方，不用在团队之间来回奔波，而是可以专下心来和团队一起转向公司内部的研发支持体系建设工作。在此对最近的工作做一个梳理。
最近做了这几个事：
- 读了几本关于devops相关的书
- 和公司内部所有项目面对面聊了一下
- 调研学习了一下业界的做法
对于Devops来说，业界其实并没有一个具体的定义，最初的定义是development + operation，也就是涵盖了开发、测试、运维三个角色。而实际上往往我们说devops，都会不自觉加上需求这一部分。我理解是造成这个现象的原因是devops传了这么多年，我们总觉得它应该无所不能。最深的印象就是我在公司内部的手册中，发现产品部门制定的流程里，把编码+构建+测试定义为devops，在领导的规划里，又认为devops可以涵盖整个公司的所有研发支持系统。觉得做了devops就能解决所有的问题。
最近读完《持续交付2.0》，我也才对持续集成、敏捷、devops、持续交付有了一个稍微清晰的概念：
- 持续集成：涵盖从编码、构建、测试，自身可以作为一个闭环。开发人员完成代码后提交代码管理系统，由自动构建工具拉取代码，编译构建，完成测试环境部署，测试人员在环境上测试后反馈开发人员问题和缺陷。
- 敏捷：涵盖产品、开发、测试。产品负责需求的引入，开发人员根据需求获取到任务后进行持续集成。产品需要进行验收测试。
- Devops：持续集成完成后，需要通过自动部署工具，部署到生产环境中，可以是自动的，也可以是手工的。具体的部署策略包括灰度、蓝绿等，根据实际情况选择。
- 持续交付：在产品部署到生产环境后，需要有相应的运维工具提供系统的相应指标的检测，通过运营数据，将信息收集反馈给产品经理，进入下一次迭代。在《持续交付2.0》中，区分了产品和业务两个角色。也就是提出了业务也需要共同参与，形成闭环的模式。但是从技术角度上来看，认为可以归结到需求。
所谓研发支持体系，我理解上最终的目标应该是能提供所有相关角色相关服务的平台系统。根据公司内部的体系，主要考虑几个阶段：
- 需求管理：提供需求的构想，分解，设计（也包括交互设计、API接口设计、数据库表结构设计）等；
- 任务管理：提供根据需求拆分的任务的管理和追踪，此处会涉及到研发模式，通常为敏捷，也需要支持瀑布；
- 代码管理：提供代码仓库，能进行分支管理，代码评审，代码合并，并提供代码的规范扫描和安全扫描能力；
- 构建管理：通过和代码仓库的联动，自动或手动进行编译构建，并展示构建结果，构建后的制品需要存放到制定位置（制品仓库）；
- 测试管理：与需求管理联动，登记手动测试案例，存放自动测试脚本，并能提供自动测试的接口，在完成项目构建后，联动触发自动测试，并展示自动测试的报告；
- 自动部署：手动触发的方式启动，将制品从仓库中取出，部署到对应的生产环境中去；
- 运维运营监控：提供系统监控、应用监控、业务监控等多维度监控，为下一阶段的需求提供数据依据，并为一线和二线运维人员提供工具平台保证应用的正常运行。
- 支持系统：为了提供1-7的能力，我们还需要为每个用户提供SSO或统一认证，使各角色能用一个账号登录所有系统。还需要配套环境的管理系统（配置管理），记录所有研发、测试、生产环境的服务器台账，并配套类似ansible、puppet运维工具，用于实现日常的运维操作和环境配置。配套邮件、短信、消息等通知系统，将流程实时告知关系人。还有针对容器的支持等等就更不用说了。
如此梳理下去，造轮子的代价很高很高……
业界其实就有类似的一站式devops工具平台，最近主要看了腾讯云的CODING
、阿里云效和TAPD。基本都提供了类似的服务。其实我们基本可以看到相似的思路，比如在这个平台上录入需求，然后进行需求对应任务的拆分，联动代码仓库和持续集成，自动化测试工具，配合阿里云或腾讯云等基础服务，实现一站式管理。这也就意味着，这个平台是阿里和腾讯云生态中的一环。
然后我去问了下本地化部署的报价，emmmm……来让我们看看devops工具这几年的发展吧。
到了2018年，出了个元素周期表，现在更新到了V3版本了。
但是笼统来看，基本可以梳理出一套国内比较最常见的工具链体系：
JIRA（任务跟踪），微信/钉钉（消息），Confluence（知识库），GIT（代码仓库，Jenkins（CI），Maven，gradle，npm（依赖、构建），selenium、Junit、Jmeter（测试），Ansible（配置管理），docker（容器），nexus、dockerhub（制品仓库），swam、k8s、rancher（容器调度），prometheus、zabbix（监控）
剩下的工作就是如何梳理出公司的痛点，排定优先级一个个搭建了。搭建完然后把所有联动起来，想想还是挺刺激的嘛。
