具有大型二进制资产的静态网站的工作流程

Workflow for static website with large binary assets

我正在为我的公司维护一个半大型网站(几百页)。这是一个静态站点,有大量的 HTML 手工编写(即复制和粘贴),二进制资产散布在各处。这些资产包括很少更改的产品图片、模拟视频、教程视频、固件文件、手册等。理想情况下,它们都将存储在一个或几个系统中,以便系统地搜索和检索它们。 las,我们的世界并不理想,事实并非如此。 这就是为什么以前的开发人员将所有这些文件的副本与代码一起放入站点的文件结构中。他的工作流程是在他的 PC 上保存整个站点的副本以进行和测试更改,然后通过 FTP 将它们上传到 Web 服务器。没有版本控制。

当我接手时,我想引入版本控制,所以我把整个东西放在托管在 Azure DevOps 上的 git 存储库中。我对大多数二进制文件使用了 LFS。 整个存储库现在大小约为 10 GB(包括 LFS 对象)。 有一个部署管道,它只是克隆 repo 并通过 FTP.

上传整个东西

最近,我的公司引入了本地 GitLab 安装,我与他们讨论了将存储库迁移到那里的问题。但是,他们现在不支持 LFS,并坚持认为我的工作流程不是 git 的使用方式。撇开我发现他们的推理过于教条的事实不谈(大型二进制文件不应该在 git 中,尽管有 LFS。如果是,那你就做错了。), 我不否认我的工作流程还有很大的改进空间。

他们建议将所有二进制资产放在外部存储解决方案(例如 Sharepoint)中,并在准备新网站时在 GitLab 中部署作业拉取它们。

这让我想到了我的实际问题。鉴于这些情况:

遵循 GitLab 管理员的建议会有所改进吗? 作为站点维护者,您能预见到对我有什么好处吗? 如果二进制资产不再是存储库的一部分,有没有办法跟踪与存储库历史相关的资产版本?

我希望这个问题足够具体,而不是一个简单的意见问题。

They're suggesting to put all of the binary assets in an external storage solution (e.g., Sharepoint) and have a deployment job in GitLab pull them when preparing a new of the web site.

实际上,通常的解决方案是将它们放在工件引用中,用于存储二进制文件。 (Nexus or Artifactory)

您要进行版本控制的是 pom.xml(例如)声明您需要什么版本的静态资产二进制文件。

部署变为:

  • git restore 来自裸仓库(快,因为文件少,更小)
  • 从工件参考中解压缩存档(具有正确的树结构)