你准备好开始DevOps了吗？

前面一章节咱们已经了解了Agile,CI/CD,DevOps，做为DevOps的起点，对于一个团队，如何开始本身的持续集成？根据个人经验，列出了一下须要考虑的点

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文化

  1.  尽早集成。若是很长时间不合并代码，代码冲突的风险就越高，代码冲突的范围就越广。若是发现某些分支会影响已经存在的分支，须要增长发布关闭标签，避免发布时两个分支冲突。
  2.  保证编译时时刻刻畅通。一旦发现任何编译问题，马上修复，不然可能会带来更多的错误。测试套件须要尽快反馈测试结果，或者优先返回短期测试（单元测试）的结果，不然开发者可能就切换回开发了。一旦编译出错，须要通知给开发者，或者更进一步给出一个 dashboard，每一个人均可以在这里查看编译结果。
  3.  把测试用例归入流程的一部分。确保每一个分支都有自动化测试用例。彷佛编写测试用例拖慢了项目节奏，可是它能够减小回归时间，减小每次迭代带来的 bug。并且每次测试经过后，将会很是有信息合并到主干分支，由于新增的内容不影响之前的功能。
  4.  修 bug 的时候编写测试用例。把 bug 的每一个场景都编写成测试用例，避免再次出现。
  5.