为什么是artifactory而不是共享文件夹？

在这种情况下，我们在公司中有一个共享文件夹，当我们放置应用程序的安装程序时（两个文件.sh，一个用于bin，另一个用于conf），这是一个手动操作

我们正试图让jenkins自动执行此操作

我必须给出一些论据：如果我们使用artifactory通过http请求从jenkis发送数据来存储数据，那么会有什么好处？我们可以自动将数据放入共享文件夹（如果您能告诉我更多关于最后一个操作的可能性，那将非常好）

---

有什么想法吗？

与共享驱动器相比，使用合适的二进制存储库管理器有很多好处。以下是一些：

• 智能存储。Artifactory使用基于校验和的存储，它比共享驱动器更快、更优化、更通用
• RESTAPI。正如您所提到的，您可以使用RESTAPI放置、搜索、检索和处理工件
• 权限和升级。使用Artifactory，您可以拥有比使用文件系统更灵活的权限。例如，可以使用元数据对工件进行注释（参见下一个项目符号），但不能部署新工件。一旦存储库（谁可以访问哪个存储库）的权限到位，您就可以将工件从一个存储库升级到另一个存储库，从而将工件公开给不同的组。例如，QA团队可以在QA存储库中看到工件，但不能在开发存储库中看到工件。一般观众只能在发布库等中看到工件
• 元数据。这是争论之王，对我来说，愚蠢的存储和人工制品之间最重要的区别。您希望尽可能多地存储有关二进制文件的信息。谁建造的？它是什么时候建成的？使用什么工具？这件文物怎么了？它通过质量保证了吗？为什么它在某个存储库中？谁把它搬到这里来的？等等。基于此元数据，您可以：
  • 对二进制文件做出明智的决定，例如，哪个二进制文件应该升级到生产环境中
  • 跟踪任何给定时间内的任何二进制文件，到生成它的构建，到生成它的源代码，并获取有关它的所有信息
  不用说，所有对元数据的操作（使用它部署文件、在现有文件上设置、检索、通过元数据搜索文件等）都可以通过RESTAPI和Artifactory Jenkins插件完全自动化

---

---

我在，公司在后面，有关详细信息和链接，请参阅。

版本控制？AFAIK Artifactory可以存储一个包的多个版本，而不是一个共享文件夹。@GiulioVian实际上在我们正在处理的用于交付的共享文件夹中，我们有一个文件树项目->组件->版本->（bin.sh+conf.sh），所以我们不讨论包，我们不建议使用人工或共享文件夹来解决依赖关系。任何帮助！我够清楚了吗？