代码管理

引言在阿里外部，风行着许多有意思的工程实际。有些实际通过工具和流程嵌在团体的大环境里，外界不容易复制，有些实际则是表露在大家的日常习惯里，被默默的恪守。比方分支治理这件事，其实属于工具和习惯各占一半，并且颇有阿里特色的成分，适宜作为一个例子。阿里有很多的研发团队，不同事业部应用的公布流程、分支策略并非整齐划一，但总体上看是比拟规整的。其中有一种支流的公布模式以及对应的分支应用形式，称为“AoneFlow”。这套工作模式思路独特，在阿里以外的中央并不多见。本文围绕这些实际，聊一聊分支治理的话题。 作者：林帆（花名金戟），阿里巴巴研发效力事业部技术专家。 细数分支模式说到分支管理模式，咱们最耳熟能详的莫过于 TrunkBased 和 GitFlow。 TrunkBased 模式是继续集成思维所崇尚的工作形式，它由单个骨干分支和许多公布分支组成，每个公布分支在特定版本的提交点上从骨干创立进去，用来进行上线部署和 Hotfix。在 TrunkBased 模式中，没有显性的个性分支。当然实际上 Git 的分布式特色天生容许每个人有本地分支，TrunkBased 也并非排挤短期的个性分支存在，只不过在说这种模式的时候，大家通常都不会明确强调它罢了。 尽管近年来有许多不错的案例，但 TrunkBased 模式并没有一统天下。它的毛病比拟显著，太多的团队同时工作在骨干上，到公布的时候就可能呈现劫难（尤其是多版本并行开发的状况）。补救的措施是 FeatureToggle 以及频繁的集成和足够的测试笼罩，这对开发团队的能力提出了比拟高的要求。目前 TrunkBased 模式次要用在不须要同时保护多个历史版本的 SaaS 型我的项目，特地是通过微服务革新的各种小型服务上。 TrunkBased 模式有两种常见演进版本。OneFlow 模式参考了 TrunkBased 的许多思维，对操作流程做了更严格的定义，减少了 Hotfix 分支等内容。多骨干模式（通常是双骨干，固定的开发分支和固定的公布分支），算是 TrunkBased 采纳固定公布分支的特例，在晋升团队的微服务落地能力这篇文章里介绍过，不再赘述。 GitFlow 模式是若干模式的集大成者，蕴含一个骨干分支、一个开发分支、许多的个性分支、许多的公布分支和 Hotfix 分支，以及许多繁琐的合并规定。它有一个 Git 插件，不过早就没人保护了。因为对每个阶段的每项操作定义十分明确，它已经是很多器重流程的企业眼里的香馍馍。但它应用起来并不是很容易，大量的合并抵触和对集成测试不敌对也是它被诟病最多的中央。 对，还有 GithubFlow 模式，不过这种策略无非是在 TrunkBased 的根底上，减少了集体仓库和 Pull Request 合并代码的操作，与在同一个仓库里减少集体分支的做法相似，从实用的意义来说，它更适合分布式团队。GithubFlow 也有演进版本，例如强调了多环境部署和将仓库或分支与环境关联的 GitlabFlow 模式。 要么简略粗犷如 TrunkBased，要么繁琐简单如 GitFlow。难到真没有其余抉择了吗？ 另辟蹊径的 AoneFlow在 AoneFlow 上你能看到许多其余分支模式的影子。它基本上兼顾了 TrunkBased 的“易于继续集成”和 GitFlow 的“易于治理需要”特点，同时躲避掉 GitFlow 的那些繁文缛节。 看一下具体套路。AoneFlow 只应用三种分支类型：骨干分支、个性分支、公布分支，以及三条根本规定。 规定一，开始工作前，从骨干创立个性分支。 AoneFlow 的个性分支根本借鉴 GitFlow，没有什么特别之处。每当开始一件新的工作项（比方新的性能或是待解决的问题）的时候，从代表最新已公布版本的骨干上创立一个通常以feature/前缀命名的个性分支，而后在这个分支上提交代码批改。也就是说，每个工作项（能够是一个人实现，或是多集体合作实现）对应一个个性分支，所有的批改都不容许间接提交到骨干。 ...

