Github中持续集成对生产效率和质量的影响

Github中持续集成对生产效率和质量的影响

QualityandProductivityOutcomesRelatingtoContinuousIntegrationinGitHub

(FSE15)BackgroundResearchQuestionsRQ1.ProductivityHowistheproductivityofteamsaffected

byCI?RQ2.QualityWhatistheeffectofCIonsoftwarequality?MethodsDataCollectionSelectingProjectsCollectingDataonSourceandTestFilesCollectingProductivityDataCollectingQualityDataAnalysisSelectingProjects数据源：GHTorrent（截止10/11/2014）基本要求：时间长，在中间某个时间点开始使用CI；PR数大于200；使用PRBased模式语言：主流语言（Ruby,Python,JavaScript,PHP,Java,Scala,CandC++）初步筛选得到1884个CI种类：Jenkins和Travis-CI，前者的构建历史不可跟踪。选择使用Travis-CI的项目筛选得到918个保证CI被合理使用：使用CI后收到的PR占25%-75%，而且CI过程包含测试筛选得到246个SelectingProjectsCollectingDataonSourceandTestFiles从项目创建开始，收集存储库3个月的快照，作为每个PR前存储库状态的近似。使用CLOC，基于文件的扩展名获得了文件数量、可执行行数数据。CollectingProductivityDataProductivityData：每个月合入PR的数量一共24个月，未使用CI和使用CI各占12个月CollectingProductivityDataCollectingQuality

DataQualityData：每个月的bug数量两种bug数量分析方法：检测commit关键字：不精确通过github内部的issue功能获取：tag或关键词分析启发式方法选择issue超过100个的42个项目issue进行分类，对于有bug标签的issue，人工提取到关键词列表（defect,error,bug,issue,mistake,incorrect,fault,andflaw）然后将这些关键词对所有issue进行分类CollectingQualityDataAnalysis多重回归建模：描述一组解释因变量（是否使用CI）和响应（单位时间bug数量）之间的关系。面临的挑战：①数据过于分散，方差远大于平均值；②0值过多使用了负二项式（NB）回归处理第一个问题使用零膨胀（zero-inflated）模型处理第二个挑战避免多重共线性：记录变换预测变量来稳定方差以改进模型，确保VIF（varianceinflationfactor，方差因子）在3-5之间去除异常点：异常点可能会影响回归方程的斜率，影响模型适配性，超过k(1+2/n)median(x)+θ的点为异常点，θ是位移指数，k保证不超过3%的点被标记为异常点。Results&Discussion建模方法（ZINB,Zero-InflatedNegativeBinomial）PR有两种状态，接受和拒绝分别建模社会关系会对判定有影响，因此内部开发者和外部贡献者分别建模RQ1.Productivity团队核心成员每月PR合入/拒绝变化统计外部贡献者每月PR合入/拒绝变化统计Count：每个变量的负二项式回归系数及标准差

Zero-infl：零膨胀系数及标准差

星号：每种数据的统计学意义RQ1.Productivity因素内部接受内部拒绝外部接受外部拒绝团队规模增大↑↑-↑项目时间增长↓↑↓↓Star增加↓↑--Fork增多↓↓↑↑代码量增大↑-↑↑测试覆盖增大↑↑↓↑开始使用CI↑↓↑↓使用CI后，核心成员合并PR的效率会提升，也使得外部贡献者PR的拒绝率降低。RQ2.QualityCount：每个变量的负二项式回归系数及标准差

Zero-infl：零膨胀系数及标准差

星号：每种数据的统计学意义RQ2.Quality因素内部人员发现bug数外部人员发现bug数非bugissue增加↑↑项目时间增长↓-Star增加