SAAS 工作流程的版本控制

Question

如果这已经被涵盖了，我很抱歉，但我可以诚实地说，我已经花了至少 3 天的时间试图提出一个版本控制解决方案，而我的头快要爆炸了。

我也浏览了一下颠覆书，但还是很困惑。

基本上我有一个一直在稳定增长的 SAAS 应用程序。目前，实际上只有 1 名开发人员（我）在开发该应用程序，但如果人们对它的兴趣持续存在，我可能不得不开始招聘。

该应用程序是用 PHP 编写的，使用 MySQL 数据库，并托管在 bog 标准 LAMP 堆栈上。

目前我的开发机器上安装了 GIT，但是我缺乏理解意味着我的提交是不规则的并且通常是不相关的，并且我遇到了它不跟踪目录更改的问题。

我主要关心的是部署到我们的生产服务器。我们的每个客户都有自己的应用程序文件夹和数据库。

目前，当我们运行更新时，我们必须编写一个自定义更新脚本：

1.Duplicates clients installation into a backup folder
2.Removes the live installation folder
3.Copies the new updated installation folder
4.Copies the users config files from the backup to the live install
5.Tells the operator to make the changes to the users database using a third party app
6.Cleans up.

5 个用户很无聊，但现在我们接近 50 个，这绝对是一场噩梦。

为了使事情变得复杂（并且更安全），每个安装文件夹都包含唯一的数据库设置，这意味着数据库架构只能从该应用程序内部更新。

我一直在考虑建立一个 gitorious 服务器，但我想在挖掘之前寻求一些关于如何继续的建议我自己更深了。

谢谢

Answer 1

也许您可以将应用程序文件保存在用户主目录之外的单独目录中，并在每个用户目录中创建一个指向您的应用程序的符号链接？示例：

ln -s /var/myapp/publicfiles /home/someuser/lib

这样您只需更新代码一次，然后更新每个用户的架构。 publicfiles 目录可以从 git 存储库更新，因此不需要手动复制文件。

Answer 2

对于源代码

如果每个客户端都有不同的配置，并且源文件可能略有不同，您可能需要为每个客户端保留一个单独的 git 存储库，并使用 rebase 从主存储库引入更改。

即，在服务器上有一个目录，保存主存储库（一个裸 git 存储库）。您将更改推送到此主存储库中，然后为每个客户端执行rebase操作。

在每个客户端中，您可以签入其他文件，或更改现有文件。变基的工作方式是撤消本地更改，从主服务器中提取所有更改，然后重新应用本地更改。因此本质上，本地更改/配置会覆盖主配置（通用配置）。

• 注意：如果您可以将每个客户端文件与源树的其余部分分开，则可以使用 Kaivosukeltaja 的符号链接方法。但是，您可能仍然希望对这些每个客户端文件进行版本控制，除非它们以某种方式由应用程序本身进行管理。

对于数据库

您可能想要使用某种类似于 Rails（也可能是其他）的迁移文件。在源代码树中，有一个迁移文件目录（可能是 SQL 命令），用于对数据库进行必要的更改（最好同时拥有“向前迁移”和“向后迁移”文件）。

原则上，您可以使用 post-rebase 挂钩来自动运行脚本并应用新的迁移脚本来更新数据库。在实践中，我会对客户数据更加小心。

Answer 3

我认为你的问题是你拥有的部署数量。这就是造成最大噩梦的原因。然而，这种形式仍然是可以管理的。基本上，您想要做的是：

1. 为每个部署克隆 git 存储库 对
2. 每个部署进行任何自定义编辑
3. 对于每个软件升级，您将遍历每个部署并合并来自默认（主）存储库的更改。

这应该合并更改，而不会弄乱应用程序中的任何内容。唯一的变化是编写一个脚本，可以在部署新代码后执行数据库升级/迁移。