具有依赖包的可重现版本

时间:2012-04-07 17:15:58

标签: continuous-integration go packaging release-management

我正在阅读“如何编写Go代码”教程,我不禁想知道如何设置稳定的工作流程。

Git说,当然,我的代码将处于源代码管理之下。现在我希望能够做到以下几点:

  • 构建我的项目的可执行文件 - 并确保对于给定的Git版本,可执行文件将构建相同的。
  • 为每个提交时激活的项目运行连续构建。我需要确保无论连续构建做什么都可以在我的工作站上重现。
  • 创建我的项目的版本。我需要知道如果我从我的代码的同一个git版本再次执行它,就可以重新创建一个版本。

Go为它提供了“go get”工具 - 但这里是我感到困惑的地方。应该支持这个工具“go get”,设置依赖包的源代码控制仓库。这给了我以下问题:

  1. 我不能将依赖包放在我自己的源代码控制之下。这意味着如果我和我的合作者,或者我和我的持续构建系统之间存在任何环境差异,我们将很难找出这些差异。
  2. 如果网络出现故障,我将无法从头开始构建代码。或者,以不同的方式,我的连续构建系统必须在每次构建版本时都击中所有这些外部服务器。这可能是脆弱的,甚至不是我愿意让外界知道的事情。
  3. Go定义了将包版本与基本语言同步的约定,但不能保证包作者将遵循该约定。如果他们不这样做,一个干净的工作空间将会获得可能被破坏的任意版本。
  4. 如果我依赖的项目被放弃,我可能会失去构建程序的能力。
  5. 我可以通过手动导入依赖项目的代码并且根本不使用“go get”来解决这些问题 - 但是,我正在避免使用专门为此用途设计和推广的语言的工具。

    有什么建议吗?我错过了什么吗?

1 个答案:

答案 0 :(得分:1)

go get只使用分布式版本控制系统源代码的使用。它将使用repo的本地副本。我会尝试在这里解决您的每一个问题。

  1. 您当然可以在本地仓库中进行修改并在那里将其提交给您 想。
  2. go get首先使用它构建的本地存储库,除非你告诉它明确更新。
  3. go get不会吹走它仍然存在的存储库。而且因为所有的来源 go get理解的控制系统是分布式的源控制系统,没有 因为你不能自己保留项目的分支。