首先，这不是一个雄心勃勃的目标，使用得到良好支持的工具很常见。所以你正在正确的轨道上，并且很清楚地确定了你的优先事项，做得好。
脚本编写
首先，如果可能的话，请不要使用批处理文件。因为批处理语言实在是太糟糕了，有许多缺失的语言结构，难以完成任何复杂的操作。专家们可以用bat完成许多操作，但我在构建系统中使用bat脚本的经验是它们普遍难以维护。
你需要编写一些操作系统级别的脚本将所有这些内容组合在一起，但你需要使用一个稳定的编程语言来进行编写。 推荐使用以下几种语言：
- Powershell
- Python
- Bash (即cygwin)
nAnt是管理构建步骤的一个好工具。配置xml文件被检入、分支、合并和与所有其他文件进行差异比较的事实是一个巨大的优势。
Make和Scons也是很好的工具。
这些脚本需要有干净的输出和良好的错误信息，特别是优秀的错误信息，编写给予良好错误信息的构建脚本永远不会浪费时间。 此外，仔细管理操作系统错误代码，并确保每个构建命令在失败时都会引发错误代码。 所有CI服务器都将使用此代码来标记构建失败。 如果你在第2步失败，但直到第10步才引发一个错误代码，那么调试就会非常困难。
单元测试
是的，他们应该成为你的构建的一部分。现在存在着各种编程语言下的单元测试框架，它们都可以通过命令行运行。因此，选择最适合你的即可开始。
持续集成
一旦你的构建流程可以通过命令行启动一个完整的构建（从源代码到可出货状态），那么就是时候考虑所谓的持续集成工具/服务器了。 Jenkins是一个好的选择，Cruise Control和Buildbot也不错。我用过它们所有，它们都很好，挑选一个并开始使用吧。一旦你开始使用它们，它们并不难学习，并且可以管理你所需要的大量通知功能。要记住的主要事情是它们都是用于执行和报告命令行参数。
当你构建流程结构清晰时，请记住它由四个基本步骤组成：
- 从存储库中获取代码
- 预构建；更新版本号等
- 编译/构建
- 后构建；打包；压缩构建产品，制作.iso镜像等
- 发布：将构建产品移动到某个人们可以找到它们的地方（在你的情况下是Web服务器）
配置文件
如果你能把你的配置管理控制在一个文件之内，那么你就得意扬扬吧，这将给你带来巨大的收益。你说你不想维护三个不同的文件。你能否确定一组规则，将一个基本文件转化为要发布的三个文件？如果可以，那么你可以编写一个脚本，在打包阶段为你完成这个转换。记住我说过“不要使用批处理文件”吗？这种任务正是批处理文件擅长的地方，这些任务总是会出现在构建系统中。
结论
最后，请记住，所有这些的目的是：
a. 确保在提交代码到交付产品之间没有任何手动步骤。人们很容易犯错，他们不总是周末工作，像这样的事情。
b. 给开发人员快速和完整、具体的反馈，以确保他们提交的内容可行。
祝好运！
