svn - Subversion 作为软件部署

Question

我想在全球范围内部署已编译的软件。

由于我已经有一个用于代码版本控制的 subversion 服务器，因此我打算使用 SVN 进行软件部署。但是由于很多人使用 apt-get 进行软件部署，我想看看使用 SVN over 的优缺点apt-get。

Answer 1

不要将编译后的代码签入 Subversion！对于软件包（RPM 或 .deb）尤其如此。

我所看到的是人们将他们的包存储在 Subversion 中，然后使用 Web-SVN 浏览器指定 URL，或者进行结帐并将包放在他们的本地系统上。我不推荐这个。

原因很简单：编译后的二进制文件占用了大量空间。我们的 RPM 包可能有数百兆字节。每次你将一个提交到 Subversion 时，你的存储库的大小就会增加几百兆字节。在几个版本之后，您的存储库中就有了千兆字节的二进制文件。

为了什么？您不能在 Subversion 中区分二进制文件。您无法查看他们的历史并看到任何有用的信息。而且，二进制文件的保质期很短。在每月发布多次的情况下尤其如此。您最终会得到一个必须维护的臃肿存储库，其中 90% 是无人关心的信息。

然而，人们这样做是因为它很方便。你给某人 Subversion URL，他们可以下载它。大不了。如果你有一个专门的发布服务器，他们可以做同样的事情，而且会更快。而且，您可以删除不再需要的旧版本并节省数千兆字节的空间。

仅仅因为很多人做某事并不意味着你也应该这样做。很多人也吸食海洛因，我也不建议这样做。

你有像Jenkins这样的构建服务器吗？如果这样做，请将已编译的包存储在那里。您可以删除较旧的包（Jenkins 会为您执行此操作），并在源代码和包之间保持连接。

在我工作的一个地方，我们使用Promoted Build Plugin设置了Jenkins 。当我们发布一个版本时，我们会进入 Jenkins 构建，并对其进行推广。促销活动将标记我们的源代码，锁定构建以防止 Jenkins 删除存档的包，并将包发送到我们的 apt-get 服务器。更好的是，我们会用发布号标记构建。您可以进入 Jenkins，找到已发布的构建，查看源代码，下载包，并查看一个构建与下一个构建之间的所有更改。

我们的 Subversion 存储库仅包含源代码，用户可以使用实际的 apt-get 包服务器进行自动包更新。

Answer 2

SVN 包含源代码，而 apt-get 将负责产品的所有安装。通常在使用 SVN 时，您只能获得软件的副本，并且需要自己手动安装。

希望这可以帮助。