在开发过程中，如果团队没有基本的DevOps体系来保证应用的稳定，便捷的自动部署，规范的部署流程，优良的开发环境，那么除了开发效率很可能是极为底下之外，团队成员也怕是会怨声载道，更别提应用的健壮性了。
DevOps是什么
DevOps的定义众说纷纭，个人的理解是：
- 从狭义上来说是一套实践、方法、工具，是提高交付应用程序和服务能力的一组最佳实践，为了在保证高质量的前提下缩短系统变更从提交到部署至生产环境的时间。
- 从广义上来说是一个运动，一种文化，强调团队紧密合作，打破角色之间的隔阂从而达到提高最终交付价值。
为什么要构建DevOps体系
所以，我们需要：
- 将应用部署的流程自动化起来，只需要按一个按钮就能完成在任意环境上的部署
- 将开发、测试、部署环境统一起来并管理起来
- 缩短从代码提交到部署到生产环境之间的时间
- 将所有过程可视化起来，让所有人知道当前的进展
- 将异常及时反馈给负责人并有回滚方式
DevOps体系的思路与实践
思路：以提升开发部署效率这个结果为导向，以标准化、自动化、可视化为思想，以持续集成、持续交付、敏捷为核心来构建一套DevOps体系。
首先我们可以用上图中的内容与自己当前的工作环境进行对比，还差哪些部分，我们就补充哪些，依靠木桶效应，优先实现还未存在的部分，优先将体系的基础构建完成。
当然图中的实践也不完整，可以参考下面的一些实践来开始。
自动化流水线（持续集成）
优先级：高
通过使用自动化流水线构建工具将代码的构建、测试、部署的流程规范起来，将执行的操作固定下来，去除人为因素干扰构建流程，从代码的提交到部署形成一条生产线。
前置条件：
- 分支策略。流水线的构建方式是通过分支策略来定的，如果有master、dev、release分支，则可能需要构建出三套流水线来分别管理这三个分支
- 提交策略。不论是否使用持续集成的方式提交，提交的信息必须统一，提交者的姓名、提交所属的功能、提交的内容这三块内容必须要有
- 部署步骤。确定需要部署到哪些环境中，有几个构建的步骤，如test、build、deployDev、deployTest、deployProd
- 多项目的结构。一个项目需要是一个能让git单独追踪的项目，才能避免在自动化中影响其他项目的构建
准备好前置条件之后就可以开始构建第一条流水线了，具体的构建工具与构建步骤因团队而异，具体构建的过程就是将所有当前的部署流程整理进构建流水线中，并使用类似Jenkinsfile这样的Pipieline as code的形式将流水线当做整个项目的一部分管理起来，因此这是工作量最大的部分。构建完成后还需要完成流水线可视化，在团队工作区域的显眼位置放置一台显示器，将当前所有流水线的工作状态显示在上面。
各种环境的管理
优先级：高
- 统一开发、测试、部署的环境。生产环境是什么样子，测试环境与开发环境就尽量保持一致。应用的架构方式、应用运行所在的系统版本、应用运行所在的机器配置都应当保持一致，使用Docker可以保证后两者没有问题，但架构方式在开发环境难以做到，优先级其实不高，可以暂时放下。
- 使用Ansible将构建虚拟机上各种工具、环境的过程代码化从而实现Infrastructure as code，将部署的架构也体现在其中从而实现Platform as code，便于扩展机器、问题追溯、架构优化。
- 依赖包的管理。Java非常方便，可以自己部署一个配置管理源，所有包都从这个源里下载，但Go不太方便，可以使用vender将项目依赖的特定版本的代码管理起来，但是会碰到被墙导致无法下载的问题，目前的方式是将项目的依赖提取到一个公共代码库中，然后将公共代码库放到GOPATH中，如果有一些依赖不适合放入公共代码库，则提交到项目根目录下的vendor中。
容器化编排（持续部署）
优先级：高
将应用使用Docker容器化，同时结合容器注册表如Nexus、AWS ECR，容器编排工具如Rancher、K8S，则可以实现应用的自动部署、动态伸缩，解放需要无数次的SCP命令。
团队协作的纪律
优先级：中
- 提交规范。根据分支策略拟定提交规范，主要是小步多次提交、提交信息要全面。
- 快速反馈。在任何工作的过程中，如果觉得哪里不太高效或者有问题，需要及时提出反馈共同优化现状，被动收集反馈。
- 长期反馈。定期召集团队成员举办retro，主动收集改进意见。
- 高优先级修复问题。一旦流水线或监控或日志有异常，需要及时通知相关人员修复。
监控日志规范化（持续运维）
优先级：中
监控：对于应用、数据库、虚拟机都应当有一套监控方式，一旦某个运行节点出现异常则需要通过一些方式通知相关人员
日志：将所有应用的日志在容器内是收集，并上传到一个日志中心，并提供方便的查询工具便于全部人员查询
构建过程敏捷化（项目管理）
优先级：中（长期、穿插）
前置条件：
- 建立需求管理、文档中心，推荐TAPD。
将构建的过程使用看板、迭代的方式管理起来，将实施的计划与进展展示在看板上，当做开发项目一样构建DevOps体系
在构建的过程中，开发、部署步骤、系统架构的文档化也是必不可少的一环，让日后其他同事能够接收DevOps体系和已有的系统架构。文档化是穿插在各个地方的，每当完成一个任务就应当抽点时间补充一下文档。
部署结果可视化
优先级：低
- 流水线可视化。流水线构建完成后，将所有流水线的状态用可视化工具与机器在团队内部展现出来。
- 运维面板可视化。在测试、生产环境部署完成且监控系统到位之后，将运维面板通过可视化工具展现出来，可以实时观察当前系统运行状态。
- DevOps构建过程可视化。使用看板的方式将DevOps体系构建过程管理起来，先维护好TAPD电子看板，需要的话再加上物理看板。看板的资料可以查看这里
落地计划
以上的实践可以说是需要落地的具体事情，把这些事情落地成功也需要一些方法。
遵循渐进式的实施顺序：
- 以任意一个项目为例，将整个DevOps体系实践根据优先级落实其中，当做一个示例规范化整个体系
- 将已有的混乱开发部署方式以第一个项目为例逐步迁移到我们搭建的架构中来
- 基本完成之后回过头来重新审视一遍已有的体系，继续改进
在实施的过程中的建议：
- 使用看板与迭代开发的方式将我们的实施任务分配清楚，计划制定成熟
- 在过程中将DevOps体系当前构建进展同步给所有人，将所有人的意识规范起来
- 让你的老大与团队其他成员意识到构建DevOps体系的必要性，为长期发展做好铺垫
- 整个过程中最大的难点可能是已有的体系也比较庞大与混乱导致迁移难度大从而需要大量时间，所以必要的时候向你的老大申请更多时间与人员来
参考
https://myslide.cn/slides/1218
https://blog.jsjs.org/?p=40
