这是关于企业DevOps系列博客的第六篇。该系列由CloudBees的CEO Sacha laboury和DevOps的Nigel Willie共同撰写从业者。在在前面的文章中，我们讨论了创建功能的标准分类法，并从这里开始确定他们。而所有功能对于提供完整的解决方案至关重要，重要的是，您不要把重点放在为您的企业交付单个解决方案上。核心DevOps功能的前缀是连续的（集成、交付、部署、监视）并不是偶然的。引用乔治·奥威尔在《动物农场》一书中的话：在DevOps的背景下，"所有工具都是平等的，但有些工具比其他工具更平等。"从经验来看，早期的大多数要求都是针对个人能力的。例如，"我们需要自动化测试工具"或"我们需要对需求工具解决方案进行改进"等。我们建议您避免交付单一功能的解决方案，而不确保您交付的产品能够轻松集成到您的产品线中，或者脊椎。安管道的早期可视化表示是一种非常有用的方法，可以将这一原则强加给自己。在与整个企业的利益相关者讨论需求时，它还强调了单个解决方案在更大的生态系统中的位置。管道的概念对DevOps来说是如此基础，以至于技术人员常常认为这是理所当然的。在一个更大的企业中，避免假设并向所有利益相关者清楚地表明对集成能力的关键依赖是至关重要的管道。我们同时也要提醒大家不要成为相反问题的牺牲品。虽然不能使用点式解决方案实现连续自动化，但也应避免提供紧密集成的自动化管道。你的技术专家应该经常听到这样的信息：他们提供的解决方案需要从单一的整体到微观的服务，他们需要通过API去耦合、去除依赖和抽象。同样的基本原理也适用于交付管道。不要创建一个整体的、紧密耦合的管道，而是在企业自动化解决方案中使用API和配置。在调查潜在的解决方案（无论是国产的、开源的还是供应商提供的）时，一个关键的问题应该是："这是否将我与未来的特定生态系统或解决方案联系在一起，还是我们可以继续利用各种解决方案？"工具链的脊椎对于任何自动化计划的成功都是至关重要的。如果不尽早交付一个健壮、一致和可配置的脊椎，您将为您和您的客户带来重大问题。设计集成到解决方案中总是比将其改造到现有点更容易解决方案。遵循来自Sacha和nigerenterprise DevOps的Enterprise DevOps博客系列：简介Enterprise DevOps：我不会从这里开始：了解您的DevOps起点Enterprise DevOps：Context is king Enterprise DevOps:Creating一条服务线企业DevOps：关于治理企业DevOps：脊梁很关键（本帖）企业DevOps：转移到自助服务企业DevOps：朱迪亚的人民阵线，还是不要为小东西操心企业DevOps：有意义的度量的13个原则，第1部分企业发展：4度量标准的进一步考虑，第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年离开红帽公司，并于2010年3月创立了CloudBees。Nigel WillieWith在全球最大的金融机构之一从事IT工作超过20年，拥有管理和实施全球转型项目的经验。作为一名开发人员，Nigel最近的职责是向企业。从从他的经验来看，他理解其中的许多挑战和错误；事实上，他声称大部分错误都是他自己犯的。奈杰尔也有幸与许多高技能人士合作，无论是作为同事还是整个行业。他试图分享一些他个人的观察和想法，希望对其他人有价值。奈杰尔提出的任何原则或不是每一条都是伟大的准则，他都是有意的。