自动将每个编译存储在github上？

Question

我的代码每天多次由多人（多台机器）编译。我希望每次有人完成编译时，每个编译都会自动上传到我们的Github帐户。基本上，这些编译的拉链通过闪存驱动器或电子邮件或Dropbox（基于许多条件的任意数量的方式）发送到实际硬件。由于zip的名称始终相同，因此有时会在设备上删除旧版本，有时会将其存储在/ old目录中。我想停止丢失旧版本并保留按时间顺序存储的每个版本的中央存储库。 Github似乎是最适合的地方。

我当然可以要求每个用户将他们创建的已完成的zip上传到中心位置，但我希望它是一个自动过程，如果可能的话。那么 - Github是否提供了这样的功能？

Answer 1

  

Github似乎是最佳选择。

不是真的，因为将大型二进制文件放在分布式 repo中（即，在 complete 中克隆的repo）is not a good idea。

要获得特定版本的二进制文件，您必须从GitHub克隆您的“工件”存储库，然后才能选择要部署的正确版本。
随着多次交付，该回购将变得越来越大，使得克隆更长 但是，如果只有一个地方可以部署，那么git fetch只能获得 new 工件（增量更新）。

可是：

• GitHub不提供无限空间（再次，该回购将随着所有交付而迅速增长）
• 清理回购（即删除可能不需要的旧版本的二进制文件）很难。

因此，再次使用GitHub或任何其他DVCS（分布式VCS）进行传送似乎不够。

如果您可以设置像Nexus这样的公共工件存储库，那么您将能够提供所需的二进制数，并且您将能够轻松地清除它们（删除它们）。

Answer 2

Github有一个附加到存储库的文件的概念（但实际上没有存储在存储库中 - 它们存储在s3上）并且有一个api用于将文件上传到它。

您可以将该API称为构建过程的一部分。

如果你有一个持续集成服务器在每次提交后构建你的代码，你应该能够让它在某处存储构建产品，但如果你想将它们存储在GitHub上，你可能必须自己处理集成（而不是在CI服务器的硬盘上）

Answer 3

虽然github非常适合在源代码上进行协作，但它并不适用于管理构建及其工件。您最终可能希望查看提供托管构建和集成环境的Cloudbees等公司，这些公司完全针对源管理之外的工作流程部分。但这些主要针对Java开发，可能适合您的需求，也可能不适合您。

除此之外，如果你真的只想从很多人可以访问的构建中获得大量带时间戳的zip文件，那么一个好的老式FTP服务器是否足以满足你的需求呢？