对于一个准备开始 DevOps 实践的团队，从哪里出发呢？根据我的实践经验，可以先从 CI/CD 开始，一步步过渡，从一个项目开始，慢慢覆盖到更多的项目
我从各个阶段列出了实践之前需要考虑的点，仅供参考：
##
1. 代码管理/分支策略
- 代码托管在哪里？
- 使用 git or svn?
- 分支策略/分支模型？
- CI 服务可以访问您的代码库吗？
- 代码结构如何？需要一个库，还是多个库？
- 版本号定义？
- 依赖管理？命名规则？
- Code Review ?
2. 持续集成服务器
- 选好你需要的 CI server 了吗？ jenkins, Teamcity,GoCD or AuzreDevOps
- CI Server 使用的学习
- CI Server 如何部署，需要多少资源，需要多少并发 job ?
- Pipeline 编写，如何标准化？是否需要参数化？
- 与代码仓库，制品库集成？
- 静态代码检查？SonarQube
- 多分支/多个仓库，相互依赖？
3. 制品库
- 选择合适的制品库服务器 (jar, npm, nuget, docker or other package ?)
- 制品的版本？ 如何与 code commit id 关联？
- 制品库保存策略/tag 管理
4. 测试类型
CI 阶段除了保证代码没有冲突，编译通过之外，最重要的就是测试 。每次代码变更后，我们需要自动运行测试用例。
在初始阶段并不需要实现所有的测试类型。一开始可以以单元测试入手，随着时间扩展覆盖面。
- 单元测试：范围非常小，验证每个独立方法级别的操作。
- 集成测试：保证模块间运行正常，包括多个模块、多个服务。
- 验收测试：与集成测试类似，但是仅关注业务 case，而不是模块内部本身。
- UI 测试：从用户的角度保证呈现正确运行。
并不是所有的测试都是对等的，实际运行中可以做些取舍。
4 级测试规划
- 单元测试实现起来既快成本又低，因为它们主要是对小代码块进行检查。
- UI 测试实施起来很复杂，运行起来很慢，因为它通常需要启动一个完整的环境以及多个服务来模拟浏览器或移动行为。实际情况可能希望限制复杂的 UI 测试的数量，并依赖基础上良好的单元测试来快速构建，并尽快获得开发人员的反馈。
- 单元测试前期投入少，短期内可以看到效果，对开发人员要求高；UI 测试前期人员成本投入大，需要很长时间看到效果
代码覆盖率
- 使用代码覆盖率查找未测试的代码。一旦您采用了自动化测试，最好将它与一个测试覆盖工具结合起来，帮助了解测试套件覆盖了多少代码库。代码覆盖率定在 80%以上是很好的，但要注意不要将高覆盖率与良好的测试套件混淆。代码覆盖工具将帮助您找到未经测试的代码，但在一天结束的时候，测试的质量会产生影响。如果刚开始，不要急于获得代码库的 100%覆盖率，而是使用测试覆盖率工具来找出应用程序的关键部分，这些部分还没有测试并从那里开始。
- 重构是一个添加测试的机会。如果您将要对应用程序进行重大更改，那么应该首先围绕可能受到影响的特性编写验收测试。这将为您提供一个安全网，以确保在重构代码或添加新功能后，原始行为不会受到影响。
5. 测试/部署环境准备
- 测试需要多少资源 ？
- 编写自动化部署脚本？ python,shell, powershell, or ansible ?
- 多环境/多分支 配置？
6. 团队 CI 文化
- 当团队实践 CI 时，需要了解分支模型，按照定义的 commit 策略，进行频繁提交
- 提交冲突了，如何处理？
- 怎么反馈冲突 或者 build break ? 谁处理？
- 推广普及 CI 文化
- 尽早集成。如果很长时间不合并代码，代码冲突的风险就越高，代码冲突的范围就越广。如果发现某些分支会影响已经存在的分支，需要增加发布关闭标签，避免发布时两个分支冲突。
- 保证编译时时刻刻畅通。一旦发现任何编译问题，立刻修复，否则可能会带来更多的错误。测试套件需要尽快反馈测试结果，或者优先返回短时间测试（单元测试）的结果，否则开发者可能就切换回开发了。一旦编译出错，需要通知给开发者，或者更进一步给出一个 dashboard，每个人都可以在这里查看编译结果。
- 把测试用例纳入流程的一部分。确保每个分支都有自动化测试用例。似乎编写测试用例拖慢了项目节奏，但是它可以减少回归时间，减少每次迭代带来的 bug。而且每次测试通过后，将会非常有信息合并到主干分支，因为新增的内容不影响以前的功能。
- 修 bug 的时候编写测试用例。把 bug 的每个场景都编写成测试用例，避免再次出现。
