关于敏捷开发:当代码农遇上码农揭秘主干开发的那些事儿-京东云技术团队

前段期间我负责部门外部骨干开发落地相干事宜，这个过程中，也真真切切的领会到了多人开发过程中，面对个性分支治理中，大家遇到的一些困扰，尤其面对麻利迭代的开发方式，合并抵触，集成测试，代码重用等方面，都与高效两个字背离。当然，我在推动骨干开发过程中，也遇到了一些问题和崎岖，在这里，集中的做一次分享。

骨干开发，是指开发人员间接向骨干（习惯上骨干分支通常为：trunk 或 master）提交 / 推送代码。通常，开发团队的成员 1 天至多 1 次地将代码提交到骨干分支。在达到公布条件时，从骨干拉出公布分支（通常为 release），用于公布。若发现缺点，间接在骨干上修复，并依据须要 cherry pick 到对应版本的公布分支。

长处：

分支模型简略高效，开发人员易于把握不容易呈现错误操作
防止了分支合并、抵触解决的困扰
随时领有可公布的版本
有利于继续集成和继续交付

毛病：

基础架构要求高：合入到骨干的代码若品质不过关将间接阻塞整个团队的开发工作，因而须要高效的继续集成平台进行把关；
自动化测试要求高：需有齐备单元测试代码，确保在代码合入主干前能在取得疾速和牢靠的品质反馈；
最好有代码评审：若代码品质要求高，须要配套代码评审（CR）机制，在代码提交到骨干时，触发 CR，通过 Peer Review 后能力正式合入；
最好有个性开关：骨干开发频发合入主干的状况下，个性拆分得很小，可能是半成品个性，须要配套个性开关（Feature Toggle），只有当个性整体开发完才通过灰度公布等伎俩逐渐关上；

实用环境：

对迭代速度要求高，心愿需要疾速交付上线
基础架构强，继续集成工具高效；
团队成员习惯 TDD（测试驱动开发），代码自动化测试覆盖率高（至多增量代码的自动化测试覆盖率高）；

能够通过执行以下操作来掂量骨干开发的成果。

测试的因素	掂量的指标	指标
利用代码库中的沉闷分支数。	掂量利用代码库版本控制系统中的沉闷分支数，让所有团队都能看到此数字。而后跟踪目标状态的增量式进度。	不超过三个沉闷分支。
代码解冻期。	掂量团队的代码解冻数及解冻时长。这些掂量指标还能够对合并抵触、代码解冻、稳固等方面所消耗的工夫进行分类。	无人提交代码时，没有代码会被解冻。
将分支合并到骨干的频率。	掂量合并的每个分支的二进制（是 / 否）值，或者掂量每天合并的分支的百分比。	每天至多合并一次。
查看审批代码更改所需的工夫。	如果您异步执行代码审核，请掂量审批更改申请所需的均匀工夫，并特地关注所需工夫大大超过平均值的申请。	设法使代码审核成为在开发过程中执行的同步流动。

如需全面采纳骨干开发，须要防止以下常见阻碍：

繁琐的代码审核流程 。许多组织的代码审核流程都较为繁琐，须要屡次审批能力将更改合并到骨干中。如果代码审核很费劲并且须要数小时或数天能力实现，开发者会防止小批量工作，改为进行大批量更改。因为大批量代码审核十分复杂，因而审核人员的审核工夫会缩短，进而造成恶性循环。
这样的后果是开发者防止应用合并申请，从而导致合并申请常常受到冷清。因为很难通过查看来推导大规模更改对系统的影响，因而审核人员很可能会疏忽缺点，骨干开发的劣势也就削弱了。
异步执行代码审核 。如果您的团队履行结对编程，那么该代码已由第二个人审核。如果须要进一步审核，则应该同步执行：开发者筹备提交代码时，应立即让团队中的其余人员审核代码。开发者不应该要求进行异步审核，例如向工具提交申请，而后在期待审核时启动新工作。合并延迟时间越长，就越有可能产生合并抵触和相干问题。如果执行同步审核，须要团队批准优先审核彼此的代码而不是解决其余工作。
在提交代码之前未运行单元测试或者自动化测试 。为了确保骨干放弃工作状态，在提交前对代码更改运行测试十分重要。此操作能够在开发者工作站实现，许多工具也提供针对本地更改近程运行测试，而后在通过测试后主动提交更改的性能。如果开发者晓得本人无需大量繁冗流程即可将代码提交到骨干，那么就会小批量更改代码，这些更改易于了解、审核、测试，并且能够更快地迁徙到生产环境。

小批量开发 。骨干开发最重要的推动因素之一就是团队学习如何小批量开发。这须要为开发团队提供培训和组织反对。
执行同步代码审核 。如前所述，转换为同步代码审核或至多确保开发者优先进行代码审核，有助于确保所做的更改不用期待数小时甚至数天即可合并到骨干中。
执行全面的单元测试和自动化测试 。确保您领有全面而实用的自动化单元测试套件，并在每次提交之前运行这些测试工具。
疾速构建 。构建和测试过程应在几分钟内执行。指标是将测试环境的 jdos 部署串联到整个 CI 的自动化流水线之中

如图所示，研发小伙伴基于 master 分支开发，当每次 merge 时，都会触发流水线验证过程。在流水线验证中：

