针对CMS的SCM

Question

我在使用CMS上的软件配置管理（特别是Joomla！）时遇到了所有问题。我正在编写自定义模板，当然还有自定义模块和组件。这些网站和应用程序是针对客户的，而不是内部的。

我想实际版本的站点的配置，它的模板和组件不仅仅是代码，因为我希望它是准备斜坡上升的修正，或转让给他人，尽快。现在，这意味着存储一个完整的Joomla！为SVN中的每个站点安装，包括组件和模板的安装版本，以及存储实际的数据库导出。对于组件，我还保留了代码的“打包”版本（见下文）。我通常不会打扰模板，因为您可以将它放入Joomla！安装并运行。

我目前正在辩论的这个设置的问题是在自定义组件开发中。在Joomla！ （和大多数其他CMS）扩展通常使用Web安装程序进行部署 - 由于需要更改数据库，因此您不能（至少在最初）将文件放在某个文件夹中。 Joomla！安装程序系统通过安装和卸载挂钩提供数据库和文件迁移，因此它是一个非常合理的部署系统。 1）直接在安装的组件上工作，添加和更改文件，然后手动将它们复制到组件的打包版本，或者2）使用打包的组件并使用安装程序以实际查看结果。这个选项通常需要很长的时间，但它确实具有保持代码“可释放”的优点，尤其是在数据库迁移方面。

无论哪种情况，在签入之前，这些更改都会被复制到这两个版本的文件中，并且重复对我来说似乎是一种嗅觉。

那么，有没有其他人这样做？有更好的选择吗？

Answer 1

“1 /”应该是“种”的路要走

当你有字的“包装”，这意味着你没有一个版本，但两个“组件”（组文件）

• 一个“发展”的成分：相当大的，与每一个文件，你需要
• 一个“DISTRIB”组件：非常小，只有少数的在它的压缩文件。

它涉及：

• 该DISTRIB组分（通过压缩这些文件并将它们存储）
• 自动的方式来复制DISTRIB成分的自动方式来构建和版本（表示压缩的版本的打包版本），解压缩并与测试或生产平台进行同步。

这样一来，你就不是简单的“复制”的变化，但保持一个实际的完整配置的轨道：

• 随时可部署在其他平台上
• 或用于rsynch部署当前包。