工具选择

代码管理用什么工具好，有人喜欢git,不过git有个小小的缺点，就是对UI使用的大文件支持不太好，比如PSD文档，PNG文档等等。

作为windows下的佛系程序员，我还是保守一点，团队使用SVN。

如果有两个工具都差不多，选择最适合你的那个，或者说，选择团队里面会的人最多的那个。

为什么，节省时间成本。

这并不是说不能使用git和github, 该用你还是用。

只是在团队中我们首选了svn, 方便大文件的存储。

工具选择哪个，主要还是看整个团队。

搭建环境

服务器端我们使用visualsvn server.

开源免费，然后权限控制挺棒的。

有钱的话可以购买一台腾讯的windows云服务器，放在外网部署。

如果担心代码安全问题，可以购买一台本地机器，然后把IP映射出去。

人多的团队可能担心SVN的拉代码慢的问题，对于以前做手机的MTK团队的确需要担心一下，动不动1-2G的代码。

对JAVA web团队，这个不用太担心，除非你的网络非常差，那得考虑让老板加下带宽了。

如果老板不愿意，你可以算一下拉代码等待的时间X每个人的小时工资。

绝对大于带宽的钱。

作为互联网开发团队，有两样钱不能省，一个是开发机的配置，一个就是网络带宽。

太慢不光影响效率，还影响开发心情。

文件夹规划

在我们团队中的经验是拆分为3个大的仓库，一个代码，一个文档，一个发布。
也就是code,doc

code我们需要建立分支，以便在发布和开发子功能的时候拉取分支。

其它的比如人力资源行政(hr)，运维(devops)也拆分出来成为独立的仓库。

代码(code):

下面用来存放各个项目的代码，按项目名称进行划分。
比如你有一个oa项目，有一个user项目(用户中心).
我们可以这样子进行存放。
oa
user

文件夹中看项目拆分程度，进行子项目的命名。

1.user是一个整体项目，没有做前后端分离,只有一个web项目。
我们可以写成
user-web。
2.oa是一个前后端分离的项目，分为PC，手机两个前端项目，一个api项目。
那我们可以写成
oa-api
oa-web-pc
oa-web-mb

文档(doc):

文档也是按照项目进行划分。
之所以文档单独分离，主要还是权限控制的问题，代码一般不能被产品和UI拿到的，但是文档是大家都要看的，分离以后权限控制相对简单一点

。
还是假设有两个项目oa和user.
oa下面有
task(各种需求和任务，为什么用task,这个单词好记，简单)
ui(原型和ui设计就放这个里面了)
test(各种测试用例和测试报告就放这里面了)
lab(项目的衍生品做各种小实验的小工程文档，都可以丢这个里面)

user下面呢，同样是这些文件夹

hr和devops

hr和devops就不用太介绍了，大家自己想怎么放就怎么放

devops里面有一个要介绍的
需要有一个项目规划表
比如oa-api 用什么端口，放哪台服务器

版本发布

RC版本发布

RC版本发布就是从主干上拉取测试过的代码，创建一个分支，进行发布。

拿oa为例，我们可以创建分支 rc-oa-1.00.0106 表示是1.00版本，2018年1月6号发布的。

正式版本发布

正式版本就不用特别拉取分支了，因为我们RC上线，测试通过了，就是直接发布到正式了。

个别公司还有uat环境，但是对于小公司单应用快速迭代，RC已经够用了。

就算是uat环境，也是直接拉取rc, 只是配置的启动参数不一样。

子功能添加

一般小的模块，可以直接在主干上进行开发，这没有太大的问题。

如果有影响很大的模块，建议创建一个分支 task-xxxx-oa-1.00.0106 这个样子。

在分支上开发完成以后，再通过打patch包合并到我们的主干上来。

迭代周期

一般每一周，每个人保持2-3个功能的开发上线，是比较合理的。

大的功能点耗费的时间长一点，这个时候可以考虑创建分支。

我们一般周三下午就准备RC上线，周四RC测试一天，周四下午发正式服务器。

周五规划好下周功能，并讨论需求。

自动化发布

每天下午四点会自动化发布一个版本给测试进行回归.
保证出现重大问题的及时回退。