配置管理：使用版本控制
　　版本控制系统（源代码控制管理系统）是保存文件多个版本的一种机制。一般来说，包括Subversion、Git在内的开源工具可以满足绝大多数团队的需求。所有的版本控制系统都需要解决这样一个基础问题: 怎样让系统允许用户共享信息，而不会让他们因意外而互相干扰？
　　如果没有版本控制工具的协助，在开发中我们经常会遇到下面的一些问题：
　　一、 代码管理混乱。
　　二、 解决代码冲突困难。
　　三、 在代码整合期间引入深层BUG。
　　四、 无法对代码的拥有者进行权限控制。
　　五、 项目不同版本发布困难。
　　对所有内容都进行版本控制
　　版本控制不仅仅针对源代码，每个与所开发的软件相关的产物都应该被置于版本控制下，应当包括：源代码、测试代码、数据库脚本、构建和部署脚本、文档、web容器（tomcat的配置）所用的配置文件等。

　　保证频繁提交可靠代码到主干
　　频繁提交可靠、有质量保证的代码（编译通过是基本要求），能够轻松回滚到近可靠的版本，代码提交之后能够触发持续集成构建，及时得到反馈。
　　提交有意义的注释
　　强制要求团队成员使用有意义注释，甚至可以关联相关开发任务的原因是：当构建失败后，你知道是谁破坏了构建，找到可能的原因及定位缺陷位置。这些附加信息，可以缩短我们修复缺陷的时间。示例：团队使用了svn和redmine，注释是：
　　refs #任务id 提交说明
　　每个任务下可以看到多次提交记录：

图-2-2-相关修订版本


　　所有的代码文件编码格式统一使用UTF-8
　　上班前更新代码，下班前提交代码
　　前，团队其他成员可能提交了许多代码到svn，开始新的工作是，务必更新到新版本，及时发现问题（例如代码冲突）并解决；
　　当日事，当日毕，下班别把当天的编码成果仅保存在本地，应当提交到svn，次日团队更新可以获取到新版本，形成良性循环。
　　构建管理：使用Maven构建工具
　　Maven是基于项目对象模型(POM)，通过为Java项目的代码组织结构定义描述信息来管理项目的构建、报告和文档的软件项目管理工具。使用“惯例胜于配置”（convention over configuration）的原则，只要项目按照Maven制定的方式进行组织，它几乎能用一条命令执行所有的构建、部署、测试等任务，却不用写很多行的XML（消除Ant文件中大量的样板文件）。
　　或许，使用Ant来构建的团队要问，为什么用Maven呢？简单来说两点
　　1、对第三方依赖库进行统一的版本管理
　　说实话，ant处理依赖包之间的冲突问题，还是得靠人工解决，这个对于研发来说是消耗时间的，倒不如把节省的时间投入到业务中去。另外再也不用每个项目繁琐复制spring.jar了，通过maven自动管理Java库和项目间的依赖，打包的时候会将所有jar复制到WEB- INF/lib/目录下。
　　2、统一项目的目录结构。

　　保证所有项目的目录结构在任何服务器上都是一样的，每个目录起什么作用都很清楚明了。