2.1 基础文档
无规矩不成方圆，如果按照CMMI最低标准流程执行的话，我们在软件开发过程中就会产生数不清的文档，而在敏捷软件开发中，更强调则是程序员团队与需求专家（产品经理）之间的紧密协作及面对面的沟通（认为比书面的文档更有效）。我认为，在正式写代码之前，有些文档是必须要准备的，有些东西也必须要标准化、流程化，这样才能减少错误的发生，或者是在发生问题时，可以更快、更有效地解决问题！
在上一章介绍了每个技术小组需要使用的内部文档，而这些内部文档需要在开发前就约定好，并在实际开发过程中得到优化，下面将简单介绍这些文档所包含的内容。
2.1.1 前端组
《html&css前端开发规范》：包括了Html标签的书写规范和CSS命名规范，共同约定了一些技巧和使用注意事项，同时也规定了各种注释规范（文件、块、行）。
《javascript前端开发规范》：js是前端使用的主要网页脚本语言，同其它编程语言一样，需要大家统一编码习惯，比如命名规则、变量定义原则、代码缩进格式、注释等。
2.1.2 开发组
《编码规范（C#版）》：C#是开发组的主要编程语言，但由于团队是刚组建起来的，所以每个人的编码风格都不一样。此文档主要来约束大家的命名规范、注释规范、特殊技术使用规范等，但并不限制某个功能必须采用某种技术或算法来实现。我在编写文档时也参考了网上的很多资料，大多都不统一，也不太规范，最终参考了《.NET 设计规范--.NET约定、惯用法与模式》来编写此文档。
2.1.3 数据库组
《数据库管理规范》：主要包括数据库对象（数据库、表、字段、视图、索引、触发器、函数及存储过程）的命名规范，还包括脚本格式的统一（存储过程、注释）和数据库安全管理的注意事项。
2.1.4 测试组
《BUG流程管理》：主要介绍BUG在内部协作过程中，从产生到解决的流程，也规定了BUG级别和各种BUG状态的处理方法。
《BUG管理工具说明》：介绍JIRA的使用方法和注意事项。
2.2 协作环境
2.2.1 版本控制
在软件开发领域，版本控制系统已经成为每个技术团队首要搭建的环境。以下引自维基百科，版本控制（Revision control）是维护工程蓝图的标准作法，能追踪工程蓝图从诞生一直到定案的过程。此外，版本控制也是一种软件工程技巧，借此能在软件开发的过程中，确保由不同人所编辑的同一程式档案都得到同步。”
在我们团队中，存在两种版本控制，一种是文档版本控制，它的具体格式主要体现在文件命名上，比如：《***网站（内容区）开发规格说明书_V1.0.9_2011-11-03》是由“文档名称+版本号+更新时间”组成的。另一种则是源代码版本控制，它是用于存放内部产品的整个生命周期所需要的文件，我们内部的版本控制系统采用的是”Subversion”。
版本控制是一个很大的话题，在部署版本控制系统前，我们需要分析产品和内部人员的架构，并根据需求来建立版本库和划分权限，这样即有利于后期的扩展，也方便大家协作开发。另外，还要考虑版本控制系统所在服务器的备份。现在，来分享我们一个产品的目录存储结构，我会附加说明每个文件夹的作用。产品目录结构如图：
CMS：内容区产品
---V1.0.0:以大版本号划分文件夹，只有在重大改版或架构变化时，则升级为“V2.0.0”。
------BackgroundDev：开发组文件夹
---------1_Doc：项目开发组文档，包括开发规范、功能说明、架构设计、进度控制等。
---------2_SourceCode：项目源代码目录
---------3_Test：包含一些功能性临时测试项目
---------4_Release：产品发布文件夹
------------Alpha：内部测试或内部使用版本
------------Beta：线上测试版本
------------Release：最终V1.0.0发布版本
---------5_Update: Release版本的升级包
---------6_Other：第三方插件、学习资料和一些快速开发代码生成模板。
------DataBaseDes：数据库组文件夹
------FrontEndDev：前端组文件夹
------ProductDes：产品组文件夹
------Release：所有小组的Release备份
------Update：所有小组的Update备份
注：这里只说明开发组文件夹”的目录结果，其它小组则根据需求设计文件目录。
以下是搭建环境所用到的工具：
服务器端
VisualSVN Server：之所以使用它，是因为它集成了”Subversion”，并支持图形化配置界面，方便SVN版本库的建立和用户权限的分配，同时支持Windows Server 2008，另外也是免费的。
客户端
TortoiseSVN：集成操作系统的资源管理器，方便更新和提交，官方网站提供中文包下载。
Ankhsvn：将Subversion的操作集成在Visual Studio的SVN Client软件，支持Visual Studio 2010。
Dreamweaver CS5：集成了SVN客户端工具，具体使用方法可以Google。
2.2.2 环境模拟
在正式开发之前，我们会根据产品的架构设计（物理架构），在团队内部搭建一个产品发布后（IDC）的同样的运行环境，以方便开发人员调试程序。针对内容区 的产品，我们一共搭建了三套环境，“分别是开发环境”、”测试环境”、“内部使用环境”，下面介绍每个环境的用途。
开发环境
主要方便开发人员自己测试程序，在发布给测试组时，首先要部署到内部开发环境查看是否能正常运行，同时也可以和测试环境部署的程序进行对比，来确认某个 问题是环境引起的还是程序本身的问题。内容区是由多个子产品和多个开发人员组成的，各个产品会相互调用，这样就方便大家查看对方程序的运行效果。
测试环境
当产品发布新版本时，测试组会从版本控制系统中提取最新版本，然后部署到测试环境进行测试。注意，所有环境的数据库并不是共享的，这样大家每次都不需要初始数据，因为有些BUG是由数据引起的。
内部使用环境
这个环境其实是没必要部署的，但是内容区项目比较特殊，根据内部进度，要求网站在上线前必须具备运营所需要的数据。由于我们在开发进度上，要求内容区的后台管理系统的部分功能，在开发阶段就要提供内部使用版本，并提供给内容部”使用，所以就临时部署了这个环境，其实这个环境还是有用的，因为它是用真正 数据来运行的，可以覆盖测试环境测试不到的问题。此环境在网站上线后就撤销了，测试部门直接从线上导出数据，并部署到测试环境来测试。
注：上述几个环境并不是和线上机器同样配置的环境，而是用虚拟化模拟出来的，但是针对一些特殊测试场景会做特殊处理，比如压力测试。
2.2.3 虚拟化
关于虚拟化在互联网产品开发中的重要性，请大家看一篇文章的介绍，里面的内容也都是我想表达的，文章标题为”虚拟化——互联网时代的产品开发加速器”。我们团队中使用微软的“Hyper-V”来实现虚拟化，关于“Hyper-V”的使用大家可以参考MSDN，其实和装虚拟机一样，只是在分配是要考虑到硬盘空间和内存大小，最大化的使用主服务器，微软也提供了“Hyper-V”的客户端管理工具，可在官方网上下载。
上一节所提到的“环境模拟”都是用虚拟化来实现的，除了产品测试所需要的机器外，我们还给每一位开发人员分配一台虚拟测试机，以方便程序开发和测试。在互联网产品开发中，浏览器兼容性是前端开发很头疼的问题，为了能模拟客户最终浏览的效果，我们虚拟出了各种操作系统的默认浏览器版本，来方便开发和测试人员测试网站。
注：“Hyper-V”对有些Linux版本的系统兼容性不是太好，内部有关Linux系统的虚拟化采用“VMware”来实现。
2.2.4 Bug管理系统
我们的技术团队采用JIRA来做“Bug跟踪”，JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。目前我们只使用它来管理内部产品 BUG，另外在JIRA平台上还安装了“Subversion JIRA plugin”插件，可以和内部源码管理工具结合起来，方便查看BUG所对应的源代码文件。
合理的使用JIRA可以为项目管理和产品版本的发布带来很多好处，在开始使用JIRA平台前，测试负责人需要给开发人员进行培训，使其并养成一些良好的习惯，在这里分享一些从测试组学来的经验。
- 分析公司产品的规划，合理在JIRA建立项目分组，比如内容区项目“可以分开建立为内容区前台”、“内容区后台”、“内容区前端”三个项目组。
- 把各项目细化为功能系统，每个功能系统对应某个开发人员，这样更方便管理Bug。
- 测试人员在提交Bug前要理解当前Bug属于哪个项目和哪个功能系统，并正确选择当前Bug所属的项目版本号。
- 开发人员在解决Bug时，一定要填写备注并正确选择Bug处理状态。
- 开发人员在提交源代码到版本控制系统时，除了填写当前源代码备注外，还需要加上Bug编号，这样就可以在JIRA中查看Bug对应的源代码文件了。
- 在填写Bug内容时也有很多学问，这个测试人员更有经验，比如加上Bug所在页面的链接、配上图片、Bug级别的选择等。（内部文档有相关规定）
有关JIRA的相关资料请参考以下链接：
- 官方网站：http://www.atlassian.com/software/jira/overview
- 中文演示：http://www.jira.cn
- Subversion JIRA plugin：https://studio.plugins.atlassian.com/wiki/display/SVN/Subversion+JIRA+plugin
- 论坛讨论：http://www.fangwai.net/bbs/
2.2.5 内部通信
企业邮箱
目前，通过腾讯企业邮箱来实现内外的邮件沟通，客户端可以使用Foxmail、OutLook、网易闪电邮，当然也可以绑定QQ邮箱。
RTX
内部通信使用腾讯企业RTX，方便分组和人员架构，就是功能太弱了，用户体验还较差！
2.3 开发环境
2.3.1 开发工具
- C#
- ASP.NET 4.0
- ASP.NET MVC 3、Razor
- HTML5
- jQuery 1.6.3
- Visual Studio 2010 Professional、Ankhsvn
- Adobe CS5、EditPlus
2.3.2 使用的软件和技术
- Windows Server 2008 R2 x64（Web版和企业版）
- SQL Server 2008 R2 running Microsoft Windows Server 2008 Enterprise Edition x64
- CentOS
- IIS 7
- Nginx
- Memcached：正移植到Redis
- HubbleDotNet：全文索引
- CKEditor
- JIRI
- VisualSVN Server
- TortoiseSVN
- Hyper-V、VMware
- Cruise Control.NET
- Cacti：安装了Nagios插件
- iDRAC：DELL远程管理卡
- SolarWinds
- Symantec Endpoint Protection：赛门铁克
2.3.3 第三方技术服务
- Google Analytics
- Apple Mobile Web Clips Icon
- 监控宝
2.4 持续集成
2.4.1
CC.NET 有关持续集成的概念和理论知识请参考《持续交付--发布可靠软件的系统方法》，目前团队还在规范化发布流程，以后会引用CC.NET来自动化这些操作，有关CC.NET的具体使用方法，园子里很多人都分享过。
本系列目录：2011 年终项目总结