第10章大型的项目 面对复杂的事物，傻子忽略它，实用主义者忍受它，有人.docx

第10章 大型项目 面对复杂的事物，傻子忽略它，实用主义者忍受它，有人能回避它，天才则消灭它。 -- Alan Perlis 这一章介绍了部署大型项目时通常涉及的几个概念，以及和Rails应用特别相关的问题。这些概念对任何项目都是宝贵的，无论你使用何种框架。 10.1 版本控制 除了最最微型的项目之外，版本控制都是绝对必需的。版本控制对一个项目来说就像时间机器一样，在协作、解决问题、发布管理甚至系统管理方面都能起到辅助作用。即使对于只有一个开发者的小型应用，提供可以回溯到各个时间代码版本的能力也使版本控制工具成为最有价值的工具之一。 版本控制系统有两个主要的模型，集中式（centralized）的和分散式（decentralized）的。尽管前者已经为大多数人熟知，不过后者正在逐步稳定的流行起来，并拥有一些令人惊异的能力。 10.1.1 集中式版本控制 集中式版本控制是最流行的模型，或许也是最容易理??的。在这个模型里面有一个中央版本代码库（repository），由项目管理员操作。这个代码库维护一个虚拟的文件系统和这个文件系统的变迁历史。 图 10-1描述了集中式开发的经典工作模型。 图10-1 集中式版本控制 一个开发者按照以下的基本流程来使用版本控制系统工作： 使用checkout操作创建一个工作副本（working copy）（开发代码的一份本地拷贝）。这会将代码的最新版本下载到本地。 在本地对代码进行修改。周期性的执行update命令，这会获取上次checkout或update后代码库中发生的任何修改。这些修改通常会被自动的merge进来，也有时候需要手动介入。 当工作单元完成后，执行commit操作，向代码库发送修改。然后由步骤2开始重复，因为你本地已经有了一份工作副本。 1. CVS CVS（Concurrent Versions System，/cvs/）是仍在被广泛使用的最古老的版本控制系统。尽管Subversion已经广泛的代替了CVS，CVS最早提出和实现了集中式版本控制系统中几个核心的特性，如下列的： 同步访问 CVS之前的版本控制系统如RCS，要求开发者检出（check out）一个文件，锁住它直到提交修改后的文件才释放锁。CVS为文本文件引入了“复制-修改-合并（copy-modify-merge）”模型。在这个模型下，多个开发者可以同时修改同一文件的不同部分，然后在提交的时候将他们做出的修改合并到一起。 代码库钩子 代码库钩子是指在提交的时候运行外部程序的能力，包括运行测试，通知团队，开始编译等等。 分支和模块 CVS允许开发中存在多个并行的分支。制造商分支可以从不相关的项目中抽取代码；模块是指给成组的文件取名，以提供方便。 CVS一个常被提起的缺点是它不保证提交的原子性。如果提交在进行中被中断，可能会造成工作拷贝和代码库处在不一致的状态。大多数其他的版本控制系统都提供了原子性的保证：一次提交的内容要么全部进入代码库，要么一点也不。 实际使用中，这一点更多的体现为一种恼人的问题而不是致命缺点。重要的代码库应该定期备份，无论它们使用哪种版本控制系统。但这个缺点和其他一些限制仍然使得一些开发者感到很不愉快。因此，许多其他的版本控制系统演进了CVS的模型，CVS在新项目中也已经不经常被使用了。 Subversion Subversion（/）现在是Rails开发者中最流行的版本控制系统。它被设计为CVS的替代品，取得了很大的成功。已经习惯了CVS的开发者们能够很快的适应Subversion的命令。 作为一个集中式版本控制系统，Subversion使用一个主服务器来保存主代码库。开发者下载一份工作拷贝，进行修改，然后提交回去。Subversion默认也使用“复制-修改-合并”模型，多人可以检出同一个文件，同步进行修改，然后将他们的工作合并。非重叠的修改可以被自动的合并，冲突的修改需要手动合并。 不能被合并的文件（比如图像文件）可以被锁定，使其只能被串行的处理： $ svn lock images/logo.png -m Changing header color (work with logo.png...) $ svn ci images/logo.png -m Changed header to blue 你也可以使用svn:needs-lock属性来指定某个文件需要在被编辑之前锁定。如果一个标记了此属性的文件未经锁定就被检出，这份被检出的工作拷贝将会被设置为只读，以提醒开发者在修改文件之前锁定它。 Subversion作为CVS的替代品，在很多方面做了改进： Subversion中提交是原子的：如果提交被中断，代码库仍然保证处于一致的状态（尽管他们可能在工作拷贝中留下锁）。 Subversio