python travis-ci

# 聊聊Python项目里的Travis CI如果你在GitHub上逛过一些Python开源项目经常会看到一个绿色的小图标写着“build passing”或者“build failing”。点进去能看到一堆测试正在自动运行。这背后往往就是Travis CI在干活。他是什么简单说Travis CI是一个持续集成服务。持续集成这个词听起来有点唬人其实概念很朴素。想象一下一个团队在共同装修一套房子。有人铺地板有人刷墙有人装水电。如果每个人都只管自己干自己的最后很可能发现地板铺好了但水管没埋进去或者墙刷完了才发现线路有问题得砸了重来。持续集成就是让大家别等到最后才碰头。每装好一个插座每铺完一块地板都立刻检查一下和别人的工作能不能接得上。在软件开发里这就意味着每次有人往代码库里提交一点改动就自动把代码拉到一个干净的环境里编译、安装依赖、运行测试看看这些新改动有没有把原本能跑的东西搞坏。Travis CI就是专门干这个的。它和GitHub关系特别紧密你只需要在项目里放一个配置文件告诉它你想怎么测试你的Python代码剩下的它就全包了。每当有人发起一个Pull Request或者往主分支合并代码Travis CI就会自动启动一个虚拟的Linux环境按照你的指示跑一遍然后把结果报告给你。他能做什么对于Python项目来说Travis CI能做的事情相当具体也相当实用。最核心的当然是自动运行测试。无论是你用unittest、pytest还是别的什么测试框架写的测试用例Travis CI都能帮你执行。这不仅仅是跑一下那么简单它能确保测试是在一个“干净”的环境里跑的。什么叫干净就是除了你项目声明需要的依赖之外没有别的任何东西。这能避免那种“在我机器上能跑啊”的尴尬——因为很可能你的机器上装着某个全局包而别人没有。除了跑测试它还能帮你做代码质量检查。比如集成pylint或者flake8检查代码风格是否符合规范有没有明显的代码坏味道。这些检查也可以配置成必须通过否则就算构建失败这样就能保证所有贡献上来的代码都保持统一的风格。对于需要打包分发的库Travis CI还能自动执行构建流程。比如运行python setup.py sdist bdist_wheel来生成源码包和wheel包。更进一步它可以配置成只在打标签Tag发布新版本的时候自动把构建好的包上传到PyPI。这样一来发布新版本就变成了一个非常流畅、不容易出错的操作。还有一个挺有用的场景是多版本测试。Python有2.7、3.6、3.7、3.8、3.9这么多版本你的库是不是都能支持在Travis CI里可以轻松配置一个矩阵让它同时在多个Python版本下运行测试。这样就能确保你的代码在不同版本下的兼容性用户用哪个版本都不会出问题。怎么使用用起来其实不复杂关键就在一个叫.travis.yml的配置文件。这个文件需要放在你GitHub仓库的根目录下。配置文件的基本结构很清晰。首先得声明语言对于Python项目就是language: python。然后要指定测试的Python版本比如python: [3.7, 3.8, 3.9]这样Travis CI就会为每个版本都跑一遍测试。接下来是安装依赖的步骤。通常会有两个部分install和before_install。before_install可以用来装一些系统级的依赖比如某些Python包需要C库支持就得先在这里用apt-get装好。install阶段就是安装Python依赖本身了一般会运行pip install -r requirements.txt或者如果你用poetry、pipenv也可以用对应的命令。然后就是运行测试的script阶段。这里放的就是实际执行测试的命令比如pytest或者python -m unittest discover。如果这个命令返回非零状态码Travis CI就会认为构建失败了。配置好之后去Travis CI的官网用GitHub账号登录把你想要集成的仓库开关打开。下次你再往这个仓库推送代码Travis CI就会自动开始工作了。你可以在它的网站上看到实时的构建日志构建完成后也会收到邮件通知。最佳实践用了一段时间后会发现有些做法能让Travis CI用得更顺手。缓存是个好东西。Python安装依赖有时候挺耗时的特别是那些需要编译的包。Travis CI提供了缓存机制可以把pip安装的包缓存起来下次构建的时候直接复用能节省不少时间。配置起来就是在文件里加一段cache: pip。矩阵构建虽然强大但也要用得聪明。除了测试不同Python版本还可以测试不同的依赖组合。比如你的库同时支持Django 2.2和3.1就可以配置一个环境矩阵把Python版本和Django版本组合起来测试。不过要注意矩阵太大会让构建时间变长所以得权衡覆盖面和反馈速度。.travis.yml文件本身也应该纳入版本控制并且保持简洁。有些项目喜欢把复杂的测试脚本都写在这个文件里结果文件变得很长很难维护。更好的做法是把复杂的逻辑写成单独的shell脚本或者Python脚本然后在.travis.yml里只是简单地调用这些脚本。这样逻辑更清晰也方便本地调试。敏感信息一定要保护好。比如上传包到PyPI需要密码这些绝对不能明文写在配置文件里。Travis CI提供了加密环境变量的功能可以在它的网站后台设置然后在构建时以环境变量的形式注入。在配置文件里用$PYPI_PASSWORD这样的形式引用就可以了。最后记得利用好构建状态图标。Travis CI提供了一个小图标可以放在项目的README里。绿色对勾能给用户很大的信心说明这个项目是被认真维护的代码质量有保障。如果图标变红了那就是一个明确的信号告诉维护者需要立刻关注了。和同类技术对比持续集成领域的选择其实不少Travis CI有几个特点让它特别适合开源项目。最直接的对比可能是Jenkins。Jenkins功能极其强大几乎什么都能做但代价是复杂。你需要自己准备服务器自己安装维护自己配置各种插件。对于公司内部项目Jenkins是个不错的选择但对于开源项目维护一套Jenkins实例就太沉重了。Travis CI完全托管不用操心服务器对开源项目还免费这个优势太大了。GitHub自家的GitHub Actions是另一个强有力的竞争者。Actions和GitHub的集成甚至比Travis CI还要紧密毕竟是一家的。它的配置方式是用YAML文件定义工作流概念上很灵活能做的事情也很多。如果项目已经在GitHub上用Actions似乎是个很自然的选择。那为什么还有人用Travis CI呢一个原因是先发优势。Travis CI出现得早很多老项目已经用惯了配置也稳定没有特别强的动力迁移。另一个原因是Travis CI在某些方面更专注。它的配置相对简单直接学习曲线平缓。对于“就是想在推送代码时自动跑个测试”这种常见需求Travis CI的配置可能比Actions更简洁明了。不过客观说GitHub Actions的势头很猛生态也在快速成长。新项目开始的时候确实值得认真考虑一下Actions。它提供的矩阵构建、缓存、多操作系统支持等功能都不弱于Travis CI而且和GitHub的问题、Pull Request等功能的集成可能更深入一些。还有像CircleCI、GitLab CI等其他选择。CircleCI配置方式和Travis CI有点像但免费额度限制多一些。GitLab CI如果你用GitLab托管代码那自然是最佳搭配但GitHub项目用起来就没那么方便了。说到底工具的选择往往不是纯粹的技术决策。团队熟悉什么、项目需要什么、生态圈里流行什么这些因素可能更重要。对于大多数Python开源项目来说无论是Travis CI还是GitHub Actions都能很好地完成任务。关键不是选哪个而是真的用起来让自动化测试成为开发流程中自然的一部分。看到那个绿色的小对勾心里确实会踏实不少。