资产管理是源代码控制的超集吗？

Question

在规划您的源代码控制解决方案时，您是否考虑了整个资产管理。例如:图像、外部链接、内容、规格和数据？我知道在让源代码管理有效工作方面有足够的努力，但我经常看到还可以进行源代码管理，但对其他相关资产的手动操作。

(补充)这个问题的灵感来自StackOverflow播客#36 https://blog.stackoverflow.com/2009/01/podcast-36/

Answer 1

在内容管理、配置管理、源代码控制和普通的企业控制(即SAS-70、SOX控制)之间有一些界限。

这两者是不同的，没有超集/子集关系。

您拥有一些企业信息，并且拥有处理这些信息的基础架构。

企业信息是数据(而不是处理)；这通常在内容管理器和关系数据库之间进行划分。

• 内容管理是您购买(或扩展)的应用程序。它处理“半结构化”和“非结构化”信息。例如，图像、链接和“内容”。有些人称其为“资产Management".
• RDBMS是您购买的应用程序。它包含结构化信息。

普通的企业控件应该涵盖所有这些“生产”数据--内容和RDBMS。如果他们不这样做，再多的内容管理或RDBMS软件也帮不上忙。

基础架构主要是在处理(而不是数据)。您必须将配置管理作为一项规程来应用。配置管理包括所有的运行时配置参数、设置、文件以及源代码。

源代码控制和配置是企业信息资产处理的一部分。

我建议您关注配置管理--源代码、设置、参数、补丁等。

内容，就像数据库管理中的数据一样，是用户的责任，而不是开发人员的责任。技术人员提供RDBMS或内容管理工具。但技术人员并不对信息的使用负责--最终用户拥有信息--他们可以随心所欲地使用信息。

内容管理(或“资产管理”)将是手动的。您可以为他们购买工具，但用户需要开发自己的流程来使用这些工具。而且它总是看起来像是手动的。

Answer 2

在我工作的地方，我们拥有与项目相关的所有资产，包括源代码控制、内部文档、第三方API文档、代码、DB SQL、内容等。

我们还通过Sharepoint等协作工具为非开发人员提供业务文档，如规范、项目计划(目前还没有项目服务器)。

Answer 3

在我工作的公司，作为开发人员，我们一致认为，在我们的产品生命周期中由不同的人操纵的所有更改都应该托管在版本控制系统中。我和不同的部门讨论了几次，结果总是“听起来不错，但是开发以外的人不能处理版本控制系统”。所以我们没有在源代码控制下的规范等。更糟糕的是，我们有部分代码，例如java-resource- files，这是由非开发人员编辑的，据称他们不能在源代码控制下工作，因此我们被迫签出文件，通过电子邮件将它们发送给翻译人员，这些翻译人员编辑文件，将它们发回，然后我们将结果再次检查到sc中(但可能在此期间已经对其进行了工作:-(和合并)……这实际上是实际发生的事情的简短版本(甚至包括MS-Excel )。

所以，我的回答是‘是的，一切都应该在源代码控制之下’，但只有代码才会这样做。