从微软相关部门落地DevOps 经验中学习

适度控管分支让开发更快速

在2008 年，我们开发团队刚开始使用Agile 时，我们认为可以透过程式码品质控管，以及版本控制系统所提供的分支(branch) 功能等方式，让程式码维持高品质。刚开始的时候，我们版本控制系统中的分支都是经过精心规划设计的，工程师开发完成后，必须要从主干(trunk) 取得最新的程式码，将自己所开发的程式码与主干的程式码合并，透过系统建置并且通过所有程式码品质的检查，确保开发的程式码符合我们的规范之后，才能算是开发完成，可以把程式码签入(check
in) 到版本控制系统中。

但我们没有预料到的是，过度的使用分支可能会造成开发流程上无谓的浪费。我们进行新功能的开发时，可能会因为在开发上遇到阻碍开发的事情，所花费的时间超过原本预期，导致开发中程式码与主干(trunk) 太久没有进行合并(merge)，让程式码落差越来越大。这个现象也产生了相当严重的合并(merge) 债务，我们在不同分支的工作好不容易完成之后，却发现原本主干中的程式码与建立分支时有相当大的落差，这是由于其他人在我们的工作进行时，也不断的把所开发的程式码加入到主干之中，所以当我们开发完成要合并程式码回主干的时候，就会有大量的合并冲突(merge
conflics) 必须要解决。随着我们的组织越庞大，分支越繁杂，这样的情况也会越来越严重。

因此在2010 年时，我们开始针对程式码分支的规划进行了改变，我们大量删减了原本过于繁琐的程式码分支架构，只留下了少数几个分支，而这些分支通常也只是暂时存在。我们同时明确的针对程式码开发流程进行了改善，减少程式码从主干切出分支进行开发到合并回主干让其他人可以使用的时间。接 我们尝试转换目前所使用的版本控制系统，虽然我们大部分的客户和合作伙伴都是使用中央化的版本控制系统，但我们仍然决定改为使用分散式的版本控制系统(例如Git)
，当然，Visual Studio Online 和TFS 都有支援这两种版本控制系统。使用Git 的好处是它相当的轻量，并且由于分散式系统的特性，可以很轻松的在本地端建立暂时性的分支结构，不会影响原本远端的分支，所以我们可以在任何需要的时候开启新的分支，当完成工作并将程式码合并回主干后就把这个分支删除，让分支不会过多，管理起来更容易。

同时再搭配发送pull-request 的工作流程，让Code Review 和程式码品质控管可以同时完成，当pull-request 中的程式码内容被审核人员确认无误之后，就会立即的合并回主要分支(Master Branch)，也就是原本的主干之中，这让我们程式码开发流程是顺畅且严谨的，而且由于每一个分支相当轻量，就比较不容易发生因为在分支上开发过久，开发人员必须花费相当大的精力保持与主干的程式码同步。

搭配这套流程可以把开发人员的工作周期相对的缩短，由原本冗长的开发时程，转变为一个一个短周期的工作项目，也让完成工作项目变得更加容易，并且随时可以合并回主要分支中，达到一个更容易持续整合的循环，分支也不会因为离开主要分支过久，而有许多合并冲突要解决，一旦我们完成工作合并回主要分支后，所建立出来的分支随时都可以删除，让分支的管理工作更容易进行。

保持敏捷

我们虽然决定要使用DevOps 作为新的流程，但我们一样会继续遵循着Scrum 的精神，Scrum 有着让我们能够方便进行沟通的优点。举例来说，我们的主要工作团队单位是以开发某项特定功能来视为一个小组，约莫等于Scrum 的一个Team，Product Owner 会坐在我们团队的中间，与我们一同工作，Product Owner 和工程师的主管共同代表着我们工作团队的意见。

我们遵循着让团队独立自主，并努力增进团队之间的认同感，这也会让一些化学效应开始发生在团队之中，我们团队的成员都是多才多艺的，我们也不会特别区分开发人员或是测试人员，而是只有一种共同的工程师角色。(这点对于提升士气十分有帮助)

我们尽可能的让团队成员互相熟悉，在每个功能开发团队中约有8~12 个工程师，我们让团队成员至少一起工作12~18 个月，甚至更久。当工作量超出团队负荷时，我们也不会对团队成员施压，希望他们能够自己消化满出来部分的工作，而是寻求其他团队的帮助，帮我们分担这些工作内容。

同时，我们让每一个功能开发团队坐在同一个团队工作区(参考图一)，每个团队拥有一个专属的房间，而并不只是开放空间的一部份。团队成员除了坐在一起工作之外，也能够随时进行沟通，不用担心打扰到其他功能开发团队。除此之外，团队工作区附近还有许多小房间提供成员进行需要专注的工作，或是暂时性离开团队进行思考或放松，基本上每个团队成员在工作区中都是非常自在的，甚至当需要进行每日站立会议时，只要在自己的座位上站起来就可以开会了！



功能开发团队的成员们一起坐在团队专属的房间中

我们通常会根据经验来规划三周的Sprint，对我们来说，要能够在这么短的周期中，替一个在全球都提供服务的网站，开发出具有足够价值的功能是相当困难的。但是如果开发周期过长，可能会让功能开发充满各种不安因素，也无法确保自己所开发功能的方向是对的。在微软的某些团队甚至使用两周的Sprint，让他们可以快速根据线上功能使用情况的反馈，不断修正自己所进行开发的项目的方向是否正确，而不是让Sprint 沦落为计算时间的单位。