阿里云云效，云原生时代新 DevOps 平台，反对公共云、专有云和混合云多种部署状态，通过云原生新技术和研发新模式，助力翻新守业和数字化转型企业疾速实现研发麻利和组织麻利，打造“双敏”组织，实现 10 倍效力晋升。 云效的作用 咱们的工作充斥着大大小小的【我的项目】、【工作】：流动策动，工程施行、IT研发、风险投资等等，应用云效做【我的项目化】治理，团队布局工作时指标更清晰，执行更到位，而且实现过程也非常轻松，成员将有全新的合作体验。 云效我的项目合作是什么？ 每一个市场都在赛跑， 应用云效我的项目合作打造一体化研发合作流程，借助业余工具，让团队体现更优异，产品更快响应需要变动。全面反对「看板」和「Scrum」麻利办法，你能够围绕产品指标灵便布局每个迭代冲刺。实时数据反馈，让打算调整更及时，团队成员踊跃应答变动，继续交付价值。你的产品交付，能够远超预期。立刻体验理解更多信息 云效测试治理是什么？ 「测试治理」蕴含对测试计划与执行用例的创立、编辑、布局与关联等性能，让测试人员能够间接在云效的我的项目中进行测试工作的布局和执行停顿反馈，并将「测试计划」与「需要」和「缺点」一起进行治理。 立刻体验理解更多信息 云效代码治理 Codeup 是什么？ 云效代码治理 Codeup 是阿里云出品的一款企业级代码治理平台，提供代码托管、代码评审、代码扫描、品质检测等性能，全方位爱护企业代码资产，帮忙企业实现平安、稳固、高效的研发治理。 立刻体验理解更多信息 云效流水线Flow是什么？ 「流水线」，又名「Flow」，是「云效」产品矩阵中一款企业级、自动化的研发交付流水线， 提供灵便易用的继续集成、继续验证、 继续公布性能，帮忙企业高质量、高效率的交付业务。流水线是继续交付的载体，通过构建自动化、集成自动化、验证自动化、部署自动化，实现从开发到上线过程的继续交付。通过继续向团队提供及时反馈，让交付过程高效顺畅。 立刻体验理解更多信息 云效制品仓库是什么？ 制品库顾名思义是制品的仓库，制品是软件交付的成绩性产物，通常是可运行的二进制模式，因而制品库通常也被称之为二进制制品仓库。云效制品库致力于帮忙开发者对立治理各种开发语言在开发、构建过程中的依赖，构建成绩（二进制制品）以及交付过程要害信息的重要组件。制品库连接继续集成和继续部署，是继续集成的成绩治理仓库，也是继续部署的物料起源，同时也为研发的动态平安提供保障。现阶段云效的制品仓库反对 Maven 、NPM类型仓库，后续还将提供一下的仓库类型，敬请期待：HelmDocker镜像一般构建产物 立刻体验理解更多信息 云效知识库是什么？ 云效知识库是一款企业 常识治理 工具，通过独立的知识库空间，结构化地组织在线合作文档，实现企业常识的积攒和积淀，促成常识的高度复用和流通。 立刻体验理解更多信息 云效 DevOps 的劣势 阿里云 云效提供了更优质的应用体验，更多便捷的企业级个性，新增了独立的知识库、测试治理性能。 「我的项目合作」：提供多种研发我的项目模板。与云效「代码治理」和「流水线」联合，打造一站式、端到端、全栈麻利的软件研发 DevOps 我的项目。「知识库」：独立的知识库空间，结构化地组织在线合作文档。并提供知识库公布性能，将全副或局部内容公布到公共网络或分享给企业外人员。「代码治理」：继续收费的同时，反对容量扩大，提供了更优质的体验和更多平安、智能化的企业级个性。「测试治理」：测试用例库治理既能够独立应用，对立标准用例，也能够在我的项目中的测试计划中应用数字化协同测试过程。「流水线」：更优质的应用体验，更多便捷的企业级个性。「制品仓库」：全新的企业级公有仓库服务，用于治理企业级依赖托管。

