什么构成了良好的 CI 构建流程？
我们使用 CI，但是当您依赖于也应该部署的多个服务并且其他应用程序也可能依赖于这些服务时，部署到生产是否是一个现实的 CI 目标？
当一个好的 CI 构建过程自动进行 QA 并从那里手动进行时，它是否足够好？
What constitutes a good CI build process?
We use CI, but is deployment to production even a realistic CI goal when you have dependencies on several services that should be deployed too and other applications may depend on these too?
Is a good good CI build process good enough when it’s automated to QA and manual from there?
发布评论
评论（7）
好吧，“这取决于”:)
我们使用我们的 CI 系统来：
这是针对 绿地项目，包含大约十几个服务和数据库，部署到 20 多台服务器，这些服务器还依赖于六种其他“外部”服务。
使用 CI 工具将产品部署到生产环境是一个现实的目标吗？ 再说一次，“这取决于”。
你为什么想做这个？
之前必须解决的一些技术问题您可以回答这个问题：
以下是关于 自动化 和 构建您需要的工具。
归根结底，你的系统越复杂，实现一切自动化就越困难，但这并不意味着它不是一个有价值的目标，只是需要付出更多的努力和意志力才能完成——一切都来自于了解您将面临的困难、您必须考虑的问题（失败将会发生）、建设基础设施的政治挑战（相对于更多的产品功能）。
现在这是一个大秘密......技术挑战具有挑战性，但并非不可能......政治挑战可能是无法克服的。 所有这一切都需要花钱，无论是开发人员时间还是购买第三方解决方案。 那么，您真的能构建 1000 美元、10K 美元、100K 美元或 100 万美元的解决方案吗？
无论您选择哪种解决方案，首先要确保自动化功能强大，其次才是完整……即，确保您拥有尽可能强大的解决方案来部署到测试环境，而不是部署到生产环境的脆弱解决方案。
Well "it depends" :)
We use our CI system to:
This is for a greenfield project of about a dozen services and databases deployed to 20+ servers that also had dependencies on half a dozen other 'external' services.
Using a CI tool to deploy your product to a production environment as a realistic goal? Again, "it depends".
Why would you want to do this?
Some technical things you have to address before you can answer this:
Here are a couple of recent related links about automation and building the tools you need.
When it comes down to it the more complex your system the more difficult it is do automate everything, but that does not mean it is not a worthy goal, it just takes a lot more effort and willpower to get it done—everything from knowing the difficulties you're going to face, the problems you have to account for (failure will happen), the political challenges of building infrastructure (vs. more product features).
Now here’s the big secret... the technical challenges are challenging, but not impossible... the political challenges may be insurmountable. Everything about this costs money, whether it’s developer time or buying third-party solutions. So really, can you build the $1K, $10K, $100K, or $1M solution?
Whatever solution you go for, make sure the automation is robust first, complete second... I.e., make sure you have as robust a solution as you can for getting deployment to a test environment rather than a fragile solution that deploys to production.
CI 并不是一种部署机制。 让您的 CI 执行到 QA/测试服务器的任何自动部署，以确保构建工作的这些方面，这是件好事，但我不会使用像 CruiseControl 或 竹子作为部署手段。
CI 用于定期构建代码库，以自动执行自动化测试、通过静态分析验证代码库以及其他类似性质的检查。
CI is not intended as a deployment mechanism. It is good to have your CI execute any automated deployment to a QA/test server, to ensure those aspects of your build work, but I would not use a CI system like CruiseControl or Bamboo as the means of deployment.
CI is for building the codebase periodically to automate execution of automated tests, verification of the codebase via static analysis and other checks of that nature.
确保您了解 CI 构建背后的想法。 CI 代表持续集成，CI 构建实际上是一次性构建，当开发人员将代码签入源代码控制系统（或以某个指定的时间间隔）时执行，以确保最新的更改不会破坏代码库（因此不断将更改集成到代码库的想法）。
为此，与构建过程中实际发生的情况相比，用于实际构建服务器过程的技术在很大程度上无关紧要。 正如 pdavis 提到的，CI 构建应该编译代码库，执行一些代码分析（FxCop，StyleCop、Lint 等），执行 单元测试和代码覆盖率，并执行任何其他自定义您想要执行的分析应该会影响“成功”或“失败”构建的概念。
让 CI 构建自动部署到环境中实际上并不属于构建服务器的控制范围。 话虽这么说，您始终可以创建一个在构建服务器上运行的单独项目，该项目在检测到某些条件（例如构建成功完成）时处理部署，但这应该始终作为完全独立的事情来完成。
Be sure you understand the idea behind a CI build. CI stands for Continuous Integration and CI builds are really intended to be throw-away builds that are performed when a developer checks code in to the source control system (or at some specified interval) to ensure that the newest changes do not break the code base (hence the idea of continuously integrating the changes to the code base).
To that end, the technology used for the actual build server process is largely irrelevant compared to what actually happens during the build. As pdavis mentioned, the CI build should compile the code base, execute some code analysis (FxCop, StyleCop, Lint, etc.), execute unit tests and code coverage, and execute any other custom analysis you want performed that should impact the concept of a "successful" or "failed" build.
Having a CI build automatically deploy to an environment really doesn't fall under the control of a build server. That being said, you can always create a separate project that runs on the build server that handles the deployment when it detects certain conditions (such as a build completes successfully), but that should always be done as a completely independent thing.
我正在开始一个我非常期待的新工作项目。 我们仍处于初始设计阶段，最近刚刚完成逻辑系统架构。 我们已经为测试和登台环境订购了新服务器，并正在建立基于 Cruise Control (http://cruisecontrol.sourceforge.net/）和 MSBuild (http://msdn2.microsoft.com/en-us/library/wea2sca5.aspx），这基本上是 ANT 的改进端口。 Visual Studio 2005 项目和解决方案文件现在似乎都是 MSBuild 格式。 Cruise Control 将自动从 Visual Source Safe 中提取源代码（好吧，它不是 Subversion，但我们可以处理），编译它，然后通过 fxCop 运行它 (http://www.gotdotnet.com/Team/FxCop/)，nUnit (http://www.nunit.org/)，nCover (http ://ncover.org/site/），最后但不租赁 Simian（http://www.redhillconsulting.com.au/products/simian/）。 Cruise Control 有一个非常好的网站界面，用于显示各种工具的所有编译结果，甚至可以显示从一个构建到下一个构建的代码更改。 它还跟踪构建历史中的所有构建。 我期待着测试驱动开发，并认为这种与 nUnit/nCover 相结合的方法应该在我们推出没有破坏任何内容的更改之前给我们一个很好的想法。 一旦我们在项目中取得了足够的进展，我们还计划纳入某种类型的自动化用户界面测试。 根据工具的不同，这应该只是在构建服务器上安装该工具并从 Cruise Control 调用它的问题。 甜的。
I am starting on a new project at work that I am really looking forward to. We are still in the initial design stage and have just recently completed the Logical System Architecture. We have ordered new servers for the testing and staging environments and are setting up a Continuous Integration (CI) build system based on Cruise Control (http://cruisecontrol.sourceforge.net/) and MSBuild (http://msdn2.microsoft.com/en-us/library/wea2sca5.aspx) which is basically an improved port of ANT. It appears that Visual Studio 2005 project and solution files are all now in MSBuild format. Cruise Control will be automatically pulling the source from Visual Source Safe (ok, it isn't Subversion but we can deal), compiling it, and then running it through fxCop (http://www.gotdotnet.com/Team/FxCop/), nUnit (http://www.nunit.org/), nCover (http://ncover.org/site/), and last but not lease Simian (http://www.redhillconsulting.com.au/products/simian/). Cruise Control has a pretty good website interface for displaying all of the compiled results from the various tools and can even display code changes from one build to the next. It also keeps track of all builds in a build history. I'm looking forward to the test driven development and think that this type of approach combined with nUnit/nCover should give us a pretty good idea before we roll out changes that we haven't broken anything. There are also plans to incorporate some type of automated user interface testing once we are far enough along in the project. Depending on the tool, this should be just a matter of installing the tool on the build server and calling it from Cruise Control. Sweet.
一个好的 CI 流程将具有完整或接近完整的单元测试覆盖率。 单元测试测试类和方法，而集成测试则测试系统的多个部分。 当您设置 CI 构建时，让它们自动执行单元测试。 这样，CI 构建每天可以运行多次。 我们将其设置为每 2 小时运行一次。
您可以每天运行一次运行时间更长的构建。 它们可以使用其他服务并运行集成测试。
A good CI process will have full or nearly-full unit test coverage. Unit tests test classes and methods, vs. integration tests, which test multiple parts of the system. When you set up your CI builds, have them automate the unit tests. That way, the CI builds can run multiple times per day. We have ours set to run every 2 hours.
You can have longer running builds that run once per day. These can use other services and run integration tests.
发现错误越晚，修复的成本就越高。 因此应该尽早发现错误。 这就是 CI 背后的动机。
一个好的 CI 应该确保捕获尽可能多的错误。 整个应用程序由代码（通常采用多种语言）、数据库模式、部署文件等组成。其中任何一个错误都可能导致错误 - 因此 CI 应尝试尽可能多地运用其中的错误。
CI 不会取代适当的 QA 纪律。 此外，CI 不需要在项目的第一天就非常全面。 人们可以从一个简单的 CI 过程开始，该过程进行基本的编译和构建。 最初进行单元测试。 当您在 QA 中发现更多类别的错误时，您应该调整 CI 流程以尝试捕获这些错误的未来出现。 它还可以涉及静态代码分析检查，以便您可以在整个代码库中实现一致的编码和设计理念。
The later a bug is discovered, the costlier it is to fix. So bugs should be discovered as early as possible. This is the motivation behind CI.
A good CI should ensure catching as many bugs as possible. The whole application comprises of code (often in multiple languages), Database schema, deployment files etc. Errors in any of these can cause bugs - so the CI should try to exercise as many of them as possible.
CI does not replace a proper QA discipline. Also, CI need not be very comprehensive on day one of the project. One can start with a simple CI process that does basic compilation & unit testing initially. As you discover more classes of bugs in QA, you should adapt the CI process to try to catch future occurrences of those bugs. It can also involve static code-analysis checks, so that you can implement consistent coding and design ideals across the codebase.
我正在观看 Thoughtworks 演示文稿（CruiseControl），他们实际上解决了这个问题。 他们的回答是部署太复杂而无法测试。 为什么？ 因为否则，您的客户就会成为您的测试人员，而这正是您不希望出现的情况。
如果您有复杂的部署结构，请设置可视化服务器。 让它假装是您需要与之交谈的所有系统。 它们始终可以以已知的良好状态启动，因为您可以重置为干净的映像。
为了回答您的第一个问题，一个好的流程是能够实现存储库和开发人员之间的沟通的流程。 如果存储库处于不良状态（无法编译代码、测试失败等），开发人员会尽快了解情况，以便进行纠正。
I was watching a Thoughtworks presentation (creators of CruiseControl), and they actually addressed this issue. Their answer is that no deployment is too complex to test. Why? Because otherwise, your customers become your testers, which is exactly where you don't want to be.
If you have a complex deployment structure, set up a visualization server. Have it pretend to be all the systems you need to talk to. They can always start in a known good state, because you can reset to a clean image.
To answer your initial question, a good process is one which enables communication between the repository and the developers. If the repository is in a bad state (noncompiling code, failed tests, etc.), the developers know about it as soon as possible, so that they can correct it.