8

我正在研究 Python 应用程序如何也可以使用 CI 管道，但我不确定如何创建标准工作流。

Jenkins 用于做初始存储库克隆，然后启动 tox。基本上这是 maven 和/或 msbuild 将获取依赖包并构建.... tox 通过 pip 执行的操作，所以在这里一切都很好。

但现在对于令人困惑的部分，管道的最后一部分是创建和上传包。开发人员可能会将创建的包上传到本地 pip 存储库，但也可能会创建一个部署包。在这种情况下，它需要是一个包含应用程序 virtualenv 的 RPM。我已经使用 rpmvenev 手动制作了一个，但不管它是如何制作的，如何将这样的步骤添加到 tox 配置中？如果是 rpmvenv，它会创建自己的 virtualenv，可以说是一个自包含的命令。

4

1 回答 1

2

我喜欢用 Unix 哲学来解决这个问题。拥有一个工具可以很好地完成一件事，然后将其他工具组合在一起。Tox 是专门为在一堆不同的 python 环境中运行你的测试而构建的，所以用它来为你构建一个 deb / rpm / etc 我觉得有点滥用这个工具。使用 tox 来运行所有测试可能更容易，然后根据结果在管道处理中为刚刚测试的内容构建一个包的另一个步骤。

在撰写本文时，Jenkins 2.x 似乎是相当新的版本，它在构建管道方面似乎要好得多。BuildBot 正在进行大量的开发，并且已经相当容易为此构建良好的管道。

我们在我的工作中所做的是

  • AWS 中的 Buildbot，它在 PR 上接收来自 Github 的推送通知
  • 这会启动一个 docker 容器，该容器会引入当前代码并运行 Tox（py.test、flake8 以及量角器和 jasmine 测试）
  • 如果 tox 步骤恢复正常，请启动不同的 docker 容器以构建 deb 包
  • 将该 deb 包推送到 S3 并让Salt处理告诉这些机器更新

该 deb 包也可以作为构建工件使用，类似于 Jenkins 1.x 所做的。一旦我们准备好进行登台，我们只需将该包手动升级到登台 debian 存储库。同上滚动它来刺激。

我发现对所有这些有用的工具：

  • Buildbot因为它在 Python 中，因此我们更容易使用，但 Jenkins 也可以正常工作。无论如何，这是整个管道的控制器
  • Docker，因为每个构建都应该与其他构建完全隔离
  • Tox 光荣的测试跑步者来处理所有这些细节
  • fpm构建包。RPM、DEB、tar.gz 等等。非常可配置且易于编写脚本。
  • Aptly使管理 debian 存储库变得容易，特别是将它们推到 S3。
于 2016-05-04T23:28:55.593 回答