云效依赖破绽检测，高效杜绝代码安全隐患，据不齐全统计 78% 的企业都在应用开源，但这些开源依赖包的安全性呢？开源依赖提供方通常没有较多的估算进行安全性测试，危险系数极大。应用云效提供依赖包破绽检测服务，可能杜绝代码安全隐患。 限定语言：Java、Python、Golang、Node.js 为什么须要关注依赖包破绽在开发过程中应用依赖包破绽检测越来越常见，无论是二方还是三方依赖，它帮忙咱们共享成绩，重复使用别人开发的软件库，让咱们可能专一于本人的翻新，进而推动技术的疾速倒退。 针对三方依赖包场景，据不齐全统计 78% 的企业都在应用开源，然而他们是否有关注过这些开源依赖包的安全性呢？开源依赖提供方通常没有较多的估算进行安全性测试，黑客的次要攻打指标也是这些开源包内存在的破绽，一旦击破一个，其影响范畴很大。 为了杜绝安全隐患，企业须要做到以下三点： 理解工程都应用了哪些依赖包；删除不须要的依赖包；检测并修复以后依赖的已知破绽；依赖包破绽分级云效Codeup 提供依赖包破绽检测服务，帮忙企业不便的查看其工程依赖包的安全性。依赖包破绽等级分为：BLOCKER,CRITICAL,MAJOR，等级划分依据NVD国家破绽数据库CVSS分数评估制订。BLOCKER: 高危破绽，倡议立刻修复；CRITICAL: 中危破绽，倡议尽快修复；MAJOR: 低危破绽； 开启扫描代码库管理员角色有权限开启或敞开扫描。点击代码库导航中「平安」模块，即①，展现以后可用平安服务列表。如果你是代码库管理员，可点击②间接返回库设置开启服务；如果不具备库管理器权限，可分割代码库管理员开启。 管理员点击②后进入代码库设置，抉择 「集成与服务」-「依赖包破绽检测」进行开启。在弹出的 「用户承诺书」窗口中，浏览并勾选 「我已浏览相干协定并确认开明服务」，而后点击「确认」后开启服务。触发形式：依赖包破绽检测目前反对「代码提交」触发主动扫描。检测参数：目前反对的检测语言类型 JavaGolangPythonNode.js对于Java 语言，须要执行编译命令以构建打包剖析，Codeup 已为你提供了默认编译命令，如无非凡传参要求，可间接运行应用。开启后返回平安模块，可见依赖包破绽检测服务：执行扫描开启服务后将主动触发「默认分支」的扫描行为，其余分支须要被动触发。点击①切换分支，若以后分支未执行过扫描，可点击②手动触发一次扫描：查看扫描后果 以后分支存在扫描后果时展现如下，每行为一个存在破绽问题的依赖包。 因为此处扫描均是基于提交进行的，点击①处可查看以后扫描后果对应的提交详情；点击②处可查看单条存在破绽的依赖包详情：最佳修复计划举荐开展依赖包问题详情，当存在修复计划的时候，①处将为你生成最佳举荐，以帮忙你疾速解决依赖包平安危险问题：破绽详情 ②处展现了以后依赖包内波及的全副破绽问题列表，点击可开展破绽的具体阐明：提交列表查看当存在新提交时，零碎将主动执行扫描，通过扫描后果卡片页面能够疾速查看依赖包破绽检测后果：综合剖析应用云效依赖破绽检测，可能高效杜绝代码安全隐患，云效代码治理 codeup是阿里云出品的一款企业级代码治理平台，提供代码托管、代码评审、代码扫描、品质检测等性能，全方位爱护企业代码资产，帮忙企业实现平安、稳固、高效的研发治理。

