为什么工具集成是困难的
两个工具之间集成的基本问题
工件不是简单的数据
工件也不是复杂的数据
工件不是独立的
API也会带来集成的困难
工具还常常发布新版本
协调工具之间的冲突需要专业的知识
需要对软件各个专业业务的理解
集成两个以上的工具的复杂性
专业的软件工具集成平台
简介软件开发和运营过程中，每个专业团队都选择了最适合自己专业的辅助工具来最大化提升其工作效率，但软件组织级别的效能提升又需要整个软件团队工作在流畅的协作环境中。本文讨论了在集成不同工具时，各种集成方法的优缺点，和工作中可能遇到的潜在问题。
为什么工具集成是困难的软件开发和运营团队使用一个平台完成所有的工作是不可能的。每一个专业团队都选择了最适合自己专业的辅助工具来最大化提升工作效率，无论在测试、开发、业务分析、项目管理等。这些工具都有效的提升了本专业的工作效能，但软件组织级别的整体的状态展示，要素之间的可追溯性，整体效能的进一步提升等需求，在这种相互分割的工具体系，很难达成。
将这些工具集成起来，是一个自然而然的想法，似乎也是个容易的工作，毕竟，大多数工具早已提供了二次开发的API，而且各个专业工具也能集成一些相关的工具。
可是，为什么还有那么多的软件组织，依然必须忍受效率低下，生产率降低，频繁的会议沟通，专业之间的误解，重复的工作，整体项目状态的缺失等问题呢？这些都是软件工具不能良好集成的问题表现。
这些都是因为，在实际工作中，软件工具集成是很难的，软件组织自行完成集成工作，并非看上去那么简单。有些软件组织即便自行开始开发工具集成平台，但他们不久就会面临难以应付的平台支持和更新工作而难以持续。仅仅两个工具之间的集成，在开始时，可能集成所需的编码量并不大。但是，随着需求的扩展，新的需要解决的问题的出现，集成使用场景的增加，最后造就了百万行难以维护的代码，自研和维护费用不断上升。
工具集成不是一个纯技术问题，实际上，它更象一个业务问题。妥善的解决这个问题，也需要对软件各个从业人员自身工作需要的深入、专业的理解，需要了解他们的目标和计划的举措是怎样的。有时还需要在矛盾中取得折中。
解决软件工具集成的问题，首先，需要我们慎重选择集成的基础技术架构，是经由工具的API完成集成，还是集成工具的数据层。
更麻烦的问题是，要提供切实可用的集成，除了要解决这些基本问题之外，还会要求我们必须考虑怎样克服由于工具的不同带来的集成要素之间的各种冲突和矛盾。
两个工具之间集成的基本问题经验表明，依赖数据层集成实现两个工具的集成，是非常脆弱的。使用工具API集成是我们推荐的方式。但是，象我们以上谈到的，解决这个问题，仅仅是个开始。已知的经验表明，最重要的一步是我们对集成的难点要有全面的理解。
首先，我们会从一些“相同”的工件类型，例如缺陷，开始尝试集成工作。然后扩展到更复杂的一些需求。集成的工作量和复杂性立刻就会提升。
工件不是简单的数据我们把集成的内容往往误解为就象简单的数据一样。例如，我们在两个工具中都有缺陷的概念，我们实现这两个工具之间缺陷信息的映像就好了。这是最简单直接的想法。完成这个种集成，我们需要做一下工作有：
l对两个工具功能的基本理解。例如，一个可能是缺陷跟踪工具，另一个可能是开发管理工具。
l理解两个工具的管理对象的模型，识别各个对象数据属性。在软件工具中管理的对象，我们可以称之为工件。（例如工件类型，缺陷，包括缺陷名称，状态，严重性，优先级等）
l理解两个工具提供的API如何实现工件的生成，删除，更新，搜索。
l及时同步工件在两个工具之内的变化。
l避免频繁的API调用，以免造成相关工具性能低下。例如低效的轮询和更新机制。
l避免点对点的集成。这种架构对导致API调用次数倍增。
工件也不是复杂的数据但事实上，工具之间工件的集成，不简简单单就是数据的集成。随着集成工作的深入，我们很快就会发现，这些看似相同的工件，实际上有很多不一致的地方。
l工具在两个工具中的属性是不同的。工件的属性是和工具的专业需求相关的，一个测试者和他们的开发同事对同样的缺陷信息又不同的要求是很正常的。
l即使那些相同的属性，这些属性的值和内容也是不同的。
l冲突难以避免，对备注、附件等属性在不同工具中同时发生的变化。
l客户自定制的工件属性。
我们发现，不同专业工具之间，即使相同工件之间，为了实现可用的集成，都是不容易的。其实，继续工作下去，我们还将面临更多的问题。
工件不是独立的一个工具中的工件不是相互独立，他们之间相互的关系也是工具必须记录的重要内容。
例如：
lEpics被分解为features属性集，然后再被分解为大量的userstories用户故事。
l一些容器经常被用以组织和计划工件
l跟踪和上下文关系是需要管理记录的重要信息。例如，需求、这些需求对应的测试、这些测试发现的缺陷之间的关系
在工具集成时，同样要集成这些关系信息是极其重要的。我们可以想象，不知道缺陷是怎样被发现的，对于修改这个缺陷的开发者来说，是一个不必要的麻烦。
API也会带来集成的困难我们采用API可以获得直接访问工具和其管理工件的能力，而且使用工具听欧冠的API也避免了我们错误的直接操作工件的潜在风险。但是，很快我们会发现，这些API作为用户自行开发集成代码是很不容易的。
首先，这些API首先是工具厂商内部分层开发的需要而产生的，初衷并不是为了用户来使用。所以，这些API常常缺乏文档，并且功能并不完整。例如：
l对于工件属性的操作应该遵循何种规范？有什么状态上下文的要求？操作可能的副作用是什么？这些细节问题，文档中往往不会包含。
lAPI使用可能带来的错误信息和错误处理方式的描述往往也没有。
l极端的用法、可能包含的缺陷、性能问题和优化也不会描述。
l由于没有文档支持，处理这些问题需要依赖频繁的试错。往往工具厂家的技术支持团队也不知道如何解决相关API的问题，而必须联系他们的开发团队。
工具还常常发布新版本更糟糕的是，当工具厂家升级工具是，API也往往会有些改变。我们基于这些API开发的集成系统也会面临很大的挑战，而且这种挑战完全不可控制，这完全依赖于工具厂家自身对变更的管理。线上应用和SaaS应用更新更加频繁而且不可控。
协调工具之间的冲突需要专业的知识象我们之前谈到的，集成的基础技术架构选择是重要的，但只是第一步面临的问题。上面的描述了经由工具的API完成集成将面临的基本问题。而要构建一个切实可用的集成，还会要求我们必须考虑怎样克服由于工具专业领域的不同，带来的集成要素之间的大量的冲突和矛盾。
要解决这些冲突和矛盾，必须要求我们对工具和其使用方式有清晰的理解，首先，我们需要知道：
l在组织中，这些工具被如何使用？
l工具的管理对象是什么？包括工件，项目，用户，工作流程，状态？
l工具管理的标准工件和属性情况？如何对标准工件做定制化工作？
l对工具的状态转换有什么要求？
考虑这些问题之后，更进一步的，我们必须理解各个软件工具和专业工作的一些业务问题。
需要对软件各个专业业务的理解集成的主要问题来自于“不匹配冲突”。不同的工具，设计之初，并没有考虑到集成，解决工具对应专业的技术问题才是首要目标。但各个专业中科UM-D北京治疗白癜风哪里医院最专业