介绍
DevOps始于一个或两个小型团队进行持续集成（CI）的过程，它已被企业视为快速向客户提供高质量并以客户为中心的创新的手段。 但是，正在扩大其DevOps实施规模的组织发现他们的工具链很大，很笨拙—并且脱节。在您进行企业DevOps转型的过程中，应尽早消除此瓶颈。 幸运的是，您可以确保团队及其工具之间的协作与合作，而无需更改整个工具生态系统。关键是将您的工具集成在一起，使它们可以共享数据信息并使工作可见，但又不改变人们使用每种工具的方式。许多工具具有内置的集成，可让您直接与其他工具共享数据。但是，如果不存在这样的集成，则可以使它们集成，以便整理和共享信息。
DevOps协作
DevOps的主要宗旨是打破壁垒，消除孤岛，并组建具备交付软件所需的一切能力的团队：开发功能，将其部署到生产中以及确保高质量和高可用性地进行维护。
由于许多组织都以DevOps的方式进行发展，并且针对DevOps市场的工具不断增长，因此发现并肩工作的团队使用不同的工具并不罕见。
每个团队管理自己的管道，维护自己的待办事项，并使用自己的测试工具，部署工具和监视工具。对于许多团队来说，这很好。如果其他团队使用替代产品，只要每个团队使用他们认为最能满足其需求的工具，对他们来说都没有关系。
为什么重要？
尽管每个团队都可以很好地发挥自己的作用，但团队成员必须经常与其他团队整合。当一个团队提供由另一团队使用的服务时，并非总是可以创建一个跨职能的端到端团队，该团队可以覆盖从服务后端到前端用户界面的所有内容。这两个团队将需要同步他们的工作，并能够共享资产和信息。 例如，如果消费者团队发现服务中的缺陷，而又无法现场修复，则必须记录该缺陷。如果两个团队使用不同的缺陷跟踪系统，则共享这些资产将是一个挑战。一方面，该缺陷需要记录在提供商的系统中，以便他们知道并可以修复。如果消费者团队没有提供者系统的登录权限，甚至没有访问服务器的权限，则无法记录缺陷，而且该缺陷也不会得到解决。在这种情况下，团队将继续依靠电子邮件以及其他不适合此目的的效率低下的协作工具。
在改进和发展其DevOps实践的同时，组织有时会遇到这样一个情况，即一个团队针对同一件事使用多个工具。测试工程师通常使用一种工具来管理其积压和任务，而开发人员则使用另一种工具。这通常是组织的历史产物，这些组织在质量保证和开发团队之间进行了清晰的区分-瀑布式开发的有力指标-现在将他们的人员整合到同一团队中。但是，各种专家继续使用他们过去使用的工具。这导致团队内部的沟通都被窒息的情况。
问题的规模
BizTechInsights在2018年对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等等。