代码扫描在当代企业，离不开软件技术。软件是工程师编写的，不免可能存在品质或平安问题，这些问题可能在生产环境中引发重大的故障，间接造成企业的经济损失和信任危机。为了将危险降至最低，倡议在编码过程中启用一系列的自动化扫描服务-代码扫描，尽早的发现问题，将危险扼杀在摇篮中。1 、用户的诉求或问题•编码不标准：开发者业余度无限，特地是依赖外包团队的状况，业务代码通常没有通过粗疏的设计，也很难保障兼容性和扩展性，存在暗藏的缺点和故障危险；•敏感数据泄露：开发者不足安全意识，企业的敏感信息间接编写到代码中，可能造成敏感信息的外流，进而使得不法分子无隙可乘，造成企业损失；•依赖项存在安全漏洞：代码中免不了引入二方或三方的依赖包，特地是引入开源依赖包的场景下，很可能本身代码爱护周全，然而依赖的代码存在安全漏洞，使得不法分子能够通过这些破绽发动攻打；•代码优化：开发者编写了代码，冀望可能失去业余的代码优化倡议；2、代码扫描启用服务云效代码治理内置了多种扫描服务，为了保障每次提交都能及时的获取扫描后果，倡议在创立代码库后，立刻返回代码库「设置」-「集成与服务」开启自动化扫描服务。 点击冀望开启服务右侧的开关，确认受权后服务胜利启用。 启用时能够抉择触发形式：提交触发或合并申请触发，局部服务仅反对一种触发形式。「提交触发」在每次提交后，将主动触发相干分支的全量扫描，即扫描分支下的所有内容；「合并申请触发」在创立或更新合并申请后，将主动触发源/指标分支的增量扫描，即扫描源/指标分支变更的内容（Diff）；如不再应用扫描服务，点击服务右侧开关敞开即可。接下来顺次介绍上诉四种扫描服务。代码品质——Java 开发规约《阿里巴巴 Java 开发手册》是阿里外部 Java 工程师所遵循的开发标准，涵盖编程规约、单元测试规约、异样日志规约、MySQL 规约、工程规约、平安规约等，这是近万名阿里 Java 技术精英的经验总结，并经验了屡次大规模一线实战测验及欠缺。依据约束力强弱，规约顺次分为强制、举荐、参考三大类：【强制】必须恪守。是不得不恪守的约定，违反本约定或将引起重大的结果。【举荐】尽量恪守。长期恪守这样的规定，有助于零碎稳定性和单干效率的提醒。【参考】充沛了解。技术意识的疏导，是集体学习、团队沟通、我的项目单干的方向。Java 代码规约扫描应用《阿里巴巴 Java 开发规约》插件扫描 Java 规约问题。代码品质——代码补丁智能举荐缺点检测和补丁举荐几十年来始终是软件工程畛域的难题，又是研究者和一线开发者最为关怀的问题之一，这里讲的缺点不是网络破绽、零碎缺点，而是暗藏在代码中的缺点。帮忙开发者辨认这些缺点，并进行修复，可能大幅晋升软件品质。基于业界和学术界较为风行的缺点检测伎俩，并剖析和躲避其局限性，云效代码治理的算法工程师们提出了一种新的算法，实现更加精准和高效的剖析代码缺点并举荐优化计划，该算法已被国内软件工程大会（ICSE）收录。代码补丁举荐服务目前利用于合并申请的代码主动扫描场景，扫描输出优化举荐计划，问题等级仅蕴含 MAJOR 类型：倡议修复的代码缺点。代码平安——敏感信息检测敏感信息检测性能，能够检测代码库中的敏感凭证和密钥，比方 API keys 等信息。集成在合并申请代码评审阶段，能够无效避免敏感信息意外提交。敏感信息问题等级分为：BLOCKER, CRITICAL, MAJORBLOCKER: 通过规定扫描进去的可能性很高的明文问题；CRITICAL: 通过信息熵模型得出的可能性较高的潜在问题；MAJOR: 用于测试的敏感信息字段；代码平安——依赖包破绽检测为了杜绝安全隐患，企业须要做到以下三点：1.理解工程都应用了哪些依赖包；2.删除不须要的依赖包；3.检测并修复以后依赖的已知破绽；依赖包破绽检测服务帮忙企业不便的查看其工程依赖包的安全性。依赖包破绽等级分为：BLOCKER, CRITICAL, MAJOR，等级划分依据国家破绽数据库CVSS分数评估制订。BLOCKER: 高危破绽，倡议立刻修复；CRITICAL: 中危破绽，倡议尽快修复；MAJOR: 低危破绽；3、提交代码执行检测 为了保障代码问题不被引入生产环境，越早进行查看，引入的危险越小。因而，倡议可能在每次提交时都进行代码检测，从终点发现并扼杀问题，保障后续利用研发流程的稳定性。开启检测服务时，勾选触发形式的「代码提交触发扫描」，如图①： 尔后库内的每次提交都会主动执行对应的自动化检测，检测以后新提交的所有文件，可在源文件或提交页面查看检测后果： 可点击检测服务开展问题详情查看，Blocker 级别的问题倡议立刻解决，这类问题容易引起故障或安全漏洞：4、合并申请执行检测开启检测服务时，勾选触发形式的「合并申请触发扫描」，如图②：尔后库内的每次创立合并申请或合并申请源分支有新提交，都会针对变更文件主动执行对应的自动化检测，保障新增冀望合并至指标分支的代码品质和平安。可在合并申请列表和详情页面查看检测后果：点击合并申请详情的检测后果详情，能够跳转代码行内查看具体问题代码：5、平安检测针对安全类问题，通常须要统计或追溯历史，因而云效代码库中提供了专门的平安模块，用于承载检测出的全副问题，并记录了已解决的历史数据。若未开启过安全类检测服务，能够通过平安模块返回代码库设置-「集成与服务」中开启。开启后，能够在当前页查看各分支检测出的平安问题：同样，可点击问题名称查看详情和举荐的解决方案：TIPS：针对敏感信息检测，若局部文件心愿跳过扫描，能够应用文件白名单的性能，白名单内的文件将不被检测：总结应用代码扫描将测试左移，对每次提交和合并进行自动化检测，保障存量和新增代码的品质和平安，可能无效的晋升研发效率，助力企业更好的实现业务价值，代码扫描，尽早的发现问题，将危险扼杀在摇篮中。

