如果您是一名独立开发人员，并且您有在提交之前运行测试的良好习惯（您应该这样做），那么 CI 就没有那么有用了。 话虽如此，您可能会养成让 CI 为您进行测试的坏习惯。
作为一名独立程序员，这主要取决于纪律。 使用 CI 是一项有用的技能，但您希望避免养成任何无法转化为团队环境的坏习惯。
The basic concept of CI is that you have a system that builds the code and runs automated tests everytime someone makes a commit to the version control system. These tests would include unit and functional tests, or even behavior driven tests.
The benefit is that you know - immediately - when someone has broken the build. This means either:
A. They committed code that prevents compilation, which would screw any one up
B. They committed code that broke some tests, which either means they introduced a bug that needs to be fixed, or the tests need to be updated to reflect the change in the code.
If you are a solo developer, CI isn't quite as useful if you are in a good habit of running your tests before a commit, which is what you should be doing. That being said, you could develop a bad habit of letting the CI do your tests for you.
As a solo programmer, it mainly comes down to discipline. Using CI is a useful skill to have, but you want to avoid developing any bad habits that wouldn't translate to a team environment.
正如其他人所指出的，CI 对于独立开发人员来说确实有优势。 但你必须问自己的问题是： 值得花费这些开销吗？ 如果你像我一样，为一个项目设置 CI 系统可能需要一两个小时，因为我必须分配服务器、设置所有网络并安装软件。 请记住，CI 系统一次只能为您节省几秒钟。 对于独立开发人员来说，这些时间加起来不太可能超过进行 CI 设置所需的时间。
但是，如果您以前从未设置过 CI 系统，我建议您只是为了学习如何设置而这样做。 它不需要太长的时间，以至于不值得学习。
As other people have noted, CI does have advantages for a solo developer. But the question you have to ask yourself is; is it worth the overhead? If you're like me, it will probably take an hour or two to set up a CI system for a project, just because I'll have to allocate a server, set up all the networking, and install the software. Remember that the CI system will only be saving you a few seconds at a time. For a solo developer, these times aren't likely to add up to more than the time it took to do the CI setup.
However, if you've never set up a CI system before, I recommend doing it just for the sake of learning how to do it. It doesn't take so long that it isn't worth the learning experience.
CI 构建也可以被视为您的“发布”构建。 环境应该稳定，并且不受您刚刚添加到计算机中的任何开发小玩意的影响。 它应该允许您始终重现构建。 如果您向项目添加新的依赖项，并且忘记设置发布构建环境以将其考虑在内，那么这可能会很有价值。
The benefit of CI lies in the ability to discover early when a check in has broken the build. You can also run your suite of automated tests against the build, as well as run any kind of tools to give you metrics and such.
Obviously, this is very valuable when you have a team of commiters, not all of whom are diligent to check for breaking changes. As a solo developer, it is not quite as valuable. Presumably, you run your unit tests, and even maybe integration tests. However, I have seen a number of occasions where the developer forgets to checkin a file out of a set.
The CI build can also be thought of as your "release" build. The environment should be stable, and unaffected by whatever development gizmo you just add to your machine. It should allow you to always reproduce a build. This can be valuable if you add a new dependency to your project, and forget to setup the release build environment to take that into account.
如果您需要支持多个编译器，那么使用 CI 构建系统来完成所有这些工作会很方便，同时您只需在一个 IDE 中进行开发。 我的代码在 x86 中使用 Vc6 到 VS2008 构建，而 x64 在 VS2005 和 VS2005 上构建。 8，所以每个项目配置有 7 次构建...拥有 CI 系统意味着我可以在一个 IDE 中进行开发，并让 CI 系统证明我支持的所有编译器仍在构建。
同样，如果您正在构建由多个项目使用的库，那么 CI 将确保它们适用于所有项目，而不仅仅是您现在正在使用的项目......
If you need to support multiple compilers then it's handy to have a CI build system to do all of that whilst you just develop in one IDE. My code builds with Vc6 through VS2008 in x86 and x64 builds on VS2005 & 8, so that's 7 builds per project per project configuration... Having a CI system means that I can develop in one IDE and let the CI system prove that all of the compilers that I support still build.
Likewise, if you are building libs that are used by multiple projects then CI will make sure they work with ALL of the projects rather than just the one that you're working with right now...
事实是，持续集成在团队中最有意义。 单个开发人员也可以获得一些优势，您必须自己决定它们是否足以抵消您在设置 CI 系统上投入的时间。
如果您忘记签入某些所需的文件，则存储库包含损坏的版本，即使它可以在您的计算机上运行。 CI 会检测到这种情况。
如果您的 CI 服务器在不同的计算机上运行，它可以指示对您的构建环境的依赖关系。 意味着，构建和所有测试都可以在您的开发盒上运行，但在另一台机器上，某些依赖关系未得到满足，并且构建会中断。
每日构建可以表明，您的旧软件无法与操作系统/编译器/库的最新升级一起使用...
如果您的 CI 系统有构建工件的存档，您可以轻松获得旧版本的发行版你的软件。
一些 CI 有一个很好的界面来向您显示有关构建的指标，并具有自动生成的文档和类似内容的链接。
The truth is, that continuous integration makes most sense in teams. Single developers can also get some advantages, you must decide yourself if they are enough to counter the time you invest into setting a CI-system up.
If you forgot to checkin some needed file, the repository contains a broken version, even if it works on your machine. CI would detect that case.
If your CI-server runs on a different machine, it can indicate dependencies on your build-environment. Means, the build and all tests can work on your dev-box, but on another machine some dependencies aren't fulfilled and the build breaks.
Daily builds can indicate, that your older software doesn't work with the newest upgrade of the OS/compiler/library...
If your CI-system has an archive of build-artifacts you can easy get an distribution of an older version of your software.
Some CI have a nice interface to show you metrics about your build, have links to automatic generated documentation and stuff like that.
CI 对独立开发人员有好处，因为如果您忘记签入某些内容，您会意识到（因为构建会被破坏）。 然而，当没有其他开发人员时，它的集成价值就会减弱。
CI benefits a solo developer in the sense that you're aware if you forgot to check something in (because the build will be broken). The integration value of it is diminished when there are no other developers, though.
发布评论
评论（7）
CI 的基本概念是，您拥有一个系统，该系统可以构建代码并在每次有人提交到版本控制系统时运行自动化测试。 这些测试将包括单元和功能测试，甚至行为驱动的测试。
好处是您可以立即知道有人破坏了构建。
这意味着：
A。 他们提交了阻止编译的代码，这会搞砸任何人
B。 他们提交的代码破坏了一些测试，这要么意味着他们引入了需要修复的错误，要么需要更新测试以反映代码中的更改。
如果您是一名独立开发人员，并且您有在提交之前运行测试的良好习惯（您应该这样做），那么 CI 就没有那么有用了。 话虽如此，您可能会养成让 CI 为您进行测试的坏习惯。
作为一名独立程序员，这主要取决于纪律。 使用 CI 是一项有用的技能，但您希望避免养成任何无法转化为团队环境的坏习惯。
The basic concept of CI is that you have a system that builds the code and runs automated tests everytime someone makes a commit to the version control system. These tests would include unit and functional tests, or even behavior driven tests.
The benefit is that you know - immediately - when someone has broken the build.
This means either:
A. They committed code that prevents compilation, which would screw any one up
B. They committed code that broke some tests, which either means they introduced a bug that needs to be fixed, or the tests need to be updated to reflect the change in the code.
If you are a solo developer, CI isn't quite as useful if you are in a good habit of running your tests before a commit, which is what you should be doing. That being said, you could develop a bad habit of letting the CI do your tests for you.
As a solo programmer, it mainly comes down to discipline. Using CI is a useful skill to have, but you want to avoid developing any bad habits that wouldn't translate to a team environment.
正如其他人所指出的，CI 对于独立开发人员来说确实有优势。 但你必须问自己的问题是： 值得花费这些开销吗？ 如果你像我一样，为一个项目设置 CI 系统可能需要一两个小时，因为我必须分配服务器、设置所有网络并安装软件。 请记住，CI 系统一次只能为您节省几秒钟。 对于独立开发人员来说，这些时间加起来不太可能超过进行 CI 设置所需的时间。
但是，如果您以前从未设置过 CI 系统，我建议您只是为了学习如何设置而这样做。 它不需要太长的时间，以至于不值得学习。
As other people have noted, CI does have advantages for a solo developer. But the question you have to ask yourself is; is it worth the overhead? If you're like me, it will probably take an hour or two to set up a CI system for a project, just because I'll have to allocate a server, set up all the networking, and install the software. Remember that the CI system will only be saving you a few seconds at a time. For a solo developer, these times aren't likely to add up to more than the time it took to do the CI setup.
However, if you've never set up a CI system before, I recommend doing it just for the sake of learning how to do it. It doesn't take so long that it isn't worth the learning experience.
CI 的好处在于能够尽早发现签入破坏了构建的情况。 您还可以针对构建运行一套自动化测试，以及运行任何类型的工具来为您提供指标等。
显然，当您拥有一支提交者团队（并非所有人都努力检查重大更改）时，这是非常有价值的。 作为独立开发者，它的价值并不高。 据推测，您会运行单元测试，甚至可能运行集成测试。 然而，我曾多次看到开发人员忘记从一组文件中签入文件。
CI 构建也可以被视为您的“发布”构建。 环境应该稳定，并且不受您刚刚添加到计算机中的任何开发小玩意的影响。 它应该允许您始终重现构建。
如果您向项目添加新的依赖项，并且忘记设置发布构建环境以将其考虑在内，那么这可能会很有价值。
The benefit of CI lies in the ability to discover early when a check in has broken the build. You can also run your suite of automated tests against the build, as well as run any kind of tools to give you metrics and such.
Obviously, this is very valuable when you have a team of commiters, not all of whom are diligent to check for breaking changes. As a solo developer, it is not quite as valuable. Presumably, you run your unit tests, and even maybe integration tests. However, I have seen a number of occasions where the developer forgets to checkin a file out of a set.
The CI build can also be thought of as your "release" build. The environment should be stable, and unaffected by whatever development gizmo you just add to your machine. It should allow you to always reproduce a build.
This can be valuable if you add a new dependency to your project, and forget to setup the release build environment to take that into account.
如果您需要支持多个编译器，那么使用 CI 构建系统来完成所有这些工作会很方便，同时您只需在一个 IDE 中进行开发。 我的代码在 x86 中使用 Vc6 到 VS2008 构建，而 x64 在 VS2005 和 VS2005 上构建。 8，所以每个项目配置有 7 次构建...拥有 CI 系统意味着我可以在一个 IDE 中进行开发，并让 CI 系统证明我支持的所有编译器仍在构建。
同样，如果您正在构建由多个项目使用的库，那么 CI 将确保它们适用于所有项目，而不仅仅是您现在正在使用的项目......
If you need to support multiple compilers then it's handy to have a CI build system to do all of that whilst you just develop in one IDE. My code builds with Vc6 through VS2008 in x86 and x64 builds on VS2005 & 8, so that's 7 builds per project per project configuration... Having a CI system means that I can develop in one IDE and let the CI system prove that all of the compilers that I support still build.
Likewise, if you are building libs that are used by multiple projects then CI will make sure they work with ALL of the projects rather than just the one that you're working with right now...
事实是，持续集成在团队中最有意义。 单个开发人员也可以获得一些优势，您必须自己决定它们是否足以抵消您在设置 CI 系统上投入的时间。
The truth is, that continuous integration makes most sense in teams. Single developers can also get some advantages, you must decide yourself if they are enough to counter the time you invest into setting a CI-system up.
我们使用 CI 系统进行发布构建（以及通常的自动“提交”构建）。
能够单击一个按钮来启动发布构建，逐步完成所有流程来发布设置是：
在敏捷环境中，您期望每 2-4 周交付一次工作软件，这绝对值得拥有，即使在 1 人团队中也是如此。
We use our CI system to do Release builds (as well as the usual automatic "on-commit" builds).
Being able to click a button that kicks off a Release build that steps through all the processes to release a setup is:
In an Agile environment, where you expect to be delivering working software every 2-4 weeks, this is definitely worth having, even in a team of 1.
CI 对独立开发人员有好处，因为如果您忘记签入某些内容，您会意识到（因为构建会被破坏）。 然而，当没有其他开发人员时，它的集成价值就会减弱。
CI benefits a solo developer in the sense that you're aware if you forgot to check something in (because the build will be broken). The integration value of it is diminished when there are no other developers, though.