python gitlab-ci
# 聊聊Python项目里的GitLab CI
很多团队在用GitLab托管代码，但真正把CI/CD用顺手的其实不多。今天想从一个实际开发者的角度，聊聊Python项目里怎么用好GitLab CI，不是那种官方文档的复述，而是些实际用下来的体会。
它到底是什么东西
GitLab CI是GitLab内置的一套持续集成系统。简单说，就是在你每次推代码到仓库时，自动触发一系列任务——比如跑测试、检查代码风格、打包发布这些。它不需要你额外搭Jenkins之类的独立服务，配置都在项目根目录的一个.gitlab-ci.yml文件里完成。
这东西有意思的地方在于，它把CI/CD变成了代码的一部分。你的构建流程和代码一起被版本管理，修改构建流程就像改代码一样简单，回滚也方便。不像有些老旧的CI系统，配置存在数据库里，改起来提心吊胆的。
实际能解决什么问题
想象一下团队协作的场景：有人提交了新功能代码，但没写测试；有人改了接口，但忘了更新文档；有人引入了新依赖，但没更新requirements.txt。这些情况在项目紧张时经常发生。
GitLab CI能帮你自动发现这些问题。比如每次提交都自动运行单元测试，如果测试失败，合并请求就通不过。还能自动检查代码是否符合PEP8规范，自动生成API文档，甚至自动部署到测试环境。
最实际的好处是，它把人为的“记得要做”变成了机器的“必须做”。代码质量的门槛被固化了，不会因为项目忙就放松标准。
怎么用起来
用GitLab CI的第一步是在项目根目录创建.gitlab-ci.yml文件。这个文件用YAML格式写，结构挺直观的。
一个典型的Python项目配置大概长这样：
stages:-test-lint-deployunit_tests:stage:testimage:python:3.9-slimbefore_script:-pip install-r requirements.txt-pip install pytest pytest-covscript:-pytest--cov=./ tests/--cov-report=xmlcoverage:'/TOTAL.*\s+(\d+%)$/'code_quality:stage:lintimage:python:3.9-slimscript:-pip install black flake8-black--check .-flake8 .这里定义了三个阶段：测试、代码检查、部署。每个任务指定了用哪个Docker镜像（这里用了Python官方镜像），安装哪些依赖，运行什么命令。
实际用的时候，有几个细节值得注意。比如缓存配置，Python项目每次重新安装所有依赖很耗时，可以这样配置缓存：
cache:paths:-.pip-cache/key:$CI_COMMIT_REF_SLUGbefore_script:-pip install--cache-dir=.pip-cache-r requirements.txt这样不同分支的缓存是隔离的，避免互相干扰。还有artifacts配置，可以把测试报告、覆盖率结果这些产物保存下来，在GitLab界面上直接查看。
一些实际用下来的经验
用了几年GitLab CI，有些经验可能对你有用。
首先是镜像选择。很多人直接用python:latest，但这样构建可能今天成功明天失败，因为基础镜像更新了。最好固定具体版本，比如python:3.9.7-slim。slim版本比完整版小很多，拉取更快。
然后是依赖管理。requirements.txt是Python的传统做法，但现在有更好的选择。可以用pipenv或poetry，它们能生成确定的依赖锁文件。在CI里安装时用锁文件，能确保每次安装的版本完全一致。
测试阶段可以拆细些。单元测试跑得快，可以放在前面；集成测试、端到端测试比较慢，可以放在后面，并且只在特定分支（比如develop、master）上运行。这样日常开发提交不会等太久。
环境变量要善用。数据库连接、API密钥这些敏感信息，不要写在配置文件里。GitLab CI提供了安全的变量存储，在项目设置里配置，在流水线中以环境变量的形式使用。
还有一个容易忽略的点：清理工作。CI运行器磁盘空间有限，长时间运行可能会满。可以在after_script里清理临时文件，或者配置自动清理策略。
和其他工具的比较
常有人问，GitLab CI和Jenkins、GitHub Actions比怎么样。
Jenkins功能强大，插件生态丰富，但配置相对复杂，需要单独维护服务器。GitLab CI配置简单，和代码仓库集成紧密，适合想要开箱即用的团队。不过Jenkins在超大规模、复杂流水线场景下可能更灵活。
GitHub Actions是后来者，设计上吸收了很多经验。它的优势在于市场丰富，很多开源项目提供了现成的Action。但GitLab CI和GitLab的其他功能（比如容器仓库、安全扫描）集成更深，如果整个开发生命周期都用GitLab，体验会更连贯。
Travis CI曾经很流行，但现在对开源项目也不免费了。CircleCI配置方式和GitLab CI类似，但它是独立服务。如果已经在用GitLab，没必要再引入另一个CI服务。
选择哪个，主要看团队的工作流。如果重度使用GitLab，用它的CI最自然。如果代码在GitHub，或者需要跨多个代码平台，GitHub Actions或Jenkins可能更合适。
最后想说
工具终究是工具，GitLab CI再好，也只是辅助。真正重要的是团队对质量的重视，对自动化流程的认同。见过有些团队配置了很完善的CI，但总有人找理由绕过检查，或者把测试用例写得毫无意义。
好的CI/CD流程应该像呼吸一样自然，不觉得是负担。它该快的时候快，该严的时候严。该给开发者即时反馈的时候不拖延，该保证质量的时候不妥协。
刚开始用可能会觉得麻烦，配置起来各种问题。但一旦跑顺了，就很难回去了。那种每次提交都自信代码质量有保障的感觉，那种发布时点一下按钮就完成的感觉，是值得花时间去搭建的。
最理想的状态是，新人加入团队，第一次提交代码触发CI，看到自动运行的测试、检查、部署，就能感受到这个团队对工程的认真态度。这种文化上的影响，比工具本身的功能更有价值。