环境需求最低硬件配置：1核CPU，1G内存（1+1）提示：如果你的应用较多，而主机节点的硬件配置较低，建议在部署节点时开通虚拟虚拟内存；生产环境建议使用2G或以上内存；推荐安装系统：Ubuntu-16.04、Ubuntu-18.04、CentOS7.X、Debian9X的64位的纯净的操作系统；URLOS安装curl -LO www.urlos.com/iu && sh iusubversion服务安装流程登录URLOS系统后台，在应用市场中搜索“subversion”，找到之后，直接点击安装按填写服务名称、选择运行节点、服务端口号、选择智能部署填写ssh密码然后点击“提交”按钮，等待部署完成；签出代码库 svn checkout svn://ip/project # 这里的ip是你服务器的ip用户名是：admin密码是：urlos520

阿里妹导读：研发效能分为两块，一是用技术的更新来提升效率；二是提高整个技术生态中的协同效率，激发技术活力。阿里巴巴技术团队在此基础上要实现的终极目标是打造7*24小时灵活发布的通道，以及提供更快的业务代码迭代能力。今天，阿里巴巴高级测试开发专家傲野为你带来关于研发效能的一些思考，希望对你有启发。7*24小时发布窗口的实现其实并不简单，受限于很多因素。我简单地进行了分解。 一、系统先从最基础的开始说，当一个创业团队只有几个人，一两个系统的情况下，是可以不考虑研发效率这回事的。因为不存在系统间的依赖，系统内的依赖也完全在一个可控的范围内，本地起一个 Tomcat 或 Apache 就能开发、调试。另外再加上团队成员之间的高频交流，基本上可以实现随时随地，想发就发的要求。 当业务逐渐复杂，开发人数扩展到10几个人时。提效的第一步是理清系统内的依赖关系，并促进角色的专业化。这也是大家所熟知的MVC，通过对视图、模型、控制器的分离，对系统内的逻辑进行分层。把复杂的代码逻辑下沉到Model层，而视图层交由更专业的前端来负责。 当然，在系统内部仍然有一些扩展的空间，比如模块化，为不同的业务划分bundle等。但仍然没有突破本身的瓶颈，而且单一的系统也很难突破机器的特性。 二、架构当技术团队已经达到几十个上百人的规模，当业务已经无法通过单一的应用来进行水平扩展时。分布式的架构是解决问题的有效手段。在07年时，阿里集团就在推进SOA化，无论是淘宝还是支付宝，原来的单一应用不断被拆分出来，也在此时，承载服务化中枢的消息等中间件蓬勃发展。 这种方式实现了系统之间的解藕，激活了技术人员的生产力，同时增大了系统的弹性，实现了服务能力的低成本水平扩展。但因为复杂的调用关系，对于某一个贯穿多个应用的项目来说，无疑增加了集成的成本和质量的风险。 同时，如果对应用规模不加以规划和控制的话，会导致应用数的不断扩张，从而影响到整体的开发维护成本。 三、配置管理在5 - 10年前，阿里是有一个专门的岗位叫SCM的，负责技术团队内的代码管理，配置项管理和应用部署。特别是在服务化初期，开发人员的coding生产力被极度释放，应用数出现一个井喷，对配置管理的需求不断增强，并最终促使了配置管理的变革。 在讲配置管理前，先讲讲代码分支管理机制。这也是很多研发模式变革的起点。在此，笔者先表达自己的观点：没有对与错（先进与落后）的代码分支管理机制，只有适不适合自己团队当下以及未来发展的管理模式。 先从大的层面上来说，我们当前所讨论的都是为了解决并行开发的问题，即有多个项目或团队对于同一系列应用进行功能开发。如果仅仅是串行开发，是基本不用太考虑代码管理策略。 1、分支开发、主干发布。核心理念是使用固定的主干作为集成分支。使用分支进行开发，在合并到主干分支后生命周期终止。当然除此之外，还有紧急发布分支等。 2、分支开发、分支发布。发布成功后执行写基线操作，确保主干的及时更新和稳定。同时分支发布的方式不依赖于大集成，保持很强的灵活性。 体现在项目上的流程为： 3、其他模式：主干开发、分支分布等。由于我们并不常用，所以略过。 平台化的支持：早期配管的人肉化，也造成了代码集成和部署的效率很低。不同角色之间的协同靠人来完成。因此在那个背景下，还需要一个配套的PMO组织来保障。在这样一个历史背景下，Aone（对外版本是云效）也孕育而生，从平台化的角度来解决研发过程的协同、构建、集成和测试几个复杂的过程。为了更清楚的了解那个时期的痛点，我找了2009年左右的Aone的蓝图，可以管中窥豹（这个时期我并没有亲自经历过，只是针对于当时的前辈做了些访谈和收集了一些资料）。我猜想也正因为这条道路面向未来解决问题造就了现在的Aone平台。 四、测试当一个技术团队小，负责应用少以及业务的用户群体少时，是完全可以不用测试的。只有当业务发展到一定阶段，用户对于质量的容忍程度越来越低时，才引入专业的测试角色。其次，在软件离线交付阶段，由于软件的召回成本很高，所以对于测试是不遗余力的，但随着在线交付时代的深入，测试团队是否能够快速的实现软件质量的评测反馈，成为一个非常关键的问题。而也决定着，在打通上述各个环节后，7*24小时软件持续交付通道是否能够真正实现。 在讲之前，我们再回顾一下上个章节。Aone平台实现了开发代码、配置、应用部署的在线化，现在只剩下最后的一环：测试。从2010年以来，B2B的测试团队就希望可以把分层自动化平台跟Aone研发协作平台绑定在一起，通过系统调用的方式来实现一个测试的快速验证机制，并最终实现回归测试过程中的无人值守。 这个意义非常重大。应用的服务化后，技术的风险实际上是收敛的，大家都可以面向服务来进行开发，实现高内聚、构耦合。并且应用的发布也更加灵活了。但对于测试来说，却是极大的挑战。 1、测试的层次增加了。 2、测试的轮次变多了。每次集成，每次发布就有可能是一次完整的测试回归。 就如Aone的推进间接取替了SCM这个角色一样。研发平台的快速发展和业务7*24小时发布的诉求，也开始冲击测试在代码集成后的快速反馈能力。这是一个挑战，也是一个机会。否则，前期释放出来的所有生产力，最后全都被卡在了测试这最后一个环节，而且没有办法拆解（每拆解出来一个，测试工作量就增加一倍）。只能通过不断叠加集成的应用量来提高集成测试的效率。 经过1688测试团队几代同学的努力，现在我们在这个方面总算有了些成绩。我们已经通过分层自动化体系实现了60%以上发布测试的无人值守，并且全年拦截故障在数百个级别（含页面、UI等）。 它的实现逻辑如下： 五、文化至此，真正所谓的7*24小时业务的持续交付通道已经完全打造出来。我们再回顾一下。 1、应用内的架构分层，前端、后端、测试各应其职，通过专业化的力量激发了一轮生产力。 2、服务化的架构，让技术人员可以面向服务来进行业务的开发，实现了架构上的高内聚低耦合。进一步释放大规模技术团队的活力。 3、研发平台的搭建，提供了持续交付管道，实现了开发、测试过程的快速、准确传递。 4、依托于研发平台，实现了环境的自动化部署，应用监控，代码检查。扫除了研发过程的基建设施。让技术人员聚焦于代码的生产。 5、测试自动化验证体系，减少系统集成风险，提高集成的频率。最终实现了代码的快速上线。 本文作者： 施翔阅读原文 本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。

