你准备好开始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级测试规划
你准备好开始DevOps了吗?

文章插图
 
image.png
  • 单元测试实现起来既快成本又低,因为它们主要是对小代码块进行检查 。
  • UI 测试实施起来很复杂,运行起来很慢,因为它通常需要启动一个完整的环境以及多个服务来模拟浏览器或移动行为 。实际情况可能希望限制复杂的 UI 测试的数量,并依赖基础上良好的单元测试来快速构建,并尽快获得开发人员的反馈 。
  • 单元测试前期投入少,短期内可以看到效果,对开发人员要求高;UI测试前期人员成本投入大,需要很长时间看到效果
代码覆盖率
  • 使用代码覆盖率查找未测试的代码 。一旦您采用了自动化测试,最好将它与一个测试覆盖工具结合起来,帮助了解测试套件覆盖了多少代码库 。代码覆盖率定在 80%以上是很好的,但要注意不要将高覆盖率与良好的测试套件混淆 。代码覆盖工具将帮助您找到未经测试的代码,但在一天结束的时候,测试的质量会产生影响 。如果刚开始,不要急于获得代码库的 100%覆盖率,而是使用测试覆盖率工具来找出应用程序的关键部分,这些部分还没有测试并从那里开始 。
  • 重构是一个添加测试的机会 。如果您将要对应用程序进行重大更改,那么应该首先围绕可能受到影响的特性编写验收测试 。这将为您提供一个安全网,以确保在重构代码或添加新功能后,原始行为不会受到影响 。
5. 测试/部署环境准备
  • 测试需要多少资源 ?
  • 编写自动化部署脚本? Python,shell, powershell, or ansible ?
  • 多环境/多分支 配置?
6. 团队CI文化