GraphGists

引言

有时,尽管我们坚持勤奋和流程,软件似乎仍然是随意发生的。系统通过人员、技能和工具的某种组合悄悄进入我们的生活。结果往往是许多作者编写的大量陌生且不清晰的组件,对整体情况知之甚少。

全面认知的益处

软件如果管理得当,受益于对围绕其创建和消费的生态系统中“活动部分”的广泛认知。实际的人与我们构建的系统互动,我们应该构建更好的模型来跟踪和描述这些系统。

分散的功能与孤立的团队

许多时候,专注于特定职能(如质量保证)的团队拥有可以直接管理与其工作职能相关实体的应用程序和系统,但是!...这些团队缺乏一个能够将其他团队和职能相关的事项关联起来的主系统。通过正确的建模,Neo4j可以解决这个问题。

连接相关事项

通过跟踪系统的各个部分、它们如何连接和交互,以及谁关心这些连接,我们可以更好地理解我们所做更改的影响、关注并受这些更改影响的利益相关者,并且通过可视化,我们可以预测并传达这些影响。

关于模型

zRAOaHp

在此模型中,采用以下类别对密切相关的标签进行分组

节点域

包含的标签

人类

:Audience, :Group, :Organization, :Person, :Role

流程

:CheckIn, :Defect, :Feature, :Iteration, :Release, :Requirement, :Task, :TestCase, :TestSuite, :UserProfile, :UserStory

技术

:AppLayer, :CodeProject, :CodeSolution, :Component, :CssFile, :Database, :DbFunction, :DbTable, :DbSchema, :DbView, :Environment, :File, :JsFile, :LocalizationKey, :Location, :MvcController, :MvcView, :Platform, :Permission, :Service, :Server

知识

:Audience, :Document, :Term, :Publication, :Skill

测试

:Defect, :Environment, :Feature, :Requirement, :TestCase, :TestSuite, :UserProfile, :UserStory

Web

:CssFile, :JsFile, :MvcController, :MvcView

设置

"人类"节点域 - 人员和群组

拥有一份软件构建所在的人员或组织环境的“地图”,可以帮助我们应对寻找问题答案或满足系统更改请求的挑战。当我们需要告知利益相关者对其业务流程的影响时,它也有助于我们的沟通工作。

// Find Node Types in the "Human" Node Domain
MATCH (m) WHERE m:Person OR m:Group OR m:Role OR m:Organization
RETURN m;

"流程"节点域 - 跟踪工作

在此示例中,通过元数据包含在“流程”节点域中的标签用于查找此类节点的实例。

// Find node examples in the "Process" 'Node Domain'
MATCH (nt:NodeType)--(:NodeDomain { name: "Process" })
WITH COLLECT(nt.name) AS processNodeTypes
MATCH (m) WHERE LENGTH(FILTER(lbl IN labels(m) WHERE lbl IN processNodeTypes)) > 0
RETURN m LIMIT 50;

示例:查找连接的系统元素

当准备修改应用程序中的共享代码资产时,可视化资产与系统其他部分的连接会非常有用。例如,考虑一个包含共享样式表的电子商务应用程序,该样式表影响Web界面中的多个视图。一个Cypher查询可以揭示对正在修改的代码的多个依赖关系。

这是Web电子商务应用程序中共享CSS文件的示例。

// CSS to MVC View and MVC Controllers, if present
MATCH (css:CssFile)--(vw:MvcView)
OPTIONAL MATCH (vw)--(ctl:MvcController)
RETURN css, vw, ctl;

示例:对源代码签入进行建模

当源代码被签入时,追踪源代码更新所影响的资产和功能会很有帮助。在大多数系统中,源代码控制本身就是一个孤岛,不提供任何追踪应用程序内功能区域抽象指定的能力。通过在图谱中对代码提交进行建模,您可以建立我们日常使用的工具自然不支持的连接。

// Developer checks in changes
MATCH (dev:Person { name: "Dev, Donna" })
MATCH (global_css:CssFile { name: "Global.css" })
MATCH (details_css:CssFile { name: "ProductDetails.css" })
MERGE (checkin:CheckIn { name: "Change set 2231" })
	ON CREATE SET checkin.description = "CSS fixes for product details"
MERGE (global_css)-[:INCLUDED_IN]->(checkin)
MERGE (details_css)-[:INCLUDED_IN]->(checkin)
MERGE (dev)-[:SUBMITTED { submitDate : "2015-06-13" }]->(checkin)
RETURN dev, global_css, details_css, checkin;

