背景

从软件开发到正式上线一般经过开发、测试、上线三个大流程,但是每个流程都应该有一定的流程规范机制。没有规范,很容易导致线上事故。此外,也易导致维护难,代码可读性差等问题。针对研发方面主要可能存在以下几个方面的规范,注意规范不是不变的下面的部分规范是个人目前认为比较合理的一种实践方案,欢迎提出建议,探寻更加合理的方案。

开发

1.分支管理

现如今开发基本上是通过git等软件进行代码库管理和协作开发。而对于这种协作开发的模式,很重要的一个内容就是分支管理。分支管理如果不做好可能会出现需求上线日期冲突,通过规范的分支管理措施能有效解决这些问题。一种简单的分支管理方法如下:

  • 分支命名规范:需求类的分支和bug修复类的分支需要进行区分,比如需求分支命名添加前缀feature,bug修复分支命名前缀可用fix。QA测试分支可直接使用test,线上发布版本前缀可使用release加上该版本第一次发布日期。

  • 合并规范:合并涉及的流程比较长,具体如下:

    • 需求分支的源分支为master,bug修复分支的源分支为bug存在的release分支。

    • 当需求分支和bug修复分支达到可交付QA进行测试验证的情况下,将指定分支合并到QA测试的分支比如test,这是因为QA可能同时测多个需求,且要对场景进行回归测试。

    • 当QA测试完毕后,从master或者最近上线的release分支拉出release分支作为发布分支,一同上线的需求可以一起合并到该分支然后删除源分支,bug修复分支亦如此。新发布的release分支需要添加该版本第一次发布日期作为版本号即从release分支拉出分支并加上日期版本号,用以记录发布的代码库,避免线上多个版本部署问题出现后,能够通过运行的版本找到代码出现的问题。

    • 当release线上发布成功并验证成功后,将其合并到master分支,作为后续需求的源分支,若出现问题则release分支为bug修复分支的源分支,注意每次分支合并需要解决版本冲突。

  • 发布规范:线上发布的版本都是release分支并且记录了第一次发布的版本号,源分支为线上运行的最新分支,一般为master,当需求密集时可能是最近的release分支。若运维工具无回滚功能可根据对应发布日期版本进行编译回滚,从而实现简单的回滚功能。

具体分支管理如图所示:

开发流程规范机制_代码风格

 

 

2.代码风格及规范

良好的代码规范及限制可以有效的将整个团队的代码风格统一从而提高代码的可维护性。一般来讲,好的代码具有风格一致、注释清晰、命名正确、圈复杂度低等特点。对于风格问题通过IDE比如Idea、Eclipse的风格配置文件以及格式化可以有效将代码风格进行统一,此外通过checkStyle以及git的hook机制可以有效的限制不符合代码风格的提交。而针对一些常见的bug和复杂度通过sonar、pmd、findbugs等代码检查工具也可以进行代码审查。代码风格及规范的流程机制的大概分为以下几个过程

  • 代码风格一致性检查。主要包括代码缩进、无用包导入、换行风格等等。此部分可由两种实现一种是通过IDE的git提交插件时对代码进行格式化,第二种则主要是通过Idea的Save Actions对代码自动保存时将代码进行格式化。当然除了本地的格式化我们也应当通过一些强制校验手段比如checkStyle,checkStyle能够通过配置文件的方式来约束代码风格,通过maven plugin方式集成可以在指定的maven生命周期对违约代码进行提示,亦可通过git的hook机制避免违约代码提交。具体

  • 代码单测覆盖率检查。好的代码应针对核心逻辑具有完善的单测覆盖,单测覆盖主要关注的指标除了行覆盖率外还应重点关注分支覆盖率,避免多case情况下,部分case没有被覆盖到。此部分可以通过jacoco来对代码覆盖率的情况生成报告,并约束覆盖率达标指标。也可通过maven plugin的方式进行集成。

  • 代码bug检测。针对可能出现的bug比如equals空指针等问题,可以通过sonar等三方平台进行检测,也可以通过findbugs、pmd等maven插件进行检测。

  • Code Review。以上都是属于自动流程机制,通过Jenkins等平台进行流水线编排能够很好的实现以上功能,除此之外我们不能少的是Code Review机制。在以上自动化流程通过后,codeReview将着重于命名、代码可读性、SQL等无法通过自动化机制实现的方面进行Review,减少CR带来的工作量。

上线

1.上线规范

在功能需求开发完成后,我们需要进行上线。对于上线一般有以下几点。

  • 针对上线内容的变更通过VMS或者ChangeLog的方式记录本次上线的内容。具体包含配置文件变更、代码内容变更,可以通过git diff等对比软件生成差异报告。针对变更的内容无论是ChangeLog还是做VMS都要做到Double Check,当然一般情况下通过VMS可能会更加方便,即内容更改以及审批都可以迅速体现,这也是基础设施完善的一大优势。

  • 上线审批,针对VMS或ChangeLog已经内部进行Double Check的上线进行审批,即更高权限的leader进行层级审批,避免上线随意的情况。

2.质量规范

在线上出现问题后,在出现的问题解决后,需要对问题进行一个总结报告。包含问题产生的原因以及处理方法进行总结记录。