devops 经验
Matt Callanan六年来一直在推动敏捷软件开发的界限，最近，当他面临向澳大利亚金融机构提供大型商业系统升级的挑战时，他将这一旅程扩展到了DevOps。 他最近在拉斯维加斯的敏捷开发实践西部会议上的一次演讲中分享了他的经验，该会议的题目是“ DevOps之旅的教训 ”。 在会议召开之前，InfoQ赶上了Matt，以了解有关其在DevOps中的经验的更多信息。
InfoQ：是什么让您对敏捷开发充满热情？
回到2006年，我以开发人员的身份从事大型敏捷项目的工作。 在那之前，我从未体验过敏捷。 我被一群训练有素的XP程序员所吸引，在最初的几周里，这简直让人心碎！ 参与真正聪明的团队并沉浸于他们的文化中，我发现我正在学习很多关于TDD，重构，结对编程和快速反馈的知识，并且与测试人员和业务分析师进行了更紧密的互动，以及许多其他方面的知识。我从未接触过的东西。 结果，这使我非常热情，因为我可以看到我们代码的可维护性以及我们系统的可部署性和可持续性比以前好得多。 那使我变得充满激情，并在那时改变了我的职业生涯。
InfoQ：您的敏捷之旅如何演变为DevOps？
那时，我接触到了使用敏捷实践紧密合作的测试人员和开发人员的高度协作文化。 很快过去了几年，我开始了另一个敏捷项目的工作，这次是围绕供应商产品的安装展开的。 我们必须与一些运维人员在该团队中紧密合作，而这些运维人员并未接触过我们从以前的经验中学到的许多开发实践和敏捷技能。 在那个时候与这些人紧密合作，帮助我意识到他们所做的所有辛勤工作以及他们特定技能所要求的纪律。 与操作人员组成一个高度协作的团队，与系统管理员和DBA一起工作使我意识到，敏捷不仅涉及开发和测试，而且还涉及更多方面。 它与项目生命周期的所有不同方面进行协作。 如果您可以进一步整合协作的想法并开始与运营人员合作，那么他们不仅会从敏捷开发实践中受益，例如减少反馈循环和提高可测试性，而且开发人员也将从运营角度受益，例如挑战保持生产系统可靠运行以及代码中支持该规则所需的纪律。 双方都是双赢。
InfoQ：根据您的经验，您对DevOps的定义是什么？
Patrick Debois在最近的一次采访中表示，DevOps没有一个定义。 对于不同的人来说，这可能意味着不同的事情。 对我而言，归结为协作和自动化。 最终，它涉及在团队中创建协作文化，以便您的开发人员不仅在考虑如何将可分发的程序包分发给运营人员，并希望获得最好的结果。 这是与他们紧密合作，并以一种可以帮助他们并帮助您的方式简化生产过程的点。 关于协作以及通常是自动化的所有内容都是用于协调这些活动的工具，以便您可以将系统保持在可以快速获得反馈并在不同环境中重复进行安装的位置。
InfoQ：在您的西部敏捷开发实践会议上的演讲中，您鼓励人们停止拖延，只是开始使用简单的工具。 您能告诉我们一些您使用过的工具以及为什么选择它们吗？
在配置管理领域，我们采用了自动化的家庭酿造方法，通常今天您可以通过Puppet和Chef完成 。 我们当时做了很多Windows自动化的工作，当时Puppet和Chef不支持它，所以我们所做的就是充分利用现有的东西。 与其说“我们没有任何可以在这一领域帮助我们的工具，让我们放弃自动化”，不如说是将Windows的批处理脚本，Unix的Bash脚本和Groovy脚本结合使用我们的Windows自动化也是如此，因为我们是一家Java商店，团队中有很多Groovy技能。 结果，我们能够将两全其美的方法结合起来，因为Groovy是一种强大的语言，可以在Batch和Java之间使用一半。 它提供了一种比典型的批处理脚本更强大的功能来调用命令行程序（如果您曾经尝试在批处理脚本中编写for循环，那么您就会知道我在说什么！）。 而且，如果您使用Java编写了所有安装自动化代码，则需要对其进行编译，JAR，然后将其包装在具有类路径设置的批处理脚本中。 在目标环境上测试自动化时，所有这些都会使您放慢速度。 使用Groovy，我们可以直接从命令行运行脚本。 基本上，我们采用了家庭酿酒的自动化方法，而这正是我们所拥有的工具所建立的。 我鼓励其他人从现有的东西开始他们的旅程，而不是花六个月的时间在会议上讨论潜在的工具，因为从早期的自动化尝试中学到的教训会带来很多好处。
InfoQ：持续集成和部署如何？
与我们合作的企业拥有一个名为Tableaux的工具。 从本质上讲，它就像Capistrano for Ruby一样，可以将您的部署部署到各种设备上。 它具有一个Web GUI，该GUI提供了部署机制以在远程计算机上运行各种脚本和活动。 我们构建了一系列发行套件（在Tableaux中称为），并捆绑了可以一起运行的不同任务，以建立依赖关系，安装产品并在远程服务器上运行测试。 通过反复试验，我们建立了一组这些任务，可以一起运行以产生一个持续集成的构建，该构建实际上行使了我们的整个操作代码。 我们围绕测试Java代码中与其他系统的自定义接口有很多过程。 我们经常采用敏捷方法来测试代码，并将其应用于我们的操作脚本和安装过程。 我们实施了每晚构建，并找到了自动安装所有组件的方法，这些组件可以使我们快速反馈可能导致我们遇到问题的任何活动。 每天我们都会对自动化进行数十项更改，这些更改中的任何一项与其他脚本一起播放时，都可能引起意想不到的问题。 如果您没有尽快并尽可能多地运行自动化，那么您将在数周或数月内都找不到问题，并且为时已晚。 当您处于需要立即进行部署的关键时刻时，现在不是发现问题的时候。 我们从敏捷开发中借鉴了很多“快速失败，经常失败，反馈是关键”的原则，并将其应用于我们的运营代码。
InfoQ：您似乎已经广泛使用了版本控制，有哪些方法和好处？
版本控制是DevOps带给操作的最重要概念之一，它具有查看更改历史记录，能够跟踪更改历史并查看代码如何更改以及能够进行合并，分支和其他各种开发的能力。对您的操作代码进行活动是真正的收获。 许多运营团队不习惯以这种方式工作，因此这是我们带来的重要实践。 我们将供应商产品存储在Subversion中，这给我们带来的好处是，每当我们收到供应商提供的补丁，更新或更改软件时，我们都会将其提交版本控制，随着时间的流逝，可以看到更改的确切历史供应商，以及我们在什么时间与这些供应商集成。 典型的供应商安装方法是将其手动安装在包装盒上，并将更新更改一个接一个地应用，这样您就不必查看一段时间后发生了什么。 版本控制使您对已应用到环境的更改具有可追溯性和责任感。 它也充当文件服务器，我们的脚本可以从中提取可分发软件包，并且在安装自定义项和各种其他配置的同时，我们还可以看到它们如何受到补丁和更新的影响。
InfoQ：审计追踪是否可以帮助您解决长期的冲突？
能够回顾历史并确切地了解发生了什么变化，真是太好了。 通常，与供应商之间的关系在证明是否已安装补丁，是否以正确的方式安装以及是否应用了正确的版本号方面可能存在一些不确定性。 在这种情况下，确保当您说已应用9号补丁程序并且系统中正在运行9号补丁程序时，这很有用。
InfoQ：您如何发展结对编程的使用，以改善与运营人员的协作？
我们采用的方法是，结对编程不仅是代码开发活动，而且是升级项目中任何活动的活动。 作为我们团队一部分的运维人员将他们的技能从日常工作中带到了支持生产环境的工作中，而开发人员则带来了敏捷开发技能和经过严格测试的代码学科。 我们采用了可以将任何任务配对的方法，例如，开发人员可以与操作中的某人配对以设置F5配置，安装IIS，与DBA进行对话或配置自动消息队列。 同样，对于典型的开发任务，我们会将操作与开发人员配对，以便他们可以了解正在部署的某些代码以及开发中涉及的一些实践，以便他们可以了解一些长期的可持续性，可维护性和测试实践。 我们采用的方法是，我们是一支高度协作的团队，不同的人具有不同的技能，但是任何人都可以从事任何工作，这样，我们就可以在通常不会接触到的领域中提高很多人的技能。
InfoQ：最终，您说的是与向客户交付产品有关，而不是与自动化有关。 采取这种客户看到的方法有什么好处或结果？
这与自动化无关。 自动化是我们非常依赖的东西，但是DevOps的主要宗旨之一就是要更快地实现业务价值，因此，我们看到了很多好处。 在最后一个上线的部署之夜，由于该项目涉及了许多纪律，因此人们一致认为这是运营团队见过的最成功的部署之一。 以前，旧系统上的操作人员几乎每天晚上都在下班后得到支持，以解决应该自动运行的问题或手动工作，但上线后，标注的数量大大减少了。 现在，修补程序通常可以更快地应用，因为旧环境是手动安装的，从而导致环境不同步，人们甚至不敢接触生产。 借助Subversion的历史记录和每晚运行的内部版本来测试安装，我们有信心在进行生产之前进行更改。 最终，我们进行了一次部署过程，整个过程最多需要五天，而一天的时间却不长，因此，由于对部署充满信心，因此使业务运行更加顺畅。
InfoQ：您在家中为该特定项目制作了许多工具，但是现在通过DevOps社区看到的一些令人兴奋的工具是什么？
如果我们又花了点时间，就会意识到我们花了很多时间来自动化配置管理方面的工作，但是现在有Puppet和Chef之类的工具可以为您完成很多繁重的工作。 我一定会考虑评估这些内容并将其作为我们程序的一部分，因为它使我们能够从很多细腻的细节中抽象出来。 我认为企业已经开始看到这些工具的价值，因为围绕安装的许多手动过程可能会经常出现问题。 如今，对于Linux甚至Windows都出现了许多可重用的模板，社区中的人们已经花了很多时间来完成各种工具和技术的安装，他们正在向自己的社区贡献模板。可以快速利用他们所做的工作，并从Puppet Forge或Chef的OpsCode Cookbooks中下载它们，并根据您的环境重复使用和调整它们。
InfoQ：对于没有考虑过旅程的敏捷团队成员或一直在考虑DevOps的人们，您的最终建议是什么？
对我们而言，DevOps旨在进一步推动敏捷发展，并将个人和交互的原则直接应用于宣言中的流程和工具，并将其不仅应用于开发任务，而且应用于项目中的所有其他领域。 您希望尽早推出产品并测试您的假设，因此您需要在开发和测试之后的最后一英里应用敏捷原则。 尽早失败，经常失败并进行协作，因为这不仅是对工具的关注，更是与人有关，并且找到了将反馈循环带到极限的方法。 另外，我推荐DevOps Cafe播客和DevOps Weekly电子邮件通讯 ，这是使自己沉浸在DevOps运动中并保持最新状态的好方法。
在他的演讲中，马特概述了他旅行中的前七课：
- 正确掌握技能
- 尽可能共处一地
- 自动化提供杠杆
- 早期失败，经常失败
- 不需要最新的工具
- 保持自动化选项打开
- 知道何时自动化
有关DevOps的更多信息，Matt保留了其网站上的资源列表 。
关于被访者
devops 经验
754
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
