在规划源代码管理解决方案时，是否考虑整个资产管理？例如：图像，外部链接，内容，规格和数据？我知道有足够的力量让源代码控制有效地工作，但我经常看到好的源代码管理，但手动操作其他相关资产。
（新增） 这个问题的灵感来自StackOverflow播客＃36 http://blog.stackoverflow.com/2009/01/podcast-36/
答案 0 :(得分：3)
内容管理，配置管理，源代码控制和普通企业控制（即SAS-70，SOX控件）之间存在一些界限。
两者截然不同，没有超集/子集关系。
您拥有一些企业信息，并且您拥有处理该信息的基础架构。
企业信息是数据（不处理）;这通常在内容管理器和关系数据库之间分开。
内容管理是您购买（或扩展）的应用程序。它处理“半结构化”和“非结构化”信息。例如，图像，链接和“内容”。有些人称之为“资产管理”。
RDBMS是您购买的应用程序。它包含结构化信息。
普通企业控制应涵盖所有这些“生产”数据 - 内容和RDBMS。如果他们不这样做，那么任何数量的内容管理或RDBMS软件都无济于事。
Infrastucture 主要是处理（而不是数据）。您必须将配置管理应用为规则。配置管理包括所有运行时配置参数，设置，文件以及什么不是源代码。
您的源代码控制和您的配置是处理企业信息资产的一部分。
我建议你专注于配置管理 - 源代码，设置，参数，补丁等。
内容与数据库管理中的数据一样，是用户的责任，而不是开发人员的责任。技术人员提供RDBMS或内容管理工具。但技术人员不对信息的使用负责 - 最终用户拥有信息 - 他们可以随意使用。
内容管理（或“资产管理”）将是手动的。您可以购买它们，但用户需要开发自己的工具来使用这些工具。它似乎总是手动的。
答案 1 :(得分：2)
在我工作的地方，我们拥有与源代码管理项目，内部文档，第三方API文档，代码，DB SQL，内容等相关的所有资产，整个shebang。
我们还通过Sharepoint等协作工具为非开发人员提供业务文档，如规范，项目计划（尚无项目服务器）。
答案 2 :(得分：1)
在我正在工作的公司中，我们作为开发人员同意，在产品生命周期中所有变化并由不同人员操纵的一切都应该托管在版本控制系统中。我与不同的部门多次讨论了这个问题，它总是以“听起来不错，但开发人员无法处理版本控制系统”结束。所以我们在源代码管理下没有规范等。更糟糕的是，我们有部分代码，例如java-resource-files由非开发人员编辑，据称他们无法在源代码管理下工作，因此我们被迫检查文件，通过电子邮件发送给翻译人员，编辑文件，发回文件，然后检查文件结果再次成为sc（但在此期间他们可能会对它们进行处理:-(和合并）......这实际上是真实情况的简短版本（即使涉及MS-Excel）。
所以，我的答案是'是的，一切都应该在源代码控制下。'，但除了代码之外什么也不会。