是否有不使用版本控制和持续集成的严肃公司？为什么？

我的一位同事给我们的印象是我们的软件部门非常先进，因为我们同时使用了具有持续集成功能的构建服务器和版本控制软件。这与我的观点不符，因为我只知道一家公司制造过认真的软件，却没有一家。但是，我的经验仅限于少数公司。

有谁知道有一家从事软件业务并且不使用这些工具的真实公司（超过3个程序员）？如果存在这样的公司，是否有充分的理由让他们不这样做？

我不确定您是否会称其为认真的举动，但MySpace在这方面还很糟糕：请参阅http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill- myspace.html。

您会惊讶地看到现实对常识有何帮助;-)

我认为仍然有很多公司没有使用版本控制系统。有趣的是，到目前为止，我所看到的所有情况都不是因为他们愿意反对使用此类系统，而是因为他们不知道像SVN这样的东西存在！至于我：我完全同意您的看法，无法想象我不想使用任何版本控制的情况。地狱，我什至将自己的个人文件（word文档等）推送到家用PC上的GIT存储库中。

在持续集成系统的情况下，在日常操作中不使用它们是很常见的。有时也是因为人们不知道这样的系统存在，但是我也看到过这样的情况：-非常可疑-不使用它们的借口是“我们不够复杂”或“如果不进行持续集成，它就可以很好地工作，那么为什么还要增加另一项技术呢？” 当然，这并不是一个现实的评估-而是要回答最初的问题：这并不是很常见。

我所在行业（银行）中的几乎每家公司目前都使用版本控制。但是在没有版本控制的情况下成功开发软件当然是可能的。20-30年前。我们正是这样做的。

我想说，许多银行，甚至可能是大多数银行，都不会使用持续集成的构建服务器。如果您已经成功交付了软件而没有进行持续集成，那么沿着这条道路继续走是完全合理的。

只是为了反驳@RoadWarrior的答案：

我在一家银行工作。我花了近三年的时间来实施版本控制，现在设法在我们代码库的20％左右使用它（这相当大，我们大约有20位开发人员，并且我们开发系统的时间超过16年）

通过我在行业（银行）的接触，我知道的吨其他金融机构的没有了任何理智的人会打电话版本控制。

是的，我们的行业（软件开发）比大多数人想承认的要难得多。

版本控制：25年前，我的第一份工作没有这样的版本控制系统，但这是PDP-11上的RSX11。然而，有一个非常有设计和代码的正式审核（这是在核工业）的质量控制水平高。

从那时起，每项工作都使用了版本控制系统，包括SCCS，PVCS，clearcase，cvs和perforce。

因此，以我的经验，版本控制在严肃的软件开发中非常普遍。

持续集成：这是一个更大的问题，尤其是在具有大量旧代码的地方，这些地方甚至可能没有太多的自动化测试方法。将现有代码转移到CI环境中需要大量投资，尽管最终可能会获得回报，但很难让管理层做出这样的投资而没有短期收益。

我曾在一个地方（一家大型银行）工作过，该地方为某些项目设置了CI，我们在项目上实施了一种CI系统，这确实使事情变得容易得多，但花了大约6个月的时间。

我可以想象，大多数MOST公司不会使用这些东西，因为它们不了解收益，而开发人员要么不想学习，要么害怕通过做与以往不同的事情来“搅动锅”以前做过。

尽管我现在是一名员工，但我曾经是一名自雇人士，担任数据库顾问。在那些很多年的时间里，我曾在800到1000家公司中工作，从准妈妈到流行100年代。

我看到的地方很少进行持续集成，但是我不记得曾经见过一家不使用版本控制的公司。我确实看到了一些没有用于版本控制代码的集中存储库的地方。各个程序员可以在自己的计算机上使用版本控制，也可以将版本控制的代码保存在服务器主目录下。

我不认为这些公司中有任何一家从事软件业务，但是他们的程序员当然是。

我的一位同事给我们的印象是我们的软件部门非常先进，因为我们同时使用了具有持续集成功能的构建服务器和版本控制软件。

不，我不想说，但这是事实。我工作的最后两个地方（一家银行的部门和一家金融公司）是实施版本控制系统的那个地方。许多地方（尤其是非软件商店）不了解为什么长期发展确实需要它。团队通常从一两个人开始，然后从那里成长，尽管很痛苦。没有一个人，一个人或两个人就可以相处（不好），因为彼此之间几乎可以保持不断的交流。

