我们最近主持了另一期持续讨论（c9d9）播客，由专家小组成员讨论绘制DevOps旅程的最佳实践。我们的专家小组成员包括：Devo首席执行官Ilmari Kontulainen；充满激情的敏捷和DevOps变革代理人Mirco Hering；数字咨询服务总监Prashant Kelker，信息服务集团公司（Information Services Group Inc.）、认证敏捷项目管理专业人士斯科特·阿巴特（Scott Abate）以及我们自己的安德斯·沃格伦（Anders Wallgren）和萨姆·费尔（Sam Fall）。在这一集中，小组成员讨论了DevOps的三大原则：人、工具和过程，详细介绍了各自的最佳实践和各自面临的挑战。继续读他们要说的话！人物：DevOps和开发团队的文化和角色描述是关于管道和软件交付过程@samueldfell#c9d9#IT的纪律pic.twitter.com/16AQf1WYxq-CloudBees（@electricloud）2016年10月4日，交付不仅发生在开发人员和运营人员之间，而且涉及到他们的合作伙伴之间，根据@prkelker#c9d9pic.twitter.com/goKZfDj6G2-CloudBees（@electriccloud）2016年10月4日，@anders_wallgren-当企业中存在积极消极因素时，尝试进行一个#DevOps转换非常困难#c9d9pic.twitter.com/CKjKwFxGoc-CloudBees（@electricloud）2016年10月4日你需要一个赞助商，但是他们需要知道他们所要求的是让人们踏上"DevOps之旅@MircoHering"c9d9-CloudBees（@electriccloud）2016年10月4日，Wallgren强调了拥有核心团队的重要性："如果你是一家大型企业，你真的负担不起在每个开发团队中都有一两名平台基础设施专家。这就是为什么在大公司里经常会有一个核心团队，他们的工作是运行构建和测试，并保持传送带的运转。"随着创新速度的加快，角色和责任也在发生变化，"孔图莱宁说："我相信IT的作用是基本上向前想一步。开发人员明天将需要哪些工具，并在开发人员需要之前测试并提供这些工具。在很多公司，尤其是大公司中，这种影子IT存在着一个巨大的问题，这是由于IT没有足够快地支持开发组织的需求。这是因为他们做了大量的手工工作，而没有提供这种平台。我认为，在这个意义上，角色和责任正在向更实际的方向转变。"获得高层支持很重要，但这些领导人必须消息灵通，Hering说："我在很多公司与首席信息官进行了交谈，他们说：‘但我们应该使用微服务，我们每天需要部署10次。’我的意思是，看看你的现有情况，编译567个不同的.NET应用程序需要3天时间。我认为关键是你需要那些赞助商，但他们需要知道他们的要求是什么，我认为他们需要让人们踏上征程，而不仅仅是说下个月我们将成为DevOps，Kelker进一步强调了自顶向下支持的必要性："尤其是在敏捷组织中，你需要一个大的赞助人。人们不想有这样的感觉，如果他们开始一些草根运动，它突然被消灭或他们去西北，然后他们必须去东南。必须自上而下。但是，我也看到这些自上而下的运动有时会引起挫折，因为自上而下的运动说的是"去做DevOps，去完成持续的开发"，但是他们忘记了它是在过去30年的遗留环境中被卡住的。所以，除非你和那个SAP人谈过，告诉他怎么做DevOps，那么在他的SAP里，当他有1100万行累加代码时，他害怕每18个月发布一次。"减少"是建立DevOps组织时要考虑的最重要的事情之一，特别是在人员方面，你真的想把DevOps从你的开发团队中分离出来。让他们成为两个截然不同的组织和实体。我看到的一个陷阱是，当您拥有一个属于大型开发组织的DevOps团队时，有时您可能会让一些开发人员在那里动态地调整构建过程或自动化。因此，您将失去构建和构建脚本的一些完整性。让开发操作组织与软件开发人员分开是很重要的。"费尔解释说，通过对camping的一个类比，让人们选择他们自己的工具是很重要的："工具成为使你能够做出改变的平台。如果你试着和某人一起去露营，而他们的心态没有从酒店变成露营地，那么你要确保你拥有的是正确的装备。如果你带他们出去，你有一个悲惨的经历，他们的脸上漏水，他们整晚都很冷，他们不会再这样做了。你必须确保工具工作正常。如果他们有自己喜欢的睡袋，就让他们用吧。别试图告诉他们它和你的帐篷不兼容。确保你至少给了人们一个可以选择什么工具的样子。"技术：基础设施和工具因为mobileapp交付速度太快，领导者更倾向于相信并推动"持续交付"@ScottAbate#c9d9#DevOpspic.twitter.com/A8b02IyH5l-CloudBees（@electricloud）10月4日，2016年的今天，当供应商离开时，您无法控制如何根据@MircoHering c9d9 DevOps交付自己的应用程序pic.twitter.com/16k7lV5f0Q-CloudBees（@electricloud）2016年10月4日，从最基本的软件交付工具和基础设施开始——版本控制、集成，等等|@kontulai#c9d9#DevOpspic.twitter.com/oqPM19maGo-CloudBees（@electricloud）2016年10月4日，从移动角度来看，阿巴特建议使用基于云的弹性工具："关注技术堆栈。我绝对推荐基于云的虚拟工具和弹性工具。我们经常需要在移动设备中快速启动新环境，以测试特定场景。在物理环境中确实很难做到这一点，但使用所有基于云的工具进行虚拟化更容易适应这一点。最好还是呆在云端，确保你有弹性的资源。"Kontulainen为他的开发团队提供自助服务平台："一般来说，从预期的工具开始，我将从最基本的工具开始，比如版本控制、不同工具的访问管理工具、问题跟踪、文档和然后是持续集成的基础知识，并以这样的方式提供它们，以便开发团队可以在他们想要的时候以他们想要的方式使用它们。提供这种开发团队可以利用的自助服务平台是非常有益的。"工具会变得非常复杂，特别是在企业中，Kelker说："我们在企业中处于买方的一方，我们的对话有点不同，我需要一个自带工具的系统集成商吗？或者，我需要得到工具然后把系统集成商带来吗？当系统集成商离开时会发生什么？他带工具了吗？然后我就迷路了。我们说的是一个非常有趣的话题，从两个话题中抽离出来。一个工具专家说-我会把这个平台作为一种服务提供给你。现在你刚从一个工具变成了一个服务，然后你有了一个系统集成商，他本质上是一个服务，但是他带来了所有这些启发，他实际上已经从一个服务变成了一个产品。"Wallgren"DevOps是一种选择软件发布速度的能力。比让你的人员、过程、工具和文化来决定你交付软件的速度要多得多。QA也是一样。QA的目标不是零缺陷发货，目标是提供已知数量的bug。"Hering强调了拥有独立基础设施的重要性和困难："现在我们所处的世界里，我们有更多更容易使用的工具，作为一个组织，我们可能会选择与Amazon合作，拥有一大堆CloudBees工具，但如果我在某个阶段决定这样做别人更好，我也有同样的问题。我已经使用了很多亚马逊提供的很酷的工具，现在我要转移到云上，但是他们没有这些工具，我们接下来要做什么？建立足够的独立的基础设施和平台确实很重要，但很困难。"流程：价值流"价值流映射是DevOps在地面上的表现。"@prkelker#c9d9#DevOps#businesspic.twitter.com/XhUGEwYFBk-CloudBees（@electricloud）10月4日，2016年"如此多的过程就是沟通"@samueldfall on#c9d9#DevOps-CloudBees（@electricloud）2016A实际方法是使用#Scrum-建立一个优先考虑价值流的积压工作|@ScottAbate#c9d9#DevOpspic.twitter.com/xPw1qoxq0X-CloudBees（@electricloud）10月4日，2016年"不要自动化一个糟糕的过程"@anders_wallgren#c9d9#DevOps#ITOps#SoftwareDevelopment-CloudBees（@electricloud）2016年10月4日一旦部署了DevOps，流程应该如何改变就变得很棘手，Kelker说："It部门很容易忙于自己的工作。人们不应该忘记在它之外还有生命。如果IT部门已经部署了DevOps，那么应该看看使用DevOps的业务部门。你现在怎么用这个速度？你应该想快点吗？你现在应该利用这个机会去尝试两件你以前不能做的新事情吗？你应该做功能测试还是A/B测试？这也是一个变化。每个人都在旅途中，如果有人不在旅途中，带他们一起去，因为你可能会忘记某个重要的人，比如那些做预算的人。"Fall举了一个例子，说明了HPE如何利用聊天来帮助改善他们的沟通过程