透过这种开发模式，要验收功能开发的完成也非常简单，当开发人员完成自己新功能的开发之后，这些新功能会在Sprint 结束后发布到上百万的使用者面前让他们使用，而当新功能在线上发生的异常时，开发人员也会马上知道，并且很快的找出发生异常的原因，并且修正它。

我们的Scrum Master 是由团队成员轮流担任的，这也让每个人都有机会学习怎么作为一个好的Scrum 领导者，我们同时尽可能的让Sprint 的进行更加轻量化，只保留了Sprint 透明好沟通的优点。在Sprint 开始时，每个功能开发小队会从产品的backlog 中认领想要进行的工作项目，并且撰写一页Email 说明他们的开发计画，信中会附上backlog 在Visual Studio Online
上的连结供大家浏览backlog 内容，而Sprint 开发结果的检验也是透过更新这个mail，如果需要的话还会再额外附上三分钟的简短说明影片，影片中将会以客户的角度来说明如何使用团队开发的新功能，以及这个新功能有什么优点。

我们让团队规划尽可能的精简，通常我们会定下未来十八个月的目标，做为我们开发的主要方向，而这些目标通常是透过一些操作上的需求、想像功能使用的情境、概念影片或是简短的构思文件来决定的。每隔六个月，我们团队与团队间也会根据需求互相交换开发项目或是合作伙伴，每隔三个Sprints，功能开发团队的队长也会一起进行新功能的跨团队沟通会议，分享交流团队工作内容的优先顺序，确认自己团队进行的方向没有偏离目标，同时交换新资讯和同步不同小队间的讯息。举例来说，我们可能会透过功能会议来重新决定我们开发新功能的顺序以及开放哪些新功能给使用者使用。

根据使用者经验调整方向

在传统的Agile 开发流程中，Product Owner 会决定产品Backlog (PBIs) 的优先顺序，PBIs 也通常被视为开发时的需求。PBIs 会使用使用者故事(User Story) 的方式来撰写，虽然PBIs 的概念是有弹性的，但决定之后不太会去改变它，我们以前也是使用这种方式进行开发。

但为了转换到DevOps 的开发流程，我们并没有使用这样的模式太久，我们尝试着把原本的PBIs 转变为假设性质的项目，假设使用者的使用情境以及需要的功能，再根据这些项目来进行功能开发，完成后就部署到线上环境提供使用者使用，然后收集使用者的反馈以及使用情况的数据，利用这些数据来证明或否定我们的假设方向是否正确，透过这种验证学习循环(Validated learning ) 的方式来确保假设的方向是正确的。

而要能够执行有效的循环必须要具备有意义的统计样本资料，以及对照组资料来互相比较数据，判断所收集的资料是否合理，当然你也必须要了解影响这些数据的因素是什么，才能够针对这些数据进行评估。你可以参考图7~11 的范例，我们发现使用者在开始使用Visual Studio Online 时，通常不会马上建立团队专案(Team Project)，但是如果没有团队专案的话，使用者就没办法实际操作或体验Visual Studio
Online 的好处以及带来的便利性，下图二中呈现了以前进入Visual Studio Online 页面的样子。



由于使用者必须要输入很多资料，以及进行许多步骤才能开始使用Visual Studio Online，导致使用者对于试用兴趣缺缺

由于以上的原因，我们修改了Visual Studio Online 在网页和IDE 中的操作体验。图三中呈现了我们让使用者能够Visual Studio 中，透过两个步骤，就能建立Visual Studio Online 帐号，以及建立团队专案，修改完成后，我们开放这项功能到其中两个Scale Units 进行实验(总共六个Scale Unit)。



我们在两个Scale Unit 中，开放改善IDE 建立团队专案流程的功能

我们在IDE 中改善建立专案流程的实验结果可以在图四中看到。这个改善增加了新使用者建立团队专案的数据，从3% 提升到20%，足足有7 倍的提升。



IDE 建立专案流程的改善，让新使用者建立团队专案的机率从3% 提升到20%

同时，我们也改善了Web 版本的注册流程，从画面上可以看到是完全不同的注册画面，在图五中可以看到我们对Web 版本登入画面的改变。



可以看到我们简化了Web 版本的注册流程，并把团队专案的建立移到第二屏

我们计算了在注册同一天也建立团队专案的使用者人数，人数从接近18% 提升到30% (1.7 倍)，可以看到图表中从深蓝色变为紫色的部分，相对于IDE 改变后的数据成长，在Web 版的改善率这么低让我们感到十分讶异。



由于另外两个新功能的结果不如预期，导致Web 版本建立帐号流程改善的效果不好，在我们关闭其中一个结果之后，主要的结果就更清楚了。

根据追查之后发现，这次的新功能发布除了Web 登入流程改善之外，同时间还有另外一个实验也在进行，导致许多不被预期的使用者也被引导来进行帐号注册，然后没有继续进行更进一步的使用，也因此登入流程改善的数据被影响了，增长的数据就没有那么的明显。这其实也是一个不正确对照组数据的好例子，两个实验的结果互相干扰，当我们停止另外一个实验的干扰之后，团队专案被建立的数据就上升了，可以参考上表中的浅蓝色部分，数据上升到了50%
(2.8 倍的成长，也是IDE 数据的2.5 倍)

上面的例子告诉我们，实验的结果可能有好有坏，而对的实验不一定会在一开始就有好的成长，就算这个方向是对的，我们还是必须继续进行反覆的实验，根据实验结果调整并再次验证，才能证明实验的方向是否正确。