# 聊聊Python与TeamCity的那点事最近在项目里又用上了TeamCity配合Python脚本做了一些自动化构建和部署的工作。有些刚接触持续集成的朋友问起这东西到底怎么用今天就来聊聊Python和TeamCity的那些事儿。这东西到底是什么TeamCity是JetBrains公司出的一款持续集成服务器。说直白点它就是个专门用来“盯着”代码变化的管家。你写完代码往仓库里一推它就开始忙活了——自动下载最新代码、运行测试、打包部署整个过程一气呵成。它和Python的关系有点像咖啡机和咖啡豆。TeamCity是那台机器提供了各种功能和接口Python就是咖啡豆你可以按照自己的口味研磨、调配最后通过TeamCity这台机器做出一杯符合团队口味的“自动化咖啡”。它能帮我们做什么想象一下这样一个场景团队里有五六个开发人员每天都要提交好几次代码。如果没有自动化工具每次提交后都得有人手动去跑测试、检查代码质量、打包部署到测试环境。这活儿枯燥不说还容易出错。TeamCity配合Python脚本就能把这个过程自动化。代码一提交它自动触发一系列操作先检查代码格式是否符合规范比如用black或flake8然后运行单元测试接着做集成测试全部通过后自动打包最后部署到指定环境。更实用的是它还能做很多“智能”判断。比如只有特定分支的代码才部署到生产环境或者当测试覆盖率低于某个阈值时就自动失败并通知负责人。这些逻辑都可以用Python脚本来灵活实现。实际用起来是什么样子在TeamCity里创建一个项目后你会看到“构建配置”这个概念。每个构建配置就像是一个菜谱告诉TeamCity要做什么菜、用什么食材、按什么步骤做。通常一个典型的Python项目构建会包含这么几个步骤第一步是环境准备。TeamCity会创建一个干净的虚拟环境避免不同项目之间的依赖冲突。这一步通常通过命令行调用python -m venv来完成。接着是依赖安装。读取requirements.txt文件把所有需要的包都装好。这里有个小技巧——可以在TeamCity里配置缓存这样下次构建时就不用重复下载了能节省不少时间。然后就是运行各种检查。比如用pytest跑测试套件用mypy做类型检查用pylint看代码质量。这些工具的输出结果TeamCity都能很好地展示出来哪个测试失败了、哪行代码有问题一目了然。如果所有检查都通过了就可以进入打包阶段。对于Python项目可能是打个wheel包也可能是构建Docker镜像具体看项目需求。最后一步是部署。把打包好的成果物推送到目标环境可能是测试服务器也可能是生产环境。这一步通常需要一些权限验证和连接配置用Python脚本处理起来很灵活。整个过程都可以在TeamCity的界面上实时看到进度哪个步骤花了多长时间、有没有出错清清楚楚。一些实践中的经验用了一段时间后发现有些做法能让整个过程更顺畅。首先是配置的管理。早期我们直接把各种配置写在TeamCity的网页界面上后来发现迁移和备份都很麻烦。现在改用Kotlin DSL领域特定语言来定义构建配置把这些配置像代码一样存在仓库里版本控制、代码评审都能用上可靠多了。然后是构建速度的优化。Python项目依赖多每次从头安装很耗时。我们后来把虚拟环境缓存起来只要requirements.txt没变就直接用缓存的环境。测试运行也可以并行化pytest支持多进程运行配合TeamCity的多个构建代理能把原本半小时的测试缩短到几分钟。错误处理也很重要。早期我们的脚本遇到错误就直接退出后来改成了更友好的方式——捕获异常记录详细的错误日志还能自动重试某些临时性故障。比如网络波动导致的下载失败重试两次往往就能成功。通知机制也值得好好设计。除了基本的成功失败通知我们还加了测试覆盖率趋势、构建耗时变化这些指标。当发现测试覆盖率连续下降或者构建时间越来越长时就能及时介入处理而不是等问题积累到不可收拾。和其他工具的比较市面上类似的工具不少Jenkins可能是最出名的一个。Jenkins更灵活插件生态极其丰富几乎什么需求都能找到对应的插件。但这也带来了复杂性配置起来学习曲线比较陡。TeamCity在这方面更“开箱即用”基本功能都内置好了对于大多数项目来说完全够用。GitLab CI是另一个选择。如果你的代码就在GitLab上用它的CI/CD功能确实很方便配置简单集成度高。但如果你用的是GitHub或其他代码托管平台TeamCity的适应性就更强一些。Travis CI和GitHub Actions这类云服务也不错特别是对于开源项目。它们免去了自己维护服务器的麻烦但对于企业内部的私有项目或者有特殊安全要求的场景还是TeamCity这种自托管方案更合适。选择哪个工具其实没有绝对的好坏更多是看团队的具体情况。如果团队规模不大项目也不复杂可能用GitHub Actions就够了如果需要高度定制化的构建流程或者有多个不同技术栈的项目TeamCity的灵活性就更值得考虑。说到底工具只是工具关键还是背后的流程和思想。无论用哪个持续集成的核心都是尽早发现问题、快速反馈、自动化一切能自动化的步骤。把这些想明白了工具的选择反而成了次要问题。