小公司基于svn进行源码版本管理存在的问题一点浅谈

_本文为原创文章，欢迎转载，转载时需附上本文的原文链接_

说在前面

业界除bat类顶级大公司和开源项目外，很多小公司特别是外包型公司，都存在相同系统多份代码、代码版本混乱、升级后出现大量兼容性问题、直接将线上系统逆向工程修改、人员离职后找不到代码、服务器上代码不是最新代码等问题。
自己之前所在的两个还不算太小的公司其实也存在上述的问题，本文记录一下个人对此问题的一点看法。

基本思路

这个问题我记得之前和一些同仁一起讨论过，结论和业界主流的产品级代码版本管理办法基本一致，即原则上源码管理大家其实都在按以下思路操作，这也是svn的标准代码管理方式。之所以叫原则上，是因为在实际的管理过程中，完全允许根据实际的情况采用变通的处理方式，达到源码管理的目的即可。

1. 始终以trunk为主线，除新增功能外，需要升级的功能或者项目交付定制化功能只能在branch上进行开发。
2. 对于branch上的功能能够合并到主线的，应该在branch有阶段性成果后merge到trunk上。
3. 合并后变更trunk版本号，自动打包并测试验证trunk版本的正确性。
4. 产品的发版始终在trunk进行，发版后，在trunk做tag标记。

根本原因

之所以很多小公司在源码管理上存在上面罗列的一大堆问题，个人认为不是一个简单规范/制度就可以解决，最根本的原因在于：

1. 除公司里面如基础开发平台和一些与业务基本无关的系统外，很多公司开发的业务系统，大多都是定制化的需求，还谈不上产品化。这样开发人员直接copy一个类似系统后直接修改，同名系统代码存在多份不难理解。
2. 技术负责人没有将可复用部分进行产品化的意识，或许是面临项目交付时间和成本的压力，无心做产品化的事情；亦或是能力目前还达不到。因为产品化带来的直接后果是设计复杂度、编码复杂度、时间和成本的上升。
3. 技术负责人和开发者代码管理意识淡薄，有相当一部分技术人员自己都搞不懂正确的源码管理应该如何进行，搞不懂svn的版本、chunk\branch\tag到底有何用？当然这个可以通过培训/指导解决。
4. 很多小公司老板虽然口头上都说想做产品，但其实不太愿意在研发上直接投入，走交付性研发的路，研发项目采用与交付项目相同的管理流程。导致交付为王的思想占了上峰，只要项目经理和测试说交付功能实现了就完事，根本性缺失后续的代码合并、主线重新测试验证这一步工艺。

简单办法

就上面列出的问题，个人认为对于小公司或外包型公司，做到以下简单处理就好，切勿草木皆兵：

• 定制化业务类系统直接不考虑产品化的事情，只需要能找到这个系统的源代码即可。
• 所有测试和发布出去的系统，坚持只能由服务器自动打包。而且发布的最小粒度为系统/组件，不允许有些公司那种直接替换系统里面的文件方式。解决源代码不check-in或者服务器上不是最新代码的问题。
• 对于明确为产品研发的系统，明确技术/部门负责人负责制，测试部在测试前打包负有检查代码版本的稽查义务。

_注：欢迎加私友一起探讨学习，我的联系方式可在脑链网上找到_