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