[2011 年终项目总结] 第二章、环境搭建

　　“工欲善其事，必先利其器”，在具备好的协作团队的同时又具备有好的开发环境，当然会事半功倍！本章将为大家介绍我们的技术团队在协作的过程中所用到的软件环境。

　　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，另外也是免费的。

• 官方地址：http://www.visualsvn.com/server/
• 下载地址：http://www.visualsvn.com/server/download/

　　客户端

　　TortoiseSVN：集成操作系统的资源管理器，方便更新和提交，官方网站提供中文包下载。

• 官方地址：http://tortoisesvn.net/
• 下载地址：http://tortoisesvn.net/downloads.html

　　Ankhsvn：将Subversion的操作集成在Visual Studio的SVN Client软件，支持Visual Studio 2010。

• 下载地址：http://ankhsvn.open.collab.net/

　　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邮箱。

　　官方地址：http://exmail.qq.com/

　　RTX

　　内部通信使用腾讯企业RTX，方便分组和人员架构，就是功能太弱了，用户体验还较差！

　　官方地址：http://rtx.tencent.com/

　　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 年终项目总结