python tox，创建 rpm virtualenv，作为 ci 管道的一部分，不确定工作流程中的位置

Question

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

Jenkins是用来做初始的repository clone，然后启动tox。基本上这是 maven 和/或 msbuild 获取依赖包和构建的地方....tox 通过 pip 完成的，所以这里一切都很好。

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

Answer 1

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

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

我们在工作中所做的是

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

该 deb 包也可以作为构建工件使用，类似于 Jenkins 1.x 所做的。一旦我们准备好进行暂存，我们只需将该包手动提升到暂存 debian 仓库。将其滚动到产品中也是如此。

我发现对这一切有用的工具:

• Buildbot因为它是用 Python 编写的，因此我们更容易处理，但 Jenkins 也能正常工作。无论如何，这是整个管道的 Controller
• Docker，因为每个构建都应该与其他所有构建完全隔离
• 让光荣的测试运行者处理所有这些细节
• fpm构建包。 RPM、DEB、tar.gz 等等。高度可配置且易于编写脚本。
• Aptly使管理 debian 存储库变得容易，特别是将它们推送到 S3。