例如，一家软件开发公司，主要为其他客户提供项目在项目结束后可能永远无法维护这些。客户项目不会与其他客户共享，因为这无关紧要。
DevOps是否甚至适用于一次性开发多个项目的公司？如果有的话，什么DevOps实践适用于这种情况？
#1 楼
DevOps就是要打破传统的筒仓（部门）以提高效率。是获得更好产品的方法。
我曾经在一家大型媒体公司工作，我们将为该公司提供内部工具支持并开发面向公众的网站。
在我们的案例中，DevOps的优点如下：建立他们的代码问题。他们可以在头脑仍留在刚刚提交的代码段上的同时解决问题。
通过持续的测试和交付（进入质量检查），我们使质量检查小组能够更早发现问题并提早报告它们。这减少了查找和纠正错误的时间，并降低了调查的复杂性。
由于没有日志收集和汇总工具，我们使开发人员可以访问他们通常不会看的东西（非常热衷于调试器:)-了解日志如何被其他团队查看和使用，从而提高了日志的整体质量
我们经常共享信息并创建文档以在团队之间共享知识，以打破壁垒。通过了解Ops的需求，我们为引导应用程序时（在何处/如何管理属性等）创建了一些指南。通过了解开发人员的实际情况（编写更多功能，更快，更gogogogo！），我们能够使操作人员创建更适合开发人员需求的服务器和集群。
部署的整体质量也大大提高了。部署由我们的团队处理，因此我们对操作和开发都拥有完美的可见性。这就消除了许多与“代码移交”有关的问题，开发人员会将软件包和一页文档交给操作人员说“安装此文件！”。
总体而言，我会说无论您每天更新一次生产环境还是每月更新一次，无论您拥有多少客户或您的业务模型，每个企业都可以使用更好的沟通，更好的工具，更好的可视性，更快的反馈等。
#2 楼
我和我的团队负责开发“一次性”产品，完成后的产品将提供给客户进行保养，或者在某些情况下由我们收取费用。我们仍然需要保持稳定的开发流程来处理来自客户的不断反馈，以确保我们向他们提供可靠且经证实可以运行的产品。
尽管客户不关心DevOps（在大多数情况下），它仍然对我们有帮助。借助DevOps，我们可以快速推出新版本，因此客户可以在数分钟而不是数小时内看到反馈，并且我们还可以通过Jenkins / Travis进行测试以捕获任何错误/错误。
为确保我们的部署策略在各个项目中相同，我们专注于容器化应用程序。使用Docker，我们能够轻松地将应用程序交付给客户。
很难确定DevOps节省的成本。我们确实会以选择用于管道的软件的形式（Travis，Jenkins，Puppet等您拥有）来支付额外费用，但我们还通过修复错误/快速提供客户反馈来节省时间和金钱。快速的响应时间使我们的客户满意，从而使我们的钱包满意。
评论
您能提供一些为什么这很重要的理由和好处吗？客户实际上是在乎您的管道，还是只是在约定的日期完成项目以及他们需要支付的价格？您是否可以通过不做所有这些“开发”的事情来削减成本？您是否可以通过不做这些事情而在项目中投入更多的时间，并为项目获得更多的钱（因为时间更长）？
– Evgeny Zislis
17 Mar 1 '17 at 4:01
@Evgeny DevOps由于我的回答中所述的原因，有助于按时，按预算完成项目。通过削减DevOps，您还将削减我解释过的收益。构建和测试通常有助于保持预算和时间。后来发现一个错误需要花费更多的金钱，并且需要花费更多的时间来修复，这一点已被反复证明。客户端并不关心管道，但是您等待反馈的时间越长，重写的成本和时间就越多。
–亚历山大
17年1月1日下午5:47
不只是敏捷软件开发人员吗？
– Evgeny Zislis
17年1月1日下午5:55
@Evgeny我已经更新了答案以进行澄清。我们确实使用敏捷，但这并不意味着我们不能拥有DevOps思维。
–龟
17年1月1日在14:51
@Evgeny您可以通过不维护单元测试和验收测试来节省一些费用，但这会积累技术债务，这是DevOps的反模式。您可能会放弃它几个星期或几个月，但是您很快就会（可能）以难以维护的混乱而无法测试。
–Steve按钮
17 Mar 1 '17 at 17:25
#3 楼
我曾在为收缩包装产品，完全安装和支持的部署以及设备中的嵌入式代码的软件生产公司工作。在所有这些公司中，DevOps为开发提供了基本支持：自动化，可重复的系统测试，用于回归测试和新功能测试。其他自动化和常规操作（例如，以所有受支持的语言提供的不断更新的示例屏幕截图，供翻译人员进行验证以及技术作者纳入用户
在所有情况下，这些都是单个开发人员可以一次性完成的事情，但这并不能很好地利用开发人员的时间，也不能像自动化系统构建有。
评论
自动化不是发展。最后，与David Bock的回答相同的评论（对不起，我的投票否决了我的评论，只是注意到了）
–滕西拜
17 Mar 7 '17 at 15:59
#4 楼
以前有关软件开发和实施的活动不需要部门之间的深入整合。但是对于今天来说，有必要紧密协作所有部门（开发，IT运营，质量保证等）。业务始终需要进行更改以适应现代世界。这种理解促使开发人员产生最大数量的更改。 IT专业人员有不同的理解，即改变是有害的。他们每个人都认为它可以正常工作，从而使业务受益。的确，如果我们分别考虑它们，那么它们都是对的。所有员工必须了解它们是单个流程的一部分。 DevOps培养思想，这使人们有可能意识到每个人的个人决定和行动都应针对实现单个目标。而且成功应该相对于整个开发到交付周期来衡量，而不是从单个角色的成功来衡量。
由于开发人员和维护专家之间的紧密合作，形成了新一代工程师，充分利用这两个学科的最佳成就，并将它们结合起来，以造福用户。这体现在具有开发，配置管理，数据库管理，测试和基础结构管理经验的跨职能团队中。
因此，该方法不仅在SaaS中有用。
#5 楼
一点也不。尽管此线程上已经有很多很好的例子，但我想分享我自己的轶事。 2001年，我继承了一个软件项目，该项目的发行版本涉及CD的创建。发布过程的文档包括以前的工程师记录的40（！）个步骤，其中包括一些荒谬的手写说明，例如“打开此配置文件并在第41行更改.jar文件的名称以包括版本号。新版本”。我们甚至不得不与第三方安装工具供应商一起打开票证，以使他们的项目文件可修补。测试通过后的每个晚上，构建机器都会自动创建新的安装CD。我们的测试人员可能会在第二天早上来，拿起磁盘，并确保所有内容都可安装。反馈，周期时间，少量发布等。评论
这与自动化有关，但与devops组织毫无关系，我在任何地方都看不到有关plury学科团队的参考，只是ops使他们继承的东西自动化
–滕西拜
17 Mar 2 '17 at 19:23
那是2001年……早在DevOps成为现实之前。这不只是自动化，我相信这可以与最终被称为DevOps的“文化”的方式完全相同，从而简化了项目管理。因此，这是SaaS组织外部DevOps态度的一个示例。
–大卫·博克（David Bock）
17年3月3日在15:37
DevOps与自动化无关，也与项目管理无关。这是从根本上打破基于筒仓的组织。很抱歉，我认为这个答案与问题无关（这并不意味着它没意思，但并不是在正确的位置IMO，而且我不知道它可能在哪里出现）后来）
–滕西拜
17年3月3日在15:45
我将再尝试澄清一下-通过如此快速一致地剪切CD，我们可以比以前更快地从质量检查中获得反馈。这减少了筒仓。它并没有消除它，因为我们花了一两年的时间才取消了围绕集中预算进行活动的限制，但这当然是制止这种情况的关键一步。当发布过程中断时，我们也早就知道了。我将许多类似的小事情归功于我个人通往DevOps的道路。
–大卫·博克（David Bock）
17 Mar 8 '17 at 19:32
这最后一个评论使该问题下的答案更具意义，您应该对其进行编辑以包括在内，我仍然觉得这不适合这种格式，但是当我观察此私人Beta版的总体发展时，我的立场似乎是错误的， ... 随你（由你决定。如果没有信息编辑，我无法删除我的反对意见
–滕西拜
17 Mar 8 '17 at 19:54
评论
实际上，DevOps几乎可以应用于任何软件开发组织，甚至适用于每年只有少量公开发布的大型嵌入式产品-通过在其开发流程中使用持续交付，他们仍然可以获得一些DevOps的好处：质量更高，成本更低，发布可预测性等
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 1 '17 at 4:59
答案的确提醒了SaaS，但并未很好地解释非SaaS产品或服务如何从这些实践中受益。
– Evgeny Zislis
17年1月1日在5:18
我正在研究的产品不是SaaS（正好相反）。但是基本原理保持不变，无论您是否使用SaaS都没关系，DevOps尝试以非传统方式改进产品。我对我们的定价模式或产品一无所知，不会有太大的改变。
–亚历山大
17年1月1日在5:23