您为谷歌描述的是每个基本构建过程的作用。 特定项目可能有其他需求，例如 - 我们如何从暂存到生产部署 Web 应用程序：
构建开始
实时站点脱机（Apache 重定向到包含“正在建设”页面的不同目录）
为生产服务器运行 SVN 更新
数据库架构运行增量
针对更新的源和模式运行测试
如果失败：运行回滚（SVN 恢复和数据库模式撤消）
站点恢复在线
构建结束
What you described for google is what every basic build process does. Specific projects may have additional needs, for example - how we deploy web applications from staging to production:
Build start
Live site is taken offline (Apache redirects to different directory holding an "Under construction" page)
SVN update is ran for production server
Database schema deltas are ran
Tests are ran against updated source and schema
In case of fail: rollback is ran (SVN revert and database schema UNDO)
在 java 平台上，我尝试了所有主要的 CI 系统。 我的建议是，为商业支持的解决方案付费是我见过的最便宜的构建系统。 这些事情需要时间来维护、支持和排除故障。 尤其是在一直运行大量构建的情况下。
On the java platform I have tried every single major CI system there is. My tip is that paying for a commercially supported solution has been the cheapest build system I've ever seen. These things take time to maintain, support and troubleshoot. Especially with a heavy load of builds running all the time.
发布评论
评论（3）
您为谷歌描述的是每个基本构建过程的作用。 特定项目可能有其他需求，例如 - 我们如何从暂存到生产部署 Web 应用程序：
What you described for google is what every basic build process does. Specific projects may have additional needs, for example - how we deploy web applications from staging to production:
在 java 平台上，我尝试了所有主要的 CI 系统。 我的建议是，为商业支持的解决方案付费是我见过的最便宜的构建系统。 这些事情需要时间来维护、支持和排除故障。 尤其是在一直运行大量构建的情况下。
On the java platform I have tried every single major CI system there is. My tip is that paying for a commercially supported solution has been the cheapest build system I've ever seen. These things take time to maintain, support and troubleshoot. Especially with a heavy load of builds running all the time.
您提供的示例工作流程与 TeamCity 提出的工作流程类似。 这个想法是：
这是一场宗教战争，但我更喜欢：
每个负责任的程序员都应该在提交之前运行所有测试。
第一种方法的主要论点是它保证 SCM 中没有损坏的代码。 但是，我认为：
The example workflow you give is similar to the one proposed by TeamCity. The idea being:
It's a religious war but I prefer:
Every responsible programmer should run all the tests before committing.
The main argument for the first way is that it gurantees that there is no broken code in SCM. However, I would argue that: