搭建新配置管理环境可行性分析及实施方案

说明：我09年写的文档，时光飞逝避免的，哈哈，为了避免可以避免的麻烦，有裁剪 1．项目目标简述

在专业服务器上搭建基于Apache+SSPI+Windows域认证的SVN服务器，供全公司所有部门使用。

2.    项目提出的背景及必要性  

通过对当前配置管理环境的分析（详细见《当前配置管理环境分析报告.doc》），我们得知主要存在下面三个问题：

 

1、  文件存放不统一，分别存放在两个VSS服务器，一个SVN服务器上，不便于管理

 

2、  服务器实际上是PC，性能不高

 

3、  VSS是入门级的配置管理工具，很多其他配置管理工具(如SVN)可以实现的功能都无法实现；安全产品部基于Svnserver搭建的SVN服务器，管理员管理起来较繁琐，且存在安全隐患。

 

4、  没有基本的备份机制，数据的安全保障性低，一旦发生硬盘损害或系统崩溃，会造成无法挽回的损失。

 

     随着公司业务的发展，项目会增加，人员也会增加；相应的，对存放公司数据的服务器的要求也在提高的。

因此，目前把PC当做服务器的做法只能是临时性的，购买专业服务器来取代目前的PC服务器是必需的

  

 

3. 为什么是“Apache+SSPI+Windows域认证的SVN服务器” 3.1 用SVN取代VSS的理由

 为什么要用SVN取代正在使用的VSS呢？从下表中的比较可知，SVN比VSS好太多。

项目	VSS	SVN	备注
原子性提交 Atomic commit	不支持	支持	SVN无论批量提交包含多少文件修改，只有当全部文件修改都成功入库，该提交才变得有效，才对其他用户可见；否则，无论任何原因造成中断，SVN都会自动“回滚”(rollback)操作。换一个说法，SVN保证所有的修改要么全部入库生效，要么个也不入库，即对版本库不作任何修改。
重命名	不支持	支持	SVN可直接对文件、目录重命名，而且历史记录不会丢，这比较重要，也是比较常用的功能。而VSS改名，实际就是新建了一个文件，删除原有文件，历史记录自然不会有。
最小提交块	文件 smallest commit block is a file	行 a line is the smallest commit block	最小提交块是文件，这样通过看历史很难找出某次checkin到底checkin了什么东西
安全性	基于文件系统共享实现对服务器的访问，需要共享存储目录	SVN服务器有自己专用的数据库，文件存储不采用“共享目录”方式，所以不受限于局域网。客户端可以是不同的平台，都是通过tcp/ip和特定端口来访问SVN服务器，有不同安全等级的访问协议可供选择	每次使用VSS的时候必须登录一次服务器，非常麻烦
离线开发操作	需要执行几个步骤也可以安全入库，但麻烦	不需要另外操作
模式	主要采用独占模式（checkout,modify,checkin）也可以使用（multi_checkout,modify,checkin,merge）模式。	使用update,modify,commit方式。每个人可以修改自己可以访问的任意代码，代码不会被一个人单独占用。可以多人修改同一份代码，并且每个人的修改结果都不会丢失。如果提交时SVN没有发现冲突，则代码可以直接入库。否则SVN会让你手工合并
Internet网络和远程协作	VSS8.0支持	更适合基于互联网协作开发，速度快
支持平台	Windows	Windows,Linux,Unix works on windows, linux, unix, and even macs and also java which makes it ultimaly portable
客户端	VSS client	Windows下：TortoiseSVN，Linux下：RapidSVN
自动合并	不提供	提供，如果不能自动合并，可以手工修改冲突
版本分支	有 但在操作中VSS首先要做项目共享,引入要分支的项目或文件然后做分支操作	有，建立分支很方便
异地开发	支持	支持
操作的便利性	安装、配置、使用均简单，很容易上手使用	安装、配置较复杂，但使用简单，只需对配置管理做简单培训即可
版本管理	手工 通过label来自定义一个版本号，可以解决部分项目管理的问题，但这是远远不够的，当一个产品根据用户需求产生一系列不同的项目版本时使用VSS将难以管理	提交时记录版本号，自动分支管理	VSS版本发行时只能手工挑选对应的版本文件进行发布。
与外围工具集成		各种各样的外围工具（主要是服务器端），满足多种需要。如果有需要也可以自己写插件或管理脚本，开放的架构，允许我们这样做。
费用	免费	免费	都是免费的，但SVN是开源的，且在不断优化之中。

 

 

3.2 选择Apache+SSPI+Windows域认证的理由

