【问题标题】:What do you use for Staging / Deployment Artifact Servers?您将什么用于暂存/部署工件服务器?
【发布时间】:2009-05-20 17:48:29
【问题描述】:

我正在考虑编写自己的发布存储服务器,在此之前,我想知道人们使用什么来查看集成而不是创建。

那么您使用什么来存储构建以供内部访问?

我正在寻找一个网络应用程序,它允许我上传工件,然后通过各种标签引用它们,以便我可以按组件或发布工具将它们组合在一起。我还希望通过准备或升级来控制每个构建的访问权限。

我将暂存定义为将构建的工件放置在服务器上供用户社区访问。工件通常是包含应用程序或库 + 文档的 zip 文件。用户社区是开发人员、QA 和服务交付/运营。基本上,创作者、检查者和外部用户。

我们在发布工具中单独发布工件并作为组发布(例如,发布 1.1 包含 foo 1.0.1 和 bar 1.0.7)。根据工件,我们可能想要限制访问。运营部门应该无法访问预发布的版本,我们可能想要跟踪谁下载了有限可用性版本。

所以,我希望找到一个工具,它可以通过良好的可扩展设计完成我想要的大部分工作,这样我就可以添加我没有的东西。

有人知道用于管理构建后构建的好工具吗?

示例可能是:

  • 快速构建/快速构建
  • 团队锻造
  • 打造锻造
  • Jira 和汇合作为一组
  • sonatype nexus
  • 自家种植
  • SVN 存储库使用分支来提升来自 dev->Qa->GA 的构建

【问题讨论】:

    标签: build continuous-integration release deployment staging


    【解决方案1】:

    彼得,

    由于您没有得到很多答案,我会让您知道 AnthillPro 我工作的开发者 Urbancode。

    好的,免责声明,AnthillPro 旨在为您所讨论的广大受众提供服务 - 开发人员、检查人员和操作人员。与您列出的工具相比,AnthillPro 类似于 BuildForge(我们的主要竞争对手)或具有紧密集成的工件存储库(如 nexus)的快速构建。因此构建运行,您可以在一个漂亮的 web ui 中查看构建的结果 - 以及构建工件。具有正确权限的用户可以运行辅助流程,例如针对先前构建的部署或测试 - 以及来自所选构建的工件。

    目标是管理从创建到各种测试工具和部署环境再到发布到生产的整个构建生命周期。它不是一个讨厌的大套件,相反,我们与 Subversion 和 Jira 等工具集成,以确保每个版本都有源和问题单更改清单。

    您的发布包可以很好地映射到 AnthillPro 的内置依赖系统。我们经常看到客户创建的虚拟项目只需要很少或不需要源代码,而是将组件关联或打包到发布包中。

    AnthillPro 可能无法满足您的要求,一般来说,我们会允许操作人员查看预发布版本。但是,您可以通过未标记为“预发布”的任何构建的操作添加将立即失败/阻止尝试发布的规则。 AnthillPro 的状态系统允许团队使用自定义标记标记构建,例如“在 QA”或“已批准发布”。结合有关运行工作流程的规则,这应该可以为您提供所需的控制。如果某些项目特别敏感,您只需使用基于角色的安全性来锁定它们。

    希望这能让你有所了解。

    -- 埃里克

    【讨论】:

    • 谢谢。现在,我有一组松散耦合的应用程序来管理我的项目和发布信息。我有用于问题跟踪的 jira、用于构建的 hudson、用于源代码控制的 svn 和 fisheye 以及用于 maven 存储库管理的 nexus。我希望能找到另一个松散的服务器。虽然,我也在关注蚂蚁山和 lunt build/quick build。所以,我去看看。
    【解决方案2】:

    我的选择是

    构建自动化系统,例如 AntHill、QuickBuild、TeamForge、BuildForge

    • 文件服务器
    • 源代码控制服务器
    • maven 存储库管理器(nexus、archiva)

    我的目标是

    • 按多个标准(工件类型、发布工具、阶段/阶段)进行组构建
    • 从 dev 升级构建 -> qa -> 发布
    • 为开发构建、qa 就绪构建、生产就绪构建提供访问控制

    我将关注源代码控制作为文件服务器(使用 svn)或 maven repos 管理器作为使用 nexus 的文件服务器。理据如下:

    • 尽量减少工作量
    • 最小化成本
    • 使用我可以在需要时轻松扩展的东西(因为我确信我的需求会发生变化)。
    • maven 的使用正在增长,最终将成为这里的主要构建技术。

    感谢您的信息。

    【讨论】:

      猜你喜欢
      • 2011-04-09
      • 1970-01-01
      • 1970-01-01
      • 2010-11-01
      • 1970-01-01
      • 2012-08-17
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多