技术推广曲线(Technology Adoption Curve

实施历程

小组从版本发布开始，承担了推动我司持续集成与持续交付赋能和平台建设的职责。其中，历经大约1年时间，完成了公司代码配置管理从SVN向Git迁移的过程，目前大约有超过50个系统，100多人在使用Git/Gitlab。回顾来看，整个过程比较符合Everett Rogers所著的《创新的扩散》(Diffusion of Innovations)一书中所提出的技术推广曲线(Technology Adoption Curve)，如下图所示。

Technology-Adoption-Curve.jpg

图1技术推广曲线(Technology Adoption Curve)
摘自：https://www.no2ndprize.co.uk/next-step-introduction

阶段1- 技术创新者(Innovators)

在这个阶段，测试中心版本发布小组在承担公司试点项目的过程中，按照既有SVN的代码管理模式实现了部分持续集成的目标。在这个过程中，也发现了许多工具、流程上阻碍组织持续集成和交付的障碍点和待改进项。其中最具可行性的是，通过将代码管理工具从SVN向Git/Gitlab进行迁移，充分利用新工具良好的工具链支持，来提升组织的持续集成成熟度。在这个阶段，推广者自身需要对既有工具流程熟悉，对新工具需要掌握，并构想出符合改进目标的新流程方案，并努力将自身打造为新工具的专家熟手形象，为进入试点阶段做好准备。

阶段2-早期使用者(Early Adopters)

该阶段的第一个里程碑的标志性事件，是有一个开发部门负责人愿意加入持续集成和持续交付试点，希望能借此提升部门交付能力和交付质量。作为整体方案之一，SVN向GIT迁移成为试点的重要组成部分。而挑选该部门作为试点的一个重要原因，是该部门绝大部分开发资源正在承接某新一代系统的7个子系统的开发，且该业务系统相对独立。并且该系统采用了新的开发语言和系统架构，开发人员对于新技术的接受程度较高。

在协商确定了试点意向后，后续的主要工作是通过了解开发模式，梳理配置管理需求，并提出代码迁移方案，确定迁移时机，编写使用手册并实施多轮次的工具和流程规范的培训。

另外有两点笔者认为促成试点成功的做法，首先是亲自迁移，其次是热线支持。在反复沟通迁移方案，通过试迁移和对比等方式打消对方顾虑之后，小组代替开发人员完成了代码库迁移的工作。避免了对方因为畏惧心理、开发任务紧急等原因造成的进度延迟。另外，在迁移实施完成，开发人员正式启用Git/Gitlab来管理代码的前三天，小组成员临时将工位搬到开发人员工位区域进行现场支持，后续也提供电话/聊天工具的技术支持。在解决了提交冲突、分支基线混淆等问题，开发了数据库增量发布脚本，克服了开发人员想退回SVN等挑战后，顺利度过了这个新技术磨合期。

阶段3-早期使用大众(Early Majorities)

这个阶段开始较大规模的进行推广Git/Gitlab的使用，其里程碑事件是将其引入了业务系统季度版本。作为最大规模的常规发布版本，每次发布涉及至少10个以上的系统，通常由3个部门的几十位开发人员协同开发。

为了能顺利实施，小组首先锁定了业务系统月度版本的主要负责部门，根据业务系统的特点有针对性地推荐了基于特性地分支模型，并邀请成功试点的团队来现身说法，最终让该开发部门负责人同意切换。然后再确定在一次版本发布之后的时间点上来实施切换，在基本没有代码提交的时间窗口期实施切换，并且依旧由小组来实施切换，开发人员只要负责验收即可。当然，培训和热线支持在这个阶段还是必须必要地。

阶段4- 晚期使用大众(Late Majorities)

在阶段3顺利完成业务系统季度版本切换到Git/Gitlab进行管理之后，本阶段的工作就是成为了常规性的系统迁移了。随着每次版本的开发和发布，就会有若干个本次发布涉及到的系统被迁移过来。另外随着版本交付节奏从季度版本提速到月度版本，系统迁移的速度也大大加快了。在经历了半年时间之后，基本上常用的业务系统均已经迁移过来了。在这个过程中，小组也不在为各部门进行系统迁移，而是由各个部门的接口人自行完成，小组提供操作手册、FAQ等文档的方式进行支持。当然，由于各部门在前期均已较为广泛的使用Git/Gitlab,这个阶段的热线支持也很少了。

阶段5- 顽固派(Laggards)

进入这个阶段的一个重要里程碑是，SVN代码库被认定为是一个遗留系统，持续集成和持续交付的实践以及工具链解决方案，也不再考虑对SVN的支持。少量留守在该系统的开发人员如果不愿意迁移的花，需要自行搭建CI或者手工构建版本来交付。迁移的话，也是按照wiki上提供的手册自行迁移。