SVN服务器有两种，一种是基于Apache的，配置比较复杂，也比较灵活；另一种是基于svnserver的，配置很简单，目前安全产品部使用的SVN（后面简称“现svn”）就是基于svnserver的。那么，我们为什么要选择配置复杂的呢？请看下面的比较：

项目	Svnserver	Apache+SSPI+Windows域认证	备注
用户名	用户名由服务器管理员在passwd（默认）中创建	用户名即为用户登录到域ZTEIC的用户名，与开机用户名一致，不需要服务器管理员创建。	1、  现svn的用户名为中文姓名的拼音，这样做的问题就是，如果有重名的同事怎么办？使用于认证就不存在这样的问题 2、  现在每次设置权限前都必须先检查这名同事是否有svn帐号，没有的话再创建，浪费时间，且可能会影响工作情绪。
密码	1、密码是明文的，安全性低；2、需要管理员手工修改，很多同事一直使用默认密码，密码形同虚设。3、修改后的密码也大多都复杂度偏低	1、密码即为开机密码，不用管理员设置，用户也不用特别设置密码 2、通过在域服务器端的设置，可以要求用户密码的复杂度，如要求必须有大小写、下滑线、数字等 3、在域服务器端还可以通过设置多长时间内必须修改开机密码，这样可以进一步确保密码的安全	配置库中存放的是公司宝贵的信息资产，所以安全性是对版本库的基本要求，而密码作为访问资源的“钥匙”，重要性不言。客观地说，大多数同事对信息安全的认识不是很足，把域密码和SVN密码绑定，可以大大提高配置库访问的安全性
Wed浏览	不支持	支持。可以通过IE或其他常用的浏览其访问配置库。你可以将浏览器指向版本库的URL，无需安装Subversion客户端就可以浏览内容，这样可以扩大访问数据的用户圈。	支持Web浏览很重要，因为： 1、  界面友好，绝大部分人更习惯这样的界面 2、  可以在不安装SVN客户端的情况下查看、打开配置库中的文件，这在评审时非常有用，特别对只检查文件，不写文件的同事。
安全	Svnser是一个轻型的服务器，安全性相对较弱	因为Apache非常稳定和安全，版本库可以自动获得同样的安全性，包括SSL加密。
加密	SSH通道	SSL	SSL 是Secure socket Layer英文缩写,它为TCP/IP连接提供数据加密、服务器认证、消息完整性以及可选的客户机认证,主要用于提高应用程序之间数据的安全性,对传送的数据进行加密和隐藏,确保数据在传送中不被改变,即确保数据的完整性。
初始化设置	比较简单	比较复杂	采用Apache的配置比较复杂，但同时也比较灵活，可以实现更多的附加功能。而且，这只对管理员有影响，用户不用关心。

 

4. 对网络及服务器的基本需求

基于对现状（详细见《当前配置管理环境分析报告.doc》）、未来的发展趋势、以及新服务器所需软件的判断，我们对网络及服务器性的基本需求如下：

0、              以下需求未将IC研发的工作站考虑在内

 

1、              关于域：所有需要访问SVN服务器的用户都必须加入到域ZTEIC，即我们在开机启动时登陆的域。

理由：目前大部分同事都在ZTEIC中，所以，若没有特别的需要，建议把其他同事也加入到ZTEIC中，我们在配置服务器时需要用到

 

2、              关于内存，建议至少在4G以上，且可扩展

理由：SVN操作交互比较多，而且涉及到web操作，对系统的响应速度要求会比较高，所以对内存的要求偏高（相对于普通的文件服务器）。目前在用的SVN服务器(10.70.59.245)的响应速度是无法令人接受的，往往服务器端操作已完成，但在客户端的状态还未表现出来。从操作完成到状态显示超过一秒钟，我们将认为是不可接受的。

 

    3、    关于磁盘：目前的数据量是100G，由于没有增量方面的数据，无法作出有效需求，请IT根据经验制定需求

   

3、              关于网络带宽：随着SVN用户的逐步增多，我们必须考虑到并发操作的情况。通常要求我们的网络带宽必须满足总用户数的四分之一并发操作时情况。请IT判断是否需要考虑增加带宽？

 

4、              关于备份和恢复：实现每日增量备份，且最长在半小时内完成数据的恢复

理由：配置库中存放的都是公司的重要信息资产，若由于某些原因，出现数据丢失、毁坏，甚至出现服务器系统、硬盘崩溃的情况，对公司的影响将是致命的。所以对数据的备份就显得格外重要。