软件研发软件基础设施的建设

前言

决定团队效率的不仅仅是成员的技术水平，团队的组织形式，还有一个关键因素就是软件研发的基础设施因素，团队再牛技术再好没有合适的基础设施往往都是事倍功半。本文将介绍经过两年的积累我们搭建的一套零成本的软件研发基础设施，特别适合于无法直接连接互联网的团队。毕竟互联网上已经有相当成熟的软件研发基础设施，而且对于小团队来说还基本是免费的，具体的请出门百度。
顺便提一句由于技术栈不一样可能需要的基础设施略有差别，请根据自身情况自行裁剪。

推荐基础设施

我们目前已经构建了如下图所示的研发基础设施，基本满足我们团队的需求，此外我们也建立了资料共享的wiki，docker的镜像仓库以及适应特殊网络的持续部署系统。

版本管理系统

说到基础设施，第一个要介绍的就是版本管理系统。若一个团队没有版本管理系统，那只能说明这个团队要么是一个人要么是属于石器时代。就算只有一个人，其实也需要版本管理系统来支持对比，回滚，分支。
目前最流行的版本管理系统非Git莫属，强烈推荐使用Git来作为新团队的版本管理系统。但由于历史原因我们采用的是SVN，对于身处于局域网中的我们影响到还不是很大。
这里特别提一下，使用SVN的话也能有一些好处那就是能尽量保证主线的一致性，因为其支线和合并功能并不是特别好使。
我们使用的VisualSVN作为服务端，至于客户端就看个人喜好了，可以使用TortoiseSVN或IDE内嵌的，问题都大。

Bug管理系统

Bug管理系统也是支持研发的一大利器，哪个团队能开发出没有Bug的产品，与其说是没有不如说是不愿意看到，同时Bug管理系统记录缺陷及时进行修复。
这里需要说明的是能修复的Bug就直接修复，不能修复的在录入，不要让Bug管理系统成为Bug的最终归属地。
我们搭建的是BugFree，简单实用。

持续集成系统

持续集成系统是现代软件研发团队的标志，高效的团队离不开持续集成系统的支持。它能够自动构建，自动测试，自动部署产品，不断地确认产品的质量，及时发现问题和缺陷。
我们采用的Jenkins作为我们的持续集成系统，免费开源功能强大，插件众多。
持续集成系统需要版本管理系统的支持，还可以与后面的质量自动检查系统配合使用。
需要注意的是Jenkins构建过程是十分消耗内存和CPU的应当为其找到合适的硬件，同时注意配置系统来及时清理构建产物，我们最开始的jenkins莫名的挂掉，后来发现可用空间为0，好几百G的构建文件。。。
同时Jenkins支持集群，要是团队比较大，产品庞大可以考虑使用集群的方式来搭建持续集成系统。

代码自动质量评价系统

产品质量的另一大利器是代码自动质量评价系统，这个系统可以自动评价项目中的源码的质量情况，找到可能的缺陷和问题，以及不符合编码规范的地方。
我们最开始使用功能的checkStyle等IDE插件来实现这个工作，后来发现了sonar系统，效果杠杠的项目的编码质量上了一个大台阶，技术债务大幅下降。
需要注意的是清理技术要适度，过分的追求0债务往往是不合适的。

依赖仓库

我们采用的maven进行项目构建，同时我们又是身处局域网中，依赖下载我们的一个大问题，经过调研确定可以搭建nexus作为局域网仓库。
需要注意的是，局域网内开发，在开始时会经常遇到局域网仓库没有依赖的现象，我们的做法是在外网通过项目的pom下载依赖后，再将外网的本地仓库同步到局域仓库。

代码评审系统

为了进一步提高产品的质量，我们每天进行代码审查，开始我们通过IDE来进行代码review有时候发现不是很方便，后来我们搭建了Upsources来辅助进行代码审查，效果还不错。
一个意外收获是由于有统计信息的存在，大家提交代码的频率高了很多，同时SVN的严重冲突现象基本消失了。
需要注意的是Upsources是商业产品，但小于10人的团队可以免费使用，怎么用大家都懂了吧。。。。

其他基础设施

除了上文的这些系统我们还搭建了doukuwiki来实现资料的共享、docker的镜像仓库来进行镜像的管理、finesse作为我们的验收测试系统。

总结

需要注意的是，随着技术的发展，基础设施始终处于一个动态的演化过程，基础设施是为了提高团队的工作效率，产品的质量。不能忽视团队和项目的实际情况，过于追求新奇的基础设施，对于产品或团队造成负面影响，这就是舍本逐末。
对团队来说最重要的基础设施就是版本管理系统+持续集成系统+Bug管理系统，有了这些系统可以更高效的支撑团队的研发。
磨刀不误砍柴工，愿大家都有一个好的平台。