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

发布于 2025-01-10 02:50:04 字数 908 浏览 1 评论 0原文

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

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

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

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

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

  • 静态站点,手动维护。
  • 目前无法从任何中央来源获得二元资产。
  • 资产很少更新。

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

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

I'm maintaining a semi-large web site for my company (a couple hundred pages). This is a static site, with tons of HTML written (i.e., copied & pasted) by hand and binary assets scattered all over the place. These assets include product images, simulation videos, tutorial videos, firmware files, manuals, etc. which change only rarely. Ideally, they would all be stored in one or a few systems where they could be systematically searched and retrieved. Alas, our world isn't ideal and this is not the case.
That's why the previous developer put copies of all these files in the site's file structure along with the code. His workflow was to have a copy of the entire site on his PC to make and test changes, then upload them to the web server over FTP. There was no version control.

When I took over, I wanted to introduce version control, so I put the entire thing in a git repository hosted on Azure DevOps. I made use of LFS for most binary files.
The entire repository is now about 10 GB in size (including the LFS objects).
There is a deployment pipeline which just clones the repo and uploads the entire thing via FTP.

Recently, my company introduced an on premises GitLab installation and I talked to them about migrating the repository there. However, they don't support LFS for now and insist that my workflow is not the way git is meant to be used. Leaving aside the fact that I find their reasoning to be too dogmatic (Large binaries aren't supposed to be in git, LFS notwithstanding. If they are, you're doing it wrong.), I don't dispute that my workflow leaves a lot of room for improvement.

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.

This brings me to my actual question. Given these circumstances:

  • Static site, maintained by hand.
  • Binary assets at this time not available from any central source.
  • The assets are updated only very rarely.

Would it be an improvement to follow the GitLab admin's advice?
Would you foresee any benefits to me as the site maintainer?
If binary assets are no longer part of the repository, is there a way to keep track of asset versions as they relate to repository history?

I'm hoping this question is concrete enough not be a simple matter of opinion.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

梦旅人picnic 2025-01-17 02:50:04

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

实际上,通常的解决方案是将它们放入用于存储二进制文件的工件引用中。 (NexusArtifactory< /a>)

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

部署变成:

  • 从裸存储库中进行 git 恢复(速度很快,因为文件更少,更小)
  • 从工件引用中解压存档(具有正确的树结构)

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.

Actually, the usual solution is to put them in an artifact referential, made to store binaries. (Nexus or Artifactory)

What you are versioning is a pom.xml (for instance) declaring what version of your static asset binaries you need.

The deployment becomes:

  • git restore from a bare repository (quick, because less files, smaller)
  • unzip of an archive from the artifact referential (with the right tree structure)
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文