持续集成 - 最佳实践
我最近一直在思考 CI 和自动构建，并且有兴趣了解是否有设置和维护持续集成环境的最佳实践。您是否将所有 CI 相关文件与项目源代码一起签入？您通常如何构建 CI 和构建文件？欢迎任何提示！
I've been thinking about CI and automatic builds a lot lately and am interested in knowing if there are any best practices for setting up and maintaining a continuous integration environment. Do you keep all your CI related files checked in with your project source? How would you usually structure your CI and build files? Any tips are welcome!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果您还没有，请务必查看持续集成 马丁·福勒系列丛书，作者：杜瓦尔/马蒂亚斯/格洛弗。它通过坚实的示例涵盖了您深入提出的所有问题。
If you haven't already, definitely check out the Continuous Integration book from the Martin Fowler series, by Duvall/Matyas/Glover. It covers all of the questions you ask in depth with solid examples.
还有实用系列的“实用项目自动化”。
当然，构建所需的所有文件都必须签入。否则 CI 将如何获取它们？
我已经将 CI 与 Java 结合使用，因此这意味着 Ant build.xml 以及 Cruise Control、Team City 或 Hudson。如果您坚持为项目使用一致的目录结构，则 build.xml 可能是通用的。
There's also the Pragmatic Series' "Pragmatic Project Automation".
Of course, all files required to build have to be checked in. How else would CI get at them?
I've used CI with Java, so that means an Ant build.xml and either Cruise Control, Team City, or Hudson. It's possible for the build.xml to be generic if you stick with a consistent directory structure for your projects.
流行的 Jenkins/Hudson CI 工具的创始人 Kohsuke Kawaguchi 刚刚发布了一份可能对您有所帮助的白皮书。
优化 Jenkins 的 7 种方法
Kohsuke Kawaguchi, the founder of the popular Jenkins/Hudson CI tool, just published a white paper you might find helpful.
7 Ways to Optimize Jenkins
如果您的构建脚本开始变大，您可以将其拆分并包含相关部分。这使得维护和可读性更好。
我的其他建议与传统编程不同——在制作构建脚本时使用大量的注释。
If your build script starts getting big you can split it out and include the relevant parts. This makes maintenance and readability better.
My other advice would be unlike traditional programming - when making a build script make use of liberal amounts of comments.