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 需要运行哪些测试?

除了受影响的功能之外,您还可以使用测试套件与功能之间的关联以及测试用例与测试套件之间的关联来构建针对给定代码签入需要运行的测试用例列表。

这也可以扩展得更远,将针对发布所需的测试用例考虑进来,这些测试用例基于与发布关联的代码(稍后描述)。

// 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`;

示例:将签入与发布关联

通过将签入与发布关联,您可以对发布所做的更改进行全面分析,包括受影响的功能。

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

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

可以从模型中得出有关针对发布需要运行哪些测试用例的结论。

// 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`;

示例:给定发布中安排了什么?

除了预测针对发布的测试需求之外,还可以对发布的“内容”进行高级概述建模。

// 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;

示例:给定发布中有什么(来自签入的发布说明)

对与发布关联的签入进行原始视图可以允许编译发布说明,然后将其发布给利益相关者。

// 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`;

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

软件开发团队面临的一个挑战是跟踪每个环境的版本。如果要选择的环境数量有限,那么了解这一点就更加至关重要。

第 1 部分:将发布添加到 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;

第 2 部分:按环境查看发布

// 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 | 博客 | 领英