摘要： 科学的重构流程。原文：如何来一次说干就干的重构 (流程篇)作者：逐鹿 IT, 猛猛如玉Fundebug经授权转载，版权归原作者所有。前言随着公司业务的爆炸式的增长，需求规模和用户规模也迅速地膨胀起来，这样给系统的三高(高性能、高并发、高可用)以及扩展性、可维护性都带来了考验。而旧系统因为早期设计的各种局限性（如早期参与人员的水平、架构设计的前瞻性、老板的急性子等等），逐渐满足不了现状和未来的新需求，暴露出各种问题。开发人员们像是拖着老破车上高速，苦不堪言。（说人话：老系统代码的坑太深了，开发们填不住了，要么被坑埋了，要么弃坑逃跑了…）那么这个时候，通常要面临一个问题：是继续填坑还是跑路走人 选择重构。填坑是不可能的，这辈子都不可能的。而选择重构是需要壮士断腕的勇气，因为重构是一项老大难、一件耗时耗力的事情，且多少会对现有业务开发造成影响，甚至是停滞。因此大多时候得不到产品经理和老板的支持，他们关心的只有一个：下个需求什么时候能上！至于其他的，都是你们研发该操心的。自己选择的重构路，跪着也要走完。如何来一次就干就干的重构呢？根据互联网常见项目重构流程，以及我的亲身参与的重构项目经历，梳理大中小型系统的常见重构流程如下：零：说服业务方重构不单是研发团队的事情，更是整个项目团队的事情。重构可以提升系统的三高，也可以优化改善业务流程，满足新的业务诉求等等。重构需要投入大量资源，必须要得到业务方的支持。通常这个时候需要对他们晓之以理，动之以情，阐述清楚重构的利弊，以及不重构的要害。在得到他们的支持后，重构的工作便正式开展。参与人员：技术 Leader一：树立重构目标，有的放矢重构是一项工程，是一场持久战，它不是一两个迭代、甚至一两个月能做好的事情，需要投入大量的人力、物力、时间精力等。那么在这场旷日持久的战斗中，我们的目标是什么？是通过更优秀更合理的架构来满足系统三高的需求，还是想通过重构来提高代码质量，或者引入新的技术和框架来升级整个系统，抑或通过重构来优化业务流程，实现原来实现不了的需求。有了目标后，才能做到有的放矢。参与人员：技术 Leader，架构师二：确定重构的范围，并对重构作出预测重构通常有以下几个级别的重构平台级别重构。针对整体平台的重构，如阿里早期是 LAMP 架构，后来整体迁移到了 Java 平台。系统级别重构。针对业务系统的重构，如通过引入微服务架构或者 SOA 架构，分解单体应用。架构级别重构。如通过架构的调整和重新设计，改善原有架构的不合理之处。如通过分层使业务解耦，引入缓存设计提升系统高并发等。业务级别重构。常见为某些业务需求因为系统设计的不合理性导致无法满足或有缺陷满足，需要通过业务系统的重构调整或数据库的重构来解决。模块/代码级别重构。这是最常见的重构。通常指使用设计模式、封装继承、优化拆解代码，使得代码的结构更良好，运行效率更高。确定这次重构是属于什么级别，确定重构的整体范围的大小，确定重构的技术选型，进而对重构工作进行科学的评测和预估。比如需要投入哪些成本，需要投入的人力和时间是多少，在重构的过程中能否支撑正常业务需求等等。在有了这些预测后，也对业务方有个交代，尤其是当他们追在后面问什么时候能上新需求。参与人员：技术 Leader，架构师，研发人员三：旧系统的熟悉和业务梳理重构不是和旧系统说散就散，而是要不断和旧系统战斗的过程。知己知彼，百战不殆。重构不仅需要清楚新系统的目标和未来，更需要对旧系统非常熟悉(尤其是坑)。此时需要参与重构的人员(尤其是参与旧系统的人员)来对旧系统业务和系统进行梳理，对原有资料信息进行收益和整理的工作，对旧系统的关键代码和数据库设计进行 Review 等等。以下是重构旧系统前需要准备的常见工作：旧系统资料和信息的收集，包含且不限于系统相关的设计文档和技术文档等文档资料，架构图、UML 图，数据库设计 ER 图等图形化资料业务线和业务流程的梳理，整理业务线上的各大项目、业务流程，并输出为文档旧系统关键代码的 Review有相关疑难点及时与相关与业务线上的人员沟通，将问题解决在”襁褓”中。参与人员：技术 Leader，架构师，研发人员四：数据库重构如果在重构中需要涉及数据库的重构，数据库的重构一般是最先开始的一步。系统需要重构的直接原因，也大多和数据库有关。在数据库重构时，我们清楚旧系统中数据库的各种设计缺陷和使用障碍，那么就可以对症下药，如通过三大范式或反范式来设计表，是否需要分库分表等等。参与人员：DBA，架构师五：后台系统重构后台系统重构前，必须需要依照前文所述的一些设计和技术文档。这些文档输出后并经讨论成型后，架构师进行系统架构设计，后台开发人员进行具体编码工作。通常这个过程是耗时最长的，也是非常重要的一环。后台的架构设计水平，决定着系统重构的水平，业务代码的质量，决定着系统重构的质量。因为这个过程比较漫长，且成果无法立竿见影。所以通常采用敏捷开发的模式，通过迭代的方式来进行后台系统重构。迭代的方式有几个好处：需要将整个重构过程进行有效规划和量化，做到胸有成竹每个阶段能有可见的成果，确保团队在长时间的重构过程中不陷于泥潭对已重构好的部分可以及时进行联调测试或观察，不断在迭代中总结、在总结中迭代另外在后台系统重构时，也需要有明确量化的目标和标准，比如各系统和业务模块支持多少 QPS，接口响应时间多长时间等，这样团队才能在重构的过程中不至于为了重构而重构。在重构过程中，定期进行 Code Review，及时发现重构的问题和质量的问题，避免出现破窗效应，引入拙劣的设计或垃圾代码，进而破坏整个系统。参与人员：技术 Leader，架构师，研发人员六：数据迁移与检查如果涉及数据库重构时，在新的数据库设计好后，就会有面临数据迁移的问题。一般分为全量迁移和增量迁移，全量迁移是将旧系统的数据一次性迁移到新的数据库中，增量迁移是在实行全量迁移后旧系统新产生的数据迁移到新系统上来，增量迁移一直到旧系统下线不再产生新数据后。通常迁移都是通过编写脚本或程序来实现，拒绝人工操作。迁移后自然需要对比新旧系统的数据，同样可以通过脚本或程序来进行对比，查缺补漏，定位分析。参与人员：DBA，研发人员七：系统检查、联调与测试在后台系统重构到一定程度时，同样也需要编写脚本和程序来对新旧系统的业务接口进行检查，及时发现重构中的问题，必要时候进行架构调整和数据库调整。当然，在重构时，开发人员能提高单元测试覆盖率当然是更好不过。当各系统和模块的依赖解决的差不多时，可以开始联调工作。当然最后还需要系统性的测试，如功能性测试、稳定性测试、性能测试，本地测试、模拟线上环境测试等。测试中发现的问题经验证修复后，达到上线的标准，即可灰度上线。参与人员：架构师，研发人员，测试人员八：灰度发布与观察万里长征已经走到最后，也到了最紧要的关头。灰度发布时，只接入一小部分流量，并及时跟踪和分析线上的 log 与监控告警，一有问题及时解决。当新系统趋于稳定时，可以逐渐加大灰度发布的范围和接入的流量，同时继续跟踪线上 log 与监控告警。参与人员：运维人员，测试人员，研发人员九：系统切换在系统切换时，需要提前制订系统切换方案，包含相应的规划与流程，甚至是应急预案与回滚方案，避免走一步看一步。切换完成后，新系统完全替换旧系统，旧系统下线，完成重构。参与人员：运维人员，测试人员结语通过上述几个步骤后，我们成功对系统进行重构。重构是一项大工程，但经历重构后的系统也并非完美无缺。重构不是终点，更像是起点。关于FundebugFundebug专注于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java线上应用实时BUG监控。 自从2016年双十一正式上线，Fundebug累计处理了10亿+错误事件，付费客户有Google、360、金山软件、百姓网等众多品牌企业。欢迎大家免费试用！