示例:哪些功能受到签入的影响?

通过在Cypher查询中使用一些“跳转”,可以确定对高级功能的可能影响,并且此信息可用于缩小关注项的列表。

// What features did a checkin affect?
MATCH (checkin:CheckIn { name: "Change set 2231" })
MATCH (css_file)-[:INCLUDED_IN]->(checkin)
MATCH (css_file)--(vw:MvcView)
MATCH (vw)-[*1..3]-(feature:Feature)
RETURN DISTINCT checkin, css_file, vw, feature;

示例:QA需要运行哪些测试?

除了受影响的功能(Features),您还可以使用测试套件(Test Suites)与功能(Features)的关联以及测试用例(Test Cases)与测试套件(Test Suites)的关联,来构建给定代码签入需要执行的测试用例列表。

这一点还可以进一步延伸,根据与发布(Release)相关的代码(稍后描述),考虑发布所需测试用例(Test Cases)。

// Data: What tests does QA need to run?
MATCH (checkin:CheckIn { name: "Change set 2231"})
MATCH (css_file)-[:INCLUDED_IN]->(checkin)
MATCH (css_file)--(vw:MvcView)
MATCH (vw)-[*1..3]-(feature:Feature)
MATCH (t_case:TestCase)--(t_suite:TestSuite)-[*1..2]-(feature)
RETURN DISTINCT t_suite.name AS `Test Suite`, t_case.name AS `Test Case`;

示例:将签入与发布关联

通过将签入(Check-ins)与发布(Releases)关联,您可以对发布的更改进行全面分析,包括受影响的功能(Features)。

MATCH (checkin:CheckIn { name: "Change set 2231" })
MATCH (release { name: "Release v1.3" })
MERGE (checkin)-[:INCLUDED_IN]->(release)
RETURN checkin, release;

示例:此发布需要测试什么?

可以从模型中得出关于发布(Release)需要运行哪些测试用例(Test Cases)的结论。

// Data: What needs tested for this release?
MATCH (rel:Release { name: "Release v1.3" })--(checkin:CheckIn)-[*1..4]-(feature:Feature)--(suite:TestSuite)--(testCase:TestCase)
RETURN DISTINCT rel.name AS `Release`, checkin.name AS `Check-In`, suite.name AS `Test Suite`, testCase.name AS `Test Case`;

示例:给定发布计划了什么?

除了预测发布(Release)的测试需求外,还可以对发布内容的“内容”进行高层次的建模。

// What's scheduled for Release v1.3?
MATCH (release_v1_3:Release { name : "Release v1.3" })
OPTIONAL MATCH (release_v1_3)<--(n)
RETURN release_v1_3, n;

示例:给定发布中有哪些内容(来自签入的发布说明)

与发布(Release)相关的签入(Check-ins)的原始视图可以用来编译发布说明,然后发布给利益相关者。

// Data: What's in release v1.3?
MATCH (rel_v1_3:Release { name: "Release v1.3" })
OPTIONAL MATCH (rel_v1_3)--(checkin:CheckIn)
RETURN rel_v1_3.name AS `Release`, checkin.name AS `Check-In`, COALESCE(checkin.description, "No description provided") AS `Description`;

示例:每个环境中存在哪些发布版本?

软件开发团队面临的一个挑战是按环境跟踪版本。如果您只有有限数量的环境可供选择,这一点就更加重要。

第一部分:将发布添加到UAT环境

// Add v1.3 to UAT
MATCH (rel_v1_3:Release { name: "Release v1.3" })
MATCH (uat:Environment { name: "UAT Environment"})
MERGE (rel_v1_3)-[r_1_3:DEPLOYED_IN]->(uat)
RETURN uat, rel_v1_3, r_1_3;

第二部分:按环境检查发布

// Releases in environments
MATCH (rel:Release)--(env:Environment)
RETURN rel, env;
// Data: Releases in environments
MATCH (rel:Release)-[i]-(env:Environment)
RETURN rel.name AS `Version`, TYPE(i) AS `is`, env.name AS `in Environment`;

亲自尝试

亲自执行一些查询,探索上面描述的模型。

结论

通过对软件开发流程中分散的部分进行建模,可以在软件开发过程中更好地理解风险和影响并将其可视化。这可以防止因修复模型可以揭示的意外问题而浪费时间和精力。


创建者:Jeffrey A. Miller - Twitter | Blog | LinkedIn

© . All rights reserved.