这是关于企业DevOps系列博客的第四篇。该系列由CloudBees的CEO Sacha laboury和DevOps的Nigel Willie共同撰写从业者。在在上一篇文章中，我们讨论了创建分类法，并从中列出了您已经提供或希望在将来提供的功能。我们希望解决的下一个方面是向技术人员。在就组织复杂性而言，最简单的用例是，我们可以考虑一个小型初创企业或单个产品团队。在这种情况下，产品团队有可能自己拥有自动化管道，从选择到创建或采购贯穿整个软件交付管道的解决方案。根据我们的经验，当一个组织朝着企业规模发展时，组织的复杂性开始影响到每个团队拥有和维护自己的工具链的理想。在整个企业中，这可能会导致成本增加、复杂性和扩散，如我们前面所述文章在本文中，我们将讨论两种替代方法，以及一些高级考虑，如果这些方法是追求。数字1： 潜在的服务线方法企业内的产品线团队，你可能有一系列的产品线（或者在更大的层次上，业务流）。例如，在金融领域，一个组织可以拥有财富管理、保险、分析和人力资源业务线，并有单独的IT主管。一个常见的新兴模式是，在这些业务流中创建了一个DevOps自动化服务线。此服务线的任务是识别、交付和支持中的业务流的自动化管道问题。那个这种方法的优点是服务线更接近客户（这是敏捷交付方法的核心支柱）。此外，业务流中的一条服务线不太可能需要处理优先级，因此交付速度通常可以改进了。那个必须防范的潜在劣势与产品级团队相似；业务线之间存在解决方案和流程分歧的风险，可以创建筒仓，为跨企业知识共享和共生关系创造机会迷路了。交叉-产品线团队可以创建一个中央团队，负责在整个企业范围内提供自动化解决方案。其基本原理是，这使业务线能够集中精力交付业务价值，同时使用由所有业务线交叉出资的一组一致的自动化功能。这种方法的优点是它可以促进一致性，从而使所有业务线都能从最佳实践中获益。此外，这可以节省资金，因为规模经济既可以在基础设施和资源成本方面实现，也可以在供应商谈判中实现。这种方法还可以通过关注可扩展的核心企业来快速构建专业知识能力。The缺点包括集中化的团队与客户失去联系并变得疏远的风险，认为解决方案是从上面强加的，无法快速响应定制的请求或关键的请求面向小众观众。当目前大多数文学作品提倡自主性和本土化时，中央团队似乎是一种矛盾。也就是说，许多组织正在转向公共云供应，这基本上是一种集中化的方法，只是从企业号什么我们推荐吗？在许多网络论坛和利益团体中，采取正确的方法常常引起热议。我们认为，没有确切的正确答案。相反，应该考虑企业的挑战和当前的结构，而不是选择和强加给所有人的正统观念模型。它混合方法很可能适用于许多产品团队支持其特定解决方案的公司（例如利基IDE），产品线有时支持对其产品线内所有团队至关重要的产品。例如，分析团队可以支持特定的大数据工具解决方案。最后，有些产品需要集中支持—SCM就是一个很好的例子这个。什么关键是要有一个健壮且轻量级的治理过程。我们将在下一篇文章中讨论解决这个问题的潜在方法条款设置边界最后，无论在结构上选择什么方法，服务线的边界必须清楚地表达出来。如果不这样做，您可能会遇到一种我们称之为"集中自治"的现象。技术人员可能会陷入这样一种陷阱：期望提供和支持一种服务，并允许他们完全自主地使用此服务做任何他们想做的事情，但之后却期望中心团队解决他们的工件的问题，因为工件位于提供的管道或服务上。我们看到的一种可能的方法是提供各种客户自治风格的管道，并设置相应的服务级别来反映这一点。这可以从最低级别的"如果服务停止运行，我们将确保它再次恢复"到"如果您在香草状态下使用所提供的管道，我们将提供完全支持，解决时间为…"请阅读Sacha和NigelenEnterprise DevOps的Enterprise DevOps博客系列：简介Enterprise DevOps:I't Start from这里：了解你的DevOps的出发点Enterprise DevOps：上下文是KingEnterprise DevOps:创建一条服务线（本帖）Enterprise DevOps:On Governance Enterprise DevOps:脊椎是关键的企业DevOps:移动到自助服务企业DevOps:朱迪亚的人民阵线，或者不要为小东西操心企业DevOps：有意义度量的13个原则，第1部分"企业DevOps：度量的进一步考虑"，第2部分关于作者Sacha Labourysacha是瑞士人，1999年毕业于EPFL。在EPFL期间，他开始了他的第一个咨询业务-Cogito Informatique。2001年，他作为核心贡献者加入了marcfleury的JBoss项目，并实现了JBoss最初的集群特性。Sacha后来成为JBoss欧洲的总经理。在这个职位上，他领导了公司的战略，并帮助招募到了促进公司在该地区发展的合作伙伴。2005年，他被任命为首席技术官，负责监管所有JBoss工程设计部2006年6月，JBoss被Red Hat收购(纽约证券交易所：RHT). 作为首席技术官，Sacha在JBoss软件与redhat产品的集成和产品化方面发挥了关键作用。2007年，Sacha成为Red Hat中间件部门的联合总经理。他于2009年离开Red Hat，并于2010年3月成立了CloudBees。Nigel WillieWith在全球最大的金融机构之一从事IT工作超过20年，拥有管理和实施全球转型项目的经验。作为一名开发人员，Nigel最近的职责是向企业。从从他的经验来看，他理解其中的许多挑战和错误；事实上，他声称大部分错误都是他自己犯的。奈杰尔也有幸与许多高技能人士合作，无论是作为同事还是整个行业。他试图分享一些他个人的观察和想法，希望对其他人有价值。奈杰尔提出的任何原则或不是每一条都是伟大的准则，他都是有意的。