Python 的“漂亮”持续集成

您可能想查看 Nose 和 the Xunit output plugin。你可以让它运行你的单元测试，并使用这个命令检查覆盖率：

nosetests --with-xunit --enable-cover

如果您想走 Jenkins 路线，或者如果您想使用另一个支持 JUnit 测试报告的 CI 服务器，这将很有帮助。

同样，您可以使用 violations plugin for Jenkins 捕获 pylint 的输出

不知道会不会：Bitten 由编写 Trac 的人制作并与 Trac 集成。 Apache Gump 是 Apache 使用的 CI 工具。它是用 Python 编写的。

我们使用 TeamCity 作为我们的 CI 服务器并使用鼻子作为我们的测试运行程序取得了巨大的成功。 Teamcity plugin for nosetests 为您提供通过/失败计数，失败测试的可读显示（可以通过电子邮件发送）。您甚至可以在堆栈运行时查看测试失败的详细信息。

如果当然支持在多台机器上运行之类的东西，那么它的设置和维护要比 buildbot 简单得多。

Buildbot 的瀑布页面可以大大美化。这是一个很好的例子http://build.chromium.org/buildbot/waterfall/waterfall

Atlassian 的 Bamboo 也绝对值得一试。整个 Atlassian 套件（JIRA、Confluence、FishEye 等）非常可爱。

我想这个线程已经很老了，但这是我对哈德森的看法：

我决定使用 pip 并设置一个 repo（开始工作很痛苦但看起来很漂亮的蛋篮），hudson 自动上传到成功的测试。这是我的粗略和准备好的脚本，可与 hudson 配置执行脚本一起使用，例如：/var/lib/hudson/venv/main/bin/hudson_script.py -w $WORKSPACE -p my.package -v $BUILD_NUMBER，只需放入**/coverage.xml、pylint.txt 和 nosetests.xml 在配置位：

#!/var/lib/hudson/venv/main/bin/python
import os
import re
import subprocess
import logging
import optparse

logging.basicConfig(level=logging.INFO,
                    format='%(asctime)s %(levelname)s %(message)s')

#venvDir = "/var/lib/hudson/venv/main/bin/"

UPLOAD_REPO = "http://ldndev01:3442"

def call_command(command, cwd, ignore_error_code=False):
    try:
        logging.info("Running: %s" % command)
        status = subprocess.call(command, cwd=cwd, shell=True)
        if not ignore_error_code and status != 0:
            raise Exception("Last command failed")

        return status

    except:
        logging.exception("Could not run command %s" % command)
        raise

def main():
    usage = "usage: %prog [options]"
    parser = optparse.OptionParser(usage)
    parser.add_option("-w", "--workspace", dest="workspace",
                      help="workspace folder for the job")
    parser.add_option("-p", "--package", dest="package",
                      help="the package name i.e., back_office.reconciler")
    parser.add_option("-v", "--build_number", dest="build_number",
                      help="the build number, which will get put at the end of the package version")
    options, args = parser.parse_args()

    if not options.workspace or not options.package:
        raise Exception("Need both args, do --help for info")

    venvDir = options.package + "_venv/"

    #find out if venv is there
    if not os.path.exists(venvDir):
        #make it
        call_command("virtualenv %s --no-site-packages" % venvDir,
                     options.workspace)

    #install the venv/make sure its there plus install the local package
    call_command("%sbin/pip install -e ./ --extra-index %s" % (venvDir, UPLOAD_REPO),
                 options.workspace)

    #make sure pylint, nose and coverage are installed
    call_command("%sbin/pip install nose pylint coverage epydoc" % venvDir,
                 options.workspace)

    #make sure we have an __init__.py
    #this shouldn't be needed if the packages are set up correctly
    #modules = options.package.split(".")
    #if len(modules) > 1: 
    #    call_command("touch '%s/__init__.py'" % modules[0], 
    #                 options.workspace)
    #do the nosetests
    test_status = call_command("%sbin/nosetests %s --with-xunit --with-coverage --cover-package %s --cover-erase" % (venvDir,
                                                                                     options.package.replace(".", "/"),
                                                                                     options.package),
                 options.workspace, True)
    #produce coverage report -i for ignore weird missing file errors
    call_command("%sbin/coverage xml -i" % venvDir,
                 options.workspace)
    #move it so that the code coverage plugin can find it
    call_command("mv coverage.xml %s" % (options.package.replace(".", "/")),
                 options.workspace)
    #run pylint
    call_command("%sbin/pylint --rcfile ~/pylint.rc -f parseable %s > pylint.txt" % (venvDir, 
                                                                                     options.package),
                 options.workspace, True)

    #remove old dists so we only have the newest at the end
    call_command("rm -rfv %s" % (options.workspace + "/dist"),
                 options.workspace)

    #if the build passes upload the result to the egg_basket
    if test_status == 0:
        logging.info("Success - uploading egg")
        upload_bit = "upload -r %s/upload" % UPLOAD_REPO
    else:
        logging.info("Failure - not uploading egg")
        upload_bit = ""

    #create egg
    call_command("%sbin/python setup.py egg_info --tag-build=.0.%s --tag-svn-revision --tag-date sdist %s" % (venvDir,
                                                                                                              options.build_number,
                                                                                                              upload_bit),
                 options.workspace)

    call_command("%sbin/epydoc --html --graph all %s" % (venvDir, options.package),
                 options.workspace)

    logging.info("Complete")

