微软西雅图总部DevOps交流总结

Posted 2021-04-16 DevOps

本文转自Study4台湾社区。Study4台湾社区，成立于2011/9/25，希望藉由社群推广的力量，让台下的朋友听到来自不同县市的大师讲课，也让台上年轻一辈的技术传教士能不断的琢磨并且追上大师这是一个社群，社区希望透过分享，给偏远地区、年轻一辈、每一个人，多那么一点机会。点击原文链接关注 Study4台湾社区。

这一两年在软体或是资讯界比较热门的词除了Scrum外，大概就非DevOps莫属了，且说真的不知道为什么，现在不管什么工具或产品，最后都要去跟DevOps扯上关系，就如之前在许多研讨会上，有很很多DevOps的大神说过，关于DevOps的定义每一个人都会有一种不同的解释或诠释方式去说出他对DevOps的认知与见解。也因为这样，怎样做好DevOps这件事情，其实也就没有标准答案了。

上个月有幸与微软西雅图总部交流了一下DevOps转型的议题。这真是一个非常棒的体验，虽然，这之间的交流时间不算长，但也发现微软在进行DevOps转型中的有些行为模式跟自己的团队运作还满相似之处。DevOps很难去说谁是对谁是错，所以，能与各种实际有在进行DevOps公司交流，互相吸取对方的经验与过程，作为自己团队或企业的借镜是相当好的。

咦?怎没有Story Point

在讨论之中，突然看到对方，在Story中没有去设定Story Point，忽然让我觉得怪怪，一般来说以Scrum进行方式，因该会团队针对每个Story去评估该Story的Story Point，进行该Sprint可以完成的Story项目。所以，就特别问了一下讲者，讲者给我这四个要点

Usage

Acquisition

Engagemnet

Satisfaction

Churn

Feature Usage

Velocity

Time to Build

Time to Self Test

Time to Deploy

Time to Learn

Live Site Health

Time to Detect

Time to Communicate

Time to Mitigate

Customer Impact

Incident Prevention Items

Aging Live Problem

SLA Per Customer

Customer Support

We don’t watch

Orginal estimate

Completed Hours

Line of code

Team Capacity

Team Burndown

Team Velocity

of bugs found

原来在整个DevOps循环中，开始关注速度部分则是交付的时间有多快，也就是说当我一个Story完成后，可以多快交付上线，确实如果从这层面考量，完成定义就会被定义在真正有被交付到环境上才算完成，因此，在对方DevOps转型中，就不太需要关注在开发者设定预估时间上。在自己实务经验上，似乎也是如此，对于团队来说，就是要赶紧把东西交付出去，尤其，有时候又会被限制时间完成，那样去预估一个Story的大小，似乎意义就不大。

何时要做UI自动化测试

这一个问题主要是我想要知道对方是怎样进行UI自动测试，却得到对方怎样去进行一个系统测试比重分布，毕竟做UI测试这件事情，实务上要去做到全自动化的难度并不清，如果从技术角度上是简单，但UI测试其实也就是整个系统的整合性测试，再加上每次要是UI有所变化，基本上写的测试案例就必须要重新再变更，让整个测试效益会比较低

原本是整合测试比重较多，慢慢增加小量的单元测试，以及测试API服务的测试比重，未来将会是以单元测试为主轴，会后思考一下，就经济效益来说确实是这样会比较划算，不仅有自动化可以帮忙，也可以缩短交付时程。再加上后续采用微服务架构化，基本上进行到L3的测试，也大概完成所有测试的80%

关于Microsoft DevOps转型前后

Microsoft开发团队转型成为DevOps历程结果，其中有几点跟自己团队是满像的，尤其是团队只剩下PM和Engineering，换句话说就剩PO和开发团队了，微软移除QA团队这件事情，想必是大家都知道。移除QA团队，就不代表不做QA，只是把QA这件事情转移到开发团队，其中最大好处当然对于要执行自动化测试这件事情来讲就会容易许多。当然，这其中也可以让开发者和PM针对所谓的Bug进行优先权处理，早期若是有QA团队，对于QA来说是必须修复好所有Bug，才算合格。但实务上并非所有Bug都是对产品或是系统有直接的影响，若无法针对Bug去进行优先权处理，某程度上就会让整个系统产品上线时程延后或是延长布署时间。就目前实务来说，也确实如此，如果整个团队都不断进行迭代，或许可以有些对用户完全不影响的缺陷，是可以延后修复的

---

有幸借镜微软转型过程，由于时程因素，讲者没有办法把所有细节讲完，但是整体而言，让我知道自己团队还有在DevOps之路还有更多改善空间，毕竟产业组织特性不同，也不能完全复制微软这套过来，还是必须做一些小小改良来符合企业文化与流程。