CI 值得为一个或两个人的项目实施吗？
在我们进行 LOB .NET/MSSQL 开发的工作中，我们的许多项目都是 2 人甚至 1 人项目，开发生命周期为 1-3 个月。开发人员担任业务分析师/项目经理/QA，因此可以用最少的“BS 时间”快速完成工作。我们确实有一些更大的项目，可能需要 6 个月的时间，并有一个由 5 名开发人员组成的团队，但这些项目并不常见。
我们正在推动每个人都继续进行 TDD（我最近的项目具有完整的代码覆盖率并且是单独开发的），并且我正在研究充分利用它所需的架构。似乎大多数做 TDD 的人都在做 CI，有一个构建服务器，正在进行自动化构建，并有某种自动化客户端构建工具（FinalBuilder 或 nAnt）等。
所以我的问题 - 我看到了明显的好处不常见的大型项目，其中有 5 个人同时在同一个代码库上工作 - 但是我们会看到在小型 2 人项目上进行 CI 有多大好处吗？一个人的项目怎么样？对于那些人来说，这完全是浪费吗，因为你真的没有与任何人“整合”？并且，您将如何向管理层推销 CI/自动化构建/构建服务器？
At work where we do LOB .NET/MSSQL developement, many projects we have are 2 person or even 1 person projects that have development life cycles of 1-3 months. The developers serve as business analyst/project managers/QA so things get done fast with minimal 'BS time' spent. We do get the bigger projects that can take 6 months and have a team of 5 devs on it, but these are more uncommon.
We're doing a push to initiate everyone doing TDD going forward (my most recent project has full code coverage and was developed solely), and I was doing research on the architecture required to take maximum benefit of it. It seems that most people doing TDD are doing CI, have a build server and are doing automated builds and have some kind of automated client build tool (FinalBuilder or nAnt) etc.
So my questions - I see the obvious benefits on the uncommon large projects where you have 5 people working on the same codebase at once - but will we see much benefit from doing CI on the small 2 man projects? What about on a 1 man project - for those is it just a complete waste since you're really not 'integrating' with anyone? And, how would you pitch CI / automated builds / build server to management?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
恕我直言，拥有自动化/可重复的构建过程，并能够证明当前构建通过了所有测试并在服务器环境中运行，对于任何规模的项目来说都是值得的。
我会这样说：手动构建是手动的。即使是小项目，事情也可能会变得混乱。自动化构建解决了这个问题。设置构建脚本所需的时间将在应用程序的生命周期中多次增加。
就带有测试运行等的 CI 而言：这是对代码库质量的持续健康检查。当一件事无意中破坏了另一件事时，尽快知道是件好事。
Having an automated/repeatable build process, and being able to prove that the current build passes all tests and runs in a server environment is worth the effort on any size project IMHO.
I'd pitch it this way: manual builds are manual. Things can get mixed up even on small projects . An automated build solves this problem. The amount of time it takes to set up the build script will be made up many times over during the lifecycle of the application.
As far as CI with test runs etc... goes: It's a constant health check on the quality of the code base. It's good to know as soon as possible when one thing inadvertently breaks another thing.
在小型项目中，您不需要大部分基础设施来执行 CI，尤其是构建服务器。您真正需要的是测试、构建自动化、版本控制和受控构建环境。您也可以让构建和测试服务器成为在工作站上运行的虚拟机映像......只要这些映像像项目的其余部分一样受到修订控制即可。
On a small project, you don't need most of the infrastructure to do CI, especially the build server. What you do need is the tests, the build automation, revision control, and a controlled build environment. You can just as well have your build and test servers be virtual machine images you run on your workstations... just so long as the images are under revision control like the rest of the project.