DevOps工具链集成可为以企业为中心的创新实现端到端的通信和协作。但是，正在扩展其DevOps实施的组织发现他们的工具链庞大、笨拙且脱节。这个瓶颈应该在您的企业DevOps转型之旅中尽早消除。幸运的是，您可以在不改变整个工具生态系统的情况下确保您的团队与其工具之间的协作与合作。关键是集成您的工具，以便它们可以共享数据信息并使工作可见，但不会改变人们使用每种工具的方式。许多工具都具有内置集成功能，可让您直接与其他工具共享数据。但是，如果不存在此类集成，则可以将它们集成，以便组织和共享信息。DevOps协作DevOps的主要宗旨是打破孤岛，消除孤岛，并组建团队，配备交付软件所需的一切：开发功能，将其部署到生产环境，并在保证高质量和高可用性的情况下进行维护。随着许多组织在DevOps中不断发展，并且针对DevOps市场的工具不断增长，发现团队使用不同工具并肩工作的情况并不少见。每个团队管理自己的管道，维护自己的积压工作，并使用自己的测试工具、部署工具和监控工具。对于许多团队来说，这很好。其他团队是否使用替代产品对他们来说并不重要，只要每个团队都使用他们认为最能满足他们需求的工具即可。它为什么如此重要？虽然每个团队都可以独立运作，但团队成员必须经常与其他团队整合。当一个团队提供由另一个团队使用的服务时，并不总是可以创建一个跨职能的端到端团队来涵盖从服务后端到前端用户界面的所有内容。这两个团队将需要同步他们的工作并能够共享资产和信息。例如，如果消费者团队发现无法在现场修复的服务缺陷，则必须记录该缺陷。如果两个团队使用不同的缺陷跟踪系统，共享这些资产可能是一个挑战。一方面，缺陷需要记录在提供商的系统中，以便他们知道并可以修复它。如果消费者团队没有提供者系统的登录权限，甚至没有访问服务器的权限，则无法记录错误，也无法解决错误。在这种情况下，团队继续依赖电子邮件和其他不适合该目的的无效协作工具。在改进和发展DevOps实践的同时，组织有时会遇到这样的情况：一个团队针对同一件事使用多种工具。测试工程师通常使用一种工具来管理他们的积压工作和任务，而开发人员则使用另一种工具。这通常是组织历史的产物，这些组织明确区分了QA和开发团队——瀑布式开发的有力指标——现在将他们的人员整合到同一个团队中。然而，各种专家继续使用他们过去使用过的工具。这导致了团队内部沟通受阻的情况。问题的规模在2018年BizTechInsights对191名技术影响者和决策者的调查中，BizTechInsights报告称，40%的受访者表示他们当前的应用程序交付管理解决方案未与其他系统集成。这阻碍了DevOps的工作，DevOps致力于识别和消除交付管道中的瓶颈。这些组织指出了最大的瓶颈。在采用应用程序交付管理解决方案的组织中，38%的组织对其不满意。只有21%的人表示他们当前的系统足以满足他们的需求。然而，好消息是这些组织认识到这是一个问题并愿意为此做点什么。所以，你可以做什么？连接工具集的简单方法一个简单的解决方案是选择一组工具并在整个组织中实施它们。每个人都必须使用相同的生命周期管理工具，相同的功能测试、性能测试和安全测试工具，相同的部署自动化工具等。但那是天真的，用一套新工具替换现有工具的成本令人望而却步，因为：许多组织仍在为他们拥有的工具支付许可证和支持费用。无法保证他们会因提前终止合同而获得退款。他们最终会为现有软件和新软件付费。将现有工具的工作与现有DevOps管道断开连接并用新软件替换它们可能会在时间和金钱上出乎意料地昂贵。与等待团队重新设计他们的管道相比，客户对获得软件更新更感兴趣。DevOps团队应该专注于为客户提供价值。随着团队学习新生态系统的方式，引入新工具通常意味着引入新的错误和瓶颈。即使选择了一组工具，也不能保证这些工具将共享信息并为团队提供他们跟踪投资、管理积压工作和解决问题所需的洞察力。如果您要从头开始组建新组织，则此方法可能会奏效。但这种情况多久发生一次？大多数迁移到DevOps的大型组织在工具、流程和程序方面都有悠久的历史和投资。这些只能逐渐改变。创建相互关联和包容性系统的更好方法是让团队选择最适合他们的工具。如果他们选择与组织结盟，甚至在两个紧密合作的团队之间做出选择，那么现在正是这样做的好时机。但他们应该谨慎行事，牢记重新设计流程和程序的潜在成本。理想情况下，您的团队应该选择已经集成并且可以相互通信的工具。但这很少发生。相反，引入一个集成的、相互关联但松散耦合的DevOps工具集，通过提供必要的端到端通信和协作渠道并与团队选择的工具集成来增加价值。这种方法有几个优点：集成工具集通常作为基于云的服务提供。没有设置成本，没有基础设施成本，并且可以很容易地使用该工具来招募新的团队成员并随着系统使用量的增长对他们进行培训。这些工具通常预先配置了所有必需的集成。连接工具集中的工具可以与您的团队已经使用的工具集成。他们不会强制改变组织团队使用工具的方式。连接的工具集也是可扩展的，因此您可以通过开放API将它们与任何第三方甚至自定义工具集成。如果该工具更适合团队，他们还可以替换团队现有的工具。例如，如果一个团队对其现有的生命周期管理工具不满意，或者根本不使用它，集成工具集将包括一个为企业DevOps团队设计和配置的生命周期管理工具。随着业务的增长，您可以根据需要换入和换出工具，这也可以保护您免受供应商锁定。他们使整个DevOps管道自动化，同时汇总来自整个生态系统的数据和见解，将它们呈现在易于使用的仪表板上，供所有利益相关者查看。开发人员可以查看其管道的状态，测试人员可以查看正在运行的测试，主管可以跟踪投资组合的整体状态等等，而无需中断现有流程。有可用的框架来帮助组织从遗留软件交付方法过渡到通过DevOps的敏捷、持续交付。企业范围。可扩展敏捷框架(SAFe)可能是最著名的。连接和集成工具集通常支持一个或多个开箱即用的框架。–请注意，最好先选择框架再选择工具，而不是根据您的工具选择框架。选择支持框架的互连集成工具集，该框架将在未来几年为您的组织提供支持。结论团队需要有自主权来决定最适合他们的工具集。同时，团队需要相互协作，如果他们选择的工具没有紧密集成，就会阻碍团队内部和团队之间的沟通渠道。最有效的解决方案是让团队选择自己的工具，同时采用连接的DevOps工具集，提供必要的端到端通信和协作渠道，并与团队已经使用的工具集成。每个团队决定自己喜欢的工作方式，而它生成的信息会自动与其他团队和高级经理共享。组织可以确保每个团队都为最关键和战略性的投资赋予正确的优先级，并获得对每个项目的状态和进度的可见性，而不管使用的是什么工具。正如文章所说，每个团队使用不同的工具是很常见的。工具链之间的集成可以帮助我们实现端到端的通信和协作。我们现在使用的DevOps工具链有哪些？在管道方面，我们会使用Jira+GitLab+Jenkins+SonarQube+Nexus/Artifactory+Docker+Kubernetes等。