1.EOS 代码扫描，该扫描会扫描代码中不标准的状况，依照代码规约不同，会有不同的级别，包含 WARNING, MAJOR, CRITICAL, BLOCKER 四种级别，基于不同级别能够设置拦挡规定，如果代码不合乎设定的拦挡规定，将不予 merge。

2. 代码评审会触发代码评审邀请，能够依据设定，邀请组内研发，leader，或者测试人员参加代码评审，通过设定规定，如果代码评审通过，才容许 merge。

3. 当初主动进行 maven 打包和单元测试工作，如果单元测试不通过，将不予 merge。

4. 流水线会主动将单元测试通过的 jar 包公布到测试的 JOS 分组进行部署，部署实现后主动调取线上自动化测试流程，只有所有接口通过自动化测试，才容许 merge。

利用架构：基于 spring boot junit 编写单元测试。

咱们能够将测试依照模块划分，放在不同的目录之下，能够分为集成测试和单元测试。这样做的起因是，当咱们的我的项目边的越来越大的时候，写的测试会越来越多，当所有测试都放在一个目录下的时候，跑一次集成测试工夫会很长。具体目录如下：

主开发目录	测试开发目录	测试模块	形容	测试父类命名
src/	test/	init	初始化测试模块	InitTestBase
unit	service 单元测试模块	UnitTestBase
jpa	长久化层测试模块	JPATestBase
mvc	controller 层测试	MvcTestBase

所有测试模块集成对应的父类，而后类名必须以对应模块 +Test 结尾，例如：ShipperStatisticUnitTest

引入单元测试依赖 spring-boot-starter-test

<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
</dependency>

2. 引入 surefile 插件

 <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.22.2</version>
                <configuration>
                    <skip>false</skip>
                    <includes>
                        <include>**/unit/*Test.java</include>
                    </includes>
                </configuration>
</plugin>

3. 配置测试配置文件门路

 <resources>
        <testResources>
            <testResource>
                <directory>src/test/resources</directory>
                <!--①-->
                <excludes>
                    <exclude>application*.properties</exclude>
                </excludes>
            </testResource>
            <testResource>
                <directory>src/test/resources</directory>
                <filtering>true</filtering>
                <includes>
                    <include>application.properties</include>
                    <include>important.properties</include>
                    <include>application-${activatedProperties}.properties</include>
                </includes>
            </testResource>

        </testResources>

该处能够先串联到流水线中，但不做门禁设置，等前期确定规范后，再关上门禁设置。

在骨干开发模式中，因为 EOS 动态代码扫描，配置代码合并门禁，确保代码编码标准。配置如下图所示例子：

代码评审通过 Coding 内置的评审规定实现，规定设定如下：

1. 评审分支为 master 分支，并在 push 时创立代码评审，并阻塞代码间接合入指标分支。

2. 评审人须要达到两人及以上通过后，能力触发随后的操作。

3. 不容许自评。

4. 不容许特定成员跳过自动化查看。

遇到此状况，个别是多版本同时开发的状况

此处跟业务强相干，须要具体问题具体分析。不过保障如下几个准则：

代码开发尽量保障高内聚低耦合，保障类的封闭性，同时能够用罕用设计模式，保障性能的业务代码解耦，有利于个性辨别。
个别情况，能够引入 ducc 配置核心，实现个性开关。

在行云流水线中，次要包含如下几个节点：

其中有一个配置上有一个小坑就是下载代码。为什么这么说呢？

因为咱们流水线的触发条件是跟 coding 上的代码评审配合应用，当骨干分支产生 merge 申请时，这个时候会触发流水线，但拉取的代码并不能间接填写骨干分支名称（如：master），起因是以后的 commit 快照并没有合并到 master 上，而是处于期待状态，只有当流水线通过后才会真正合并到骨干分支，这是如果下载代码里拉取的骨干分支就是不蕴含以后提交内容的快照，并不能满足咱们的诉求。

那么，咱们该如何配置呢？

好在 Webhook 中会带一些零碎内置全局参数，其中 globalParams.user.WEBHOOK\_ATTR\_COMMIT_ID，代表的就是以后提交申请所蕴含的 commit 快照，所以，咱们只须要配置这个全局参数即可，如图所示：

配合如上配置，咱们在触发设置中，只须要设置 MR created/Updated 事件即可。如下图所示：

于许多开发者而言，骨干开发是一项重大改革，您很可能会遇到一些妨碍。许多开发者根本无法想像如何采纳这种形式工作。一项好的做法是找到曾采纳这种形式工作的开发者，让他们领导其余开发者。让一些团队转为采纳骨干开发方式工作也很重要。实现此指标的一种办法是将大量具备骨干开发教训的开发者招集到一起，这样至多有一个团队遵循骨干开发做法。而后，如果您确信遵循此做法的团队施展预期的作用，则能够将其余团队转换为这种格调。

当然骨干开发也不是银弹，他也会有一些本人的弊病，比方在解决需要变更，或者同时多版本并行开发时，也须要建设多个长期分支反对，想做到纯正的骨干开发，也是过于理想化的后果。

关于敏捷开发:当代码农遇上码农揭秘主干开发的那些事儿-京东云技术团队

1. 概述

2. 整体架构

2.1 掂量骨干开发的成果

2.2 常见误区

2.3 改良骨干开发的 Tip

2.4 骨干开发流程阐明

3. 落地计划

3.1 单元测试

3.2 JaCoCo 代码覆盖率扫描

3.3 EOS 动态代码扫描

3.4 代码线上评审

3.5 个性开关

3.6 流水线配置

4. 总结