介绍

在我目前的组织中，我们有许多台式机和Web应用程序在某个时刻相互融合。当照顾较旧的应用程序或者创建新的应用程序时，很难记住哪个系统依赖于其他系统才能工作。我不是在谈论诸如DLL和图像之类的软件依赖关系，而是在谈论整个系统，例如依赖于HR系统的Finance系统等。

我的问题

跟踪整个系统如何依赖另一个系统的最佳方法是哪一种？

答案可以建议执行上述操作的方法，软件包或者文档编制技术。

在我的特定情况下，"许多"表示十几个服务器上有20多个Web和桌面应用程序。

解决方案

我要说的是在建筑设计文档中清楚地说明这一点。有一些很好的工具，例如Enterprise Architect。使用此工具，我们可以使用UML标准创建图表，以清晰直观的方式描述这些依赖关系。

最好的信息来源通常是在Config文件中找到的。通常，它具有连接字符串，Web服务URL等，这些将对外部依赖项有一个很好的了解。

另一种技术是通过使用概要分析或者跟踪并应用过滤器，我们可以轻松跟踪任何外部调用。在大多数情况下，依赖关系在数据库层中，检查链接服务器并跟踪其依赖关系可以挖掘大量信息。

我不确定是否有任何自动方式来获取此信息，尤其是在系统位于多个平台上的情况下。要记录所有这些，将需要大量的手工工作。

听起来像是对企业发现的工作，它是尽可能自动化的。根据组织规模和环境，有不同的解决方案。对于大环境，无论如何都将需要CMDB(配置管理数据库)。诸如HP Universal CMDB之类的产品可以发现和跟踪大规模环境中的依赖关系。

例如。它可以发现SAP系统及其相关数据库与运行分布式系统的主机之间的关系，并向我们显示相关性。更重要的是，如果对实际环境进行了一些未经授权的更改，它可以警告我们。

因此，答案取决于我们认为的"很多"。

这是一个好问题-似乎我们每次都为此而苦苦挣扎。

过去一年左右的时间里，我们试图在两件事上保持"冷酷"：

• 自动化-如果我们将其自动化并经常进行构建/部署，则自动化过程通常会在大多数情况下使事情变得正确(配置设置等)
• Wiki，Wiki，Wiki-我们努力保持团队和项目Wiki的最新状态。

好奇地看到其他回应。

这是我们在Tideway Systems上生产的那种应用程序，许多大型组织正将其用于此目的。我们可以使用该产品发现自己的资产，并使用建模功能来描述业务应用程序(通常由多个软件和跨度服务器组成)。

听起来我们有资格使用免费的Foundation社区版，只需下载并签出即可在多达30台服务器上使用。然后，请告诉我们想法！

免责声明：我在Tideway负责开发小组。该产品是非常酷的IMO，尽管我自己还没有直接写过它：)

逐一关闭每台计算机，然后看看有什么坏处。

认真地说，这个问题没有简单的答案。使用一组系统，我们可以创建一个显示基本依赖关系的图，但是除非我们对依赖关系有一个概念，否则它没有太多意义。通常，目标是确定更改另一个系统时需要"重新验证"的内容，而不是可以随机关闭的计算机。但是，这类信息需要大量细节，一开始很难积累。

所有这些最终最终会导致系统领先于自动化。我们将永远找不到能够满足需求的收缩包装自动化工具。另一方面，必要的细节太多了，任何可以处理一半甚至三分之一工作量的东西都是有价值的。

系统依赖关系映射是一回事。
真正的环境挑战是真正的环境设置，uid，密码，模拟设置，数据库名称和其他数据，这些数据会从开发到质量检查再到从生产到生产都发生变化。

谁存储/记住所有这些？

开发人员不知道其应用程序将驻留在哪个生产服务器上。
他仅记录开发数据库的名称，uid，pwd的名称，并描述他的数据库表，conn字符串等。

将其检入代码存储库并迁移到QA环境后，用适当的值更新这些配置文件所需的数据的保管人是谁？

同样，当迁移到质量检查和UAT时，谁呢？

谁负责将需要更改的内容告知下一个迁移组？

在我的公司中，这是让我们最头疼的原因。等到内部变更控制流程批准它并创建迁移请求以将应用程序迁移到生产环境时，只需要一个配置设置就可以了，这会破坏整个实现，并且一直在发生，因为没有明确的责任划分(在我看来)。

除了责任，我认为这是此信息的中央存储库。

IE。一个存储所有项目/应用程序的所有配置设置的系统，根据"角色"，我们可以/看不到实际值。

开发人员完成其构建，并在"系统"中创建迁移请求。
质量检查人员会收到有关构建##准备就绪的通知。
质量检查人员登录"系统"并检索迁移说明。
现在他们清楚地知道需要做什么，并且开始进行代码检出和迁移过程。

重复进行UAT并最终生产。

当有人构建此迁移系统时，请告诉我，因为那会帮助很多人。

也许我会自己建造它...谁想签约我？