操作系统和编程框架之间的实现显然有很大的区别，但理念基本一致。脚本应该完成你在构建/编译/交付准备环境时通常要做的所有事情。通常，这意味着编译代码，使用特定的编译选项，将输出文件和原始代码库分开保存，做部署准备。即便在无须编译的项目中，例如静态网站，项目中可能有不可动态更新的内容，例如测试页面或调试脚本，你想在源码控制系统中统一管理这些内容，但是在你确实想要部署时，构建脚本将文件交付准备环境时不会发布这些内容，所以你无须每一次都要考虑这些事情。

　　除了基本的构建/编译/交付准备环境等步骤，你其实可以做任何想做的。想压缩JavaScript文件？为它创建一个任务。编译之前代码中需要时间戳？创建一个任务。为了不让网站落入对手囊中，需要分型数据加密算法？添加一个任务（请个人帮忙）。在构建流程中，你能在命令行做的都能在代码编译前后执行。

　　大多数软件项目都不止一个模块。例如，你可能有个web应用程序，但你还有个独立的数据库，它是该整体解决方案的一部分。对于这种场景，单个控制脚本是解决的方法。该脚本是控制器，每次调用一个单独脚本。在每个Visual Studio项目、Java包、抑或是自定义的代码结构中都有脚本。每个单独的脚本都有该项目特有的任务，而控制脚本包含了所有共享功能。

　　尽可能使脚本通用并且可重用。使用相对路径，不要使用路径，具体项目的信息定义在一处，可重用的信息定义在控制脚本中。这么做便于维护，也有助于今后构建新项目。

　　持续集成

　　一旦编写了脚本，项目可以通过一个命令完成编译和交付准备环境。这是个良好的开始，但还需要有人执行命令。我们的目标是去除人工介入，所以持续集成将为我们考虑这些。

　　至于构建脚本，供选择的有许多种不同的技术，项目的组织方式也多种多样。但再次强调，你将想要找到适合于你的解决方案，并坚持下去，以便在项目中保持一致性。

　　一些流行的选择是TeamCity、Jenkins、CruiseControl（或CruiseControl.NET），如果你喜欢多用途的应用程序， Microsoft Team Foundation Server除了源码控制和构建之外还能够完成持续集成。每个产品都有各自的目标受众，但是他们全都是设计用来监视源码并自动运行构建脚本，所以不需要手工完成这些。持续集成服务器的传统策略是监视源码控制仓库的变动，当有变动时自动下载新代码，然后执行脚本，它依次编译应用程序并为发布做准备。然而，在构建脚本中，你能够添加任何你需要的任务或行为。

　　你可以设置单元测试或任何其他你编写的自动化测试作为该流程的一部分执行。一旦有人提交代码，测试将立即运行。至于测试不通过，更有甚者编译不通过，你会被告知出错了，所以这些问题能够被快速处理。本人而言，我建议用飞镖射击责任人（戴高帽是另一个不错的选择），但是如何实现当然是由你决定。

　　发布

　　到目前为止所有的一切都是为了这一刻。此刻我们只是提交了代码，自动编译了，运行了测试，交付到准备环境和做好了发布的准备。后一步是将交付准备环境的代码发布到任何需要的地方。

　　发布自己托管的web应用程序通常是将文件从准备环境拷贝到web服务器。这可能意味着人工拷贝文件，或整理到一个简单的批处理/shell脚本中。因为我们仍在努力使生活变得简单并且自动化，你将寻求更佳的解决方案。取决于你们单位的安全策略，你也许能够将持续集成流程中的任务组织在一起，以便通过文件系统或FTP拷贝文件。至于一个纯HTTP的解决方案，你可以看看DubDubDeploy等产品，它不受域安全或文件系统访问的限制，能够服务器之间拷贝文件。

　　如果你有个包装产品，后一步只要简单地将产品打包。构建脚本可能已经处理了创建安装包，组织文档，以及其他与发布文件相关的东西。现在有了可部署的产品，剩下的是将产品拷贝到3.5英寸软盘、打包、发布。

　　总结

　　组建自动化构建环境可能会花些时间，让它按你想要的方式工作至少需要几天时间，也可能是几个礼拜，可能还要按照你自己的意愿做调整。后，你需要权衡后续每天将节省的时间，以及那些平时大家很容易掉入而在采用一致的过程后可以有效避免的陷阱。

　　当每个人都做他们擅长事情的时候，你的组织会是高效的。开发人员编写代码，构建工程师处理构建和部署配置，构建服务器完成所有重复性任务，它的确做得很出色。运转流畅的软件过程通常会直接提升产品质量和缩短发布周期，两者都将极大地影响着你公司的财务状况。