大多数组织都希望能够快速地从负责IT平台的团队获得反馈。尽管IT对于企业的运作至关重要，但它要远比推动者具有更强大的业务约束力。

事实证明，关键业务应用程序开发的瀑布式方法无法解决该问题。而DevOps是一种旨在得到快速反馈的方法，开发者快速地将代码提供给运营基础设施，这样就可以使IT在问题发生时及时作出响应。

你的DevOps工具多样化了吗？

具有循序渐进、持续集成和交付的DevOps思维模式对于消费者来说非常熟悉，但是在企业环境中进行应用测试和培训时却面临着挑战。在完整的DevOps工具列表工具支撑下，企业不得不转向持续交付的思维方式：定期、快速有效地交付细小变动更易于桌面用户和终端用户接受。

在DevOps部署中，开发者必须非常精通业务，即围绕业务影响力构建项目，而不是构建技术上更有吸引力的项目。即使现在IT平台具有复杂的相互依存关系，操作技术人员也不应该害怕产品的改变。通过合理地管理和工具从正确的地方获取精准信息，细小的改变相比一个完整的大规模升级更加容易处理，而且大规模的版本升级回滚是一个很漫长的问题。

想要获得更好的IT环境，DevOps并无捷径。它需要重复考虑如何管理IT交付，以及一致、强大的流程处理工具。

DevOps工具列表

和混乱的路线相比，DevOps的成功和什么有关呢？当然并不是指其给予了（开发和运营）两个团队对IT完全的控制*。企业需要一整套的流程来完成捕捉业务需求和区分业务需求优先级；对新的或变更的技术进行需求规划；有效测试其性能；提供阶段性代码，并以最可能低的代价和风险实现它。

大型的、长期的项目不得不消逝。IT组织者必须将业务需求分成必要的流程，再将流程分成若干任务，然后审视这些任务，并且识别在IT环境中是否已经有满足那些要求的服务。不需要再让开发人员创建另一个类似的功能——重复使用这些功能以确保支持和负载的可移植性正常。也要关注外部服务，这些服务可以被应用程序接口 (API)调用。为了监控和管理这些API，就需要评估API管理工具，例如Apigee和TIBCO Mashery。

然后，为DevOps选择开发工具。许多开发者已经建立了定制工具包，而不是使用保守的来自微软、IBM和其他供应商的工具包。为了实现开发-运营过程中的个性化控制，他们可能会选择开放系统，例如Ruby on Rails或者Python系统，以及带有版本控制和配置管理的系统，例如Jenkins、Chef和Puppet系统。

由于团队开发的特性，合作管理是关键。这可以体现在一个简单的层面，例如使用线上工具，例如Redbooth(先前的Teambox)或者Basecamp，或者现场工具CAPPM，或者复合工具Clarizen。后面介绍的工具可以允许团队将代码储存在一个单一的地方，这个地方具有文件和外围信息，并且有能力管理项目任务的进程。也有全面的源代码管理（SCM）工具，例如那些来自Serena Software和IBM Rational的软件，同时还有开源工具，例如由elego Software Solutions或者Git开发的DCVS工具。

不要急于通过用户可接受性测试获得代码，也不要急于进入分阶段式操作环境。检查和权衡是非常必要的，这伴随着自动化监控，以确保监控每个流程，采取立即措施时提出问题。对于提供具有自动化和监测的DevOps流程的系统，可以考虑由HashiCorp供应商提供的Altas产品——这是其独家的工具集合，例如Vagrant, Packer等等——Eletric Cloud与其ElectricFlow，或者IBM产品，可以提供Bluemix作为开发、包装和配置的平台。Atlassian是另一家提供自动化测试和配置工具的公司。

DevOps应用程序尽可能地使用虚拟容器。容器能够允许对代码更好的控制和管理，推动开发者向一个更加灵活的微服务模型前进。该领域的领军目前是Docker，但CoreOS Rocket项目也展示出很有潜力，Apache Tomcat 也是个很有力的竞争者，但似乎还不能和Docker齐平。

链接你的DevOps工具链

此时此刻，DevOps仍然还是一个新兴的方法，缺乏总体成熟的市场。而且，对于任何公司来说，不可能通过单一的工具带来完美的DevOps策略。因此要充实你的DevOps工具列表，对每项给定任务提供最佳的平台，并且要着眼于未来。避免使用那些由老旧的SCM系统更名而来，并且将DevOps作为营销策略的工具；并且随着新技术的到来，确保你的开发者和IT操作人员所使用的工具能够灵活适应新技术。

停止寻找综合性的DevOps工具——因为并没有银弹。相反，也要确保你所选择的子弹不会射到你自己的脚

本文转自d1net（转载）