连续构建是完全不同的情况。如果我不得不猜测，我敢打赌，几乎90％的开发场所都没有CI解决方案。我参加会议时，大多数人都为MS或Google以外的组织感到惊讶。我发现，即使它可以节省很多时间，管理层也不想花一小笔钱来启动和运行它。

我为此找到的最大原因是：

1. 管理人员已在同一组织中晋升。他们从未使用过，也不需要它，为什么现在需要更改？我发现有些人只是害怕改变。有些新东西令人恐惧，它会阻止他们使用旧的编译器，并在需要时为我们的年轻编译器提供帮助。在其他时间（且经常），他们的预算总是很紧张，并且他们必须决定在哪里花钱。对于我们来说，实现这些功能是很明显的需求，但这是因为我们之前已经使用过它们。我们知道好处，但他们不知道。

2. 经理是非IT人员，他们在这里的全部目的就是要花钱购买以前不需要的东西。

我从人们那里听到的大多数争论都围绕最佳实践等，而这些都是正确的，但是大多数开发人员不了解的是，在这种情况下，您必须根据财务状况来进行构架。有了您要花费的这笔钱，我们将节省X的时间，并且您需要数字来备份它。这并不总是正确的，但是我过去的经验一直如此。

我会说很多人不使用源代码管理，因为他们可能自己编写代码，并习惯于定期将代码库备份到中央服务器或USB硬盘驱动器。大约一年前，我强迫自己开始使用SVN，因为我知道从长远来看它将是有益的。花费了一段时间才能习惯它，但是现在我有很多代码历史可以随时参考。我现在希望四年前开始实施时就已实施。

持续集成？仅在需要时使用它。对我来说，只有两名软件工程师，所以我们不能从持续集成中受益，因为我们自己开发自己的软件。

哈，您认为自己先进，因为您拥有SCM和CI系统？让我告诉你这是业余时间。

许多公司都做到了最低要求，因为这是它真正需要的。如果可行，并且您无需花费大量精力即可获得良好的可复制发行版，则无需进行任何修复。在这种情况下，您要做的最后一件事是开始“修复”问题，尤其是在将管理资源从他们的工作中移出来设置和管理新服务器以及构建系统的时候。

但是，有些公司需要更严格的系统，一旦这样做，不仅要进行构建，还要通过测试计划和测试结果来控制整个需求，直至部署，并接受代码审查，工作流样式的签入程序和团队负责人指定的工作包管理。这是真正的配置管理，很高兴您不必在那种环境下工作！

我曾在几家公司工作，我想不出没有某种形式的SCM。他们中的一些人比其他人更全面，但是他们每个人都有一个对他们来说运作良好的系统，即使是使用VSS的系统。

即使有两个程序员，当您在处理复杂的应用程序和一系列任务时，也很难不互相敲击。

甚至我们以前的版本管理软件也可以并行显示更改，并允许将它们应用于任一方向。没有它，就不会多次错过变更。

我看到了CI带来的许多好处，但是我无法想象为什么任何公司都不会使用版本控制软件。

我上次没有版本控制的工作是在2006年（我是Web开发人员FWIW）。在雇用我之前，该公司只有大约2到3个开发人员，但是在短短几个月内，我是10个左右的开发人员中的第一个。聘用时我做的第一件事就是引入版本控制（CVS，因为当时我还不知道它的糟糕程度！），但是在我之后聘用的许多开发人员无法将其用于他们的开发工作环境，所以没有使用它。哦，我是否提到他们甚至没有运行该应用程序的本地实例？他们入侵了服务器上的代码。当然，没有自动化测试。当我回想一下时，我会畏缩。

在此之前，我做了一些没有版本控制的AS / 400编程工作。我不知道在该环境下是否还可以使用像样的VCS。

现在，我将Git用于所有的单人项目，而我的前几项工作也都使用了它。

CI是另一回事。很棒，我鼓励这样做，但是它比版本控制要重要，至少对于使用解释语言的较小项目而言。不过，我最近的大部分工作都使用CI服务器。除其他外，这意味着没有人会忘记在部署之前运行完整的测试套件。

我肯定到处都碰到了一些，但大多数都是小型公司。我经常看到的问题是实际上拥有SCM的公司，但认为许多项目太小或不重要而无法追踪。