DevOps 中如何做 Backlog Version Control 和 Testing

Posted 2021-04-16 Study4为爱而学

前一篇谈论到 DevOps 的概念，现在来谈谈在 DevOps 针对 Backlog 、 Version Control 和 Testing 这三种工作该怎样进行。  DevOps的文化转变中，其中有一个重要的变革就是在于Backlog的等级，在 鳳凰項目 一书中有提到两种类型的工作，分别是商业项目 (Business Project) ，这边可以简单说是用户需求，以及工程项目或 IT 内部项目两种

Backlog

---

这两种类型的工作，都因该被归属到整个 DevOps 流程中，针对 使用者需求 和 工程專案或 IT 內部專案 两类的定义如下:

1. 用户需求 :  来自企业商业所需要的功能或是用户需求项目

2. 工程项目 : 在用户需求中必须去建构的 Infrastructure 的工作项目或是维护该需求的项目，以及系统的改善项目。 这些类型的需求，也因该与用户需求一样，放在同一个Backlog去被追踪和完成，并不可以被排除在工作项目之外

大多数的团队，很容易把第二项给忽略，甚至认为做那些是无价值的。 在DevOps持续改进的精神中，为了不断改善、优化系统的流程和适应性。 建议是要花整个团队的20%时间去给这些非商业功能需求的项目，像是系统的信息安全、Infrastructure、 工程流程... 等，让这些支持商业需求的项目，可以更好及更稳定。 若是，长期不把时间分配到这些项目上做改善，容易累积许多的技术债，甚至，会造成日后更多非计划性或是预期性的工作，像是系统稳定性、漏洞... 等等

而将一些计划外的工作或是复原工作，附加到原本的计划工作项目中，很容易造成工作切换上的瓶颈和混乱。 有时候会让原本backlog有了更长的Lead Time。 往往发生这些事件，就是长期忽略技术债的消除或是在日常没有一些改善的方案去进行。 当团队开始程序开发到代码第一次被布署到正式环境，这期间的周期，可被定义为Lead Time。  Lead Time本身是可以被衡量的指针，而透过DevOps的一些实践方式，有助于改进它 

Version Control

---

大多数的团队或是企业，都知道使用版本控制来管理程序代码，但是，并非所有人都可以有效做到这一点，有时候，大多数的版本管控作法只像是文件备份，而忽略两种版本控制的方式:

1. 有效的建立版本控制分支策略

2. 将工作项目连接到程序代码，达到透明度

   
   

建立分支的策略有很多种，最好的方式是依照组织或团队的特性进行订制。 较为简单作法，就是建立一个分支，这个分支建立持续整合流程，每当程序代码被Check-in时候，就自动化布署到开发环境中，透过这样方式，再与工作项目结合， 就可以轻易的知道有那些变更被发布到开发环境中。 然后，再把开发环境的分支提升到测试或是正式环境，这样相同的程序代码将会被布署到正式环境，而不会出现未经过验证或是检查的代码被发布到正式环境。 此外，在布署到任何环境时候，必须确认所有更改是跟商业或业务需求是一致的

工作项目链接程序码 (Connecting work to code)

把工作项目与程序代码链接一起，主要是一种简单验证程序代码变更和需求是相关性，并且透过建置和布署后，从用户的反馈中去了解这次的代码变更。 定义分支最简单的规则就是保持低维护性和较高的可持续性。 若是有一个分支，长期很少有合并的动作，那么将可能累积隐藏不少的技术债

如果团队或是企业，还没开始做有效的版本控制机制，那么开始使用版本控制这件事情是重要的。 一个好的开始可以从开始学习Git版本控制模式下手。

从 DevOps 的团队来看， Infrastructure 的处理方式是和软件开发因该是要相同的。 其中，Infrastructure as Code (IaC)就是透过程序代码去管理和建置机器环境，这些程序代码是需要被版本控制的，同时，也要能与团队协同合作完成

Testing

---

在测试部分， DevOps 提到是持续进行测试，这样测试是包括程序代码和布署环境的测试。 不过，在实务上，持续测试是持续交付中最困难的一部分。 但持续测试最终结果将会在整个交付过程中，提供高质量的软件，并提升我们布署到正式环境前的信心程度。 但怎样的要接受怎样测试成果，是可以由团队规范，建立一个Bug Cap规则，在这规则下进行持续交付的动作

1. 自动化 :  自动化是测试的关键，从单元测试、整合测试、 UI 测试到负载平衡测试都是属于持续测试一环

2. 使用增量和迭代方式 : 越接近正式环境的上线，其测试的深度会不断前进

   
   

Beta testing and progressive exposure

Beta testing 和渐进式公开功能是在 DevOps 在正式环境中，接受终端用户反馈的重要方式和策略:

1. Beta testing: 这是一种提供给外部用户测试的方式，将发布的版本提供给受限人员进行测试，让版本发布到正式环境区做更多测试，或是从受众群体中得到一些反馈

2. Progressive exposure: 类似 Feature flag ，把一些新功能或技术，让少量的用户可以进行切换到新版本或是新功能使用，进而得到反馈。 然后再逐步发布给大量用户去使用这些功能

以上两种方式都是透过先给小量用户进行测试新功能，由他们测试后，迅速提供反馈意见。 透过，这样的快速反馈，可以让开发团队知道哪些功能是有相关性、有价值的，并且藉由这些信息，做为下次改进和策略应用的依据。

Study4 Love