if __name__ == "__main__":
    main()

在部署东西时，您可以执行以下操作：

pip -E /location/of/my/venv/ install my_package==X.Y.Z --extra-index http://my_repo

然后人们可以使用以下方法开发东西：

pip -E /location/of/my/venv/ install -e ./ --extra-index http://my_repo

这些东西假设你每个包都有一个 repo 结构，其中设置了 setup.py 和依赖项，然后你可以检查主干并在其上运行这些东西。

我希望这可以帮助某人。

- - - 更新 - - - - -

我添加了 epydoc，它非常适合 hudson。只需使用 html 文件夹将 javadoc 添加到您的配置中

请注意，这些天 pip 不正确支持 -E 标志，因此您必须单独创建 venv

另一个：Shining Panda 是 python 的托管工具

如果您正在考虑托管 CI 解决方案并进行开源，那么您也应该查看 Travis CI - 它与 GitHub 的集成非常好。虽然它最初是一个 Ruby 工具，但他们在 added Python support 前有一段时间。

信号是另一种选择。您可以了解更多信息并观看视频here。

我会考虑 CircleCi - 它有很好的 Python 支持和非常漂亮的输出。

continuum 的 binstar 现在能够从 github 触发构建，并且可以为 linux、osx 和 windows ( 32 / 64 ) 编译。巧妙的是，它确实允许您将分布和持续集成紧密结合在一起。那是跨越 t 并点缀 I 的整合。站点、工作流程和工具都非常完善，AFAIK conda 是分发复杂 Python 模块的最强大和最 Python 的方式，您需要在其中包装和分发 C/C++/Fotran 库。

我们已经用过很多次了。它很漂亮并且与 Trac 很好地集成在一起，但是如果你有任何非标准的工作流程，定制是一件很痛苦的事情。此外，插件也没有更流行的工具那么多。目前，我们正在评估 Hudson 作为替代品。

检查rultor.com。正如 this article 所解释的，它对每个构建都使用 Docker。多亏了这一点，您可以在 Docker 映像中配置任何您喜欢的内容，包括 Python。

一点免责声明，我实际上必须为想要一种在 git push 上自动测试和部署 any 代码并通过 git notes 管理问题票证的方法的客户构建这样的解决方案。这也导致了我在 AIMS project 上的工作。

人们可以轻松地设置一个具有构建用户的裸节点系统，并通过 make(1)、expect(1)、crontab(1)/systemd.unit(5) 和 incrontab(1) 管理他们的构建。甚至可以更进一步，将 ansible 和 celery 用于带有 gridfs/nfs 文件存储的分布式构建。

虽然，除了 Graybeard UNIX 人员或原理级工程师/架构师之外，我不希望任何人真正走到这一步。因为构建服务器只不过是一种以自动化方式任意执行脚本任务的方式，因此只是一个不错的想法和潜在的学习体验。