以下是我对您的清单的看法。您可以实现一定范围的自动化，而我将尝试提供一个合理的起点，然后提供一些提示，告诉您如何进一步发展。

---

没有CD的CI

采用这一部分应该已经摆脱了大多数烦人的手动工作，并且您可以根据需要越来越多地实现自动化。如果您不愿意维护大量的CI代码，则应从此处开始。

您需要的是CI（如前所述）和程序包管理器。您无法解决的事情是使用git推送更改和新标签，因此第5步和第6步的部分内容仍为手动操作。

包装管理

我会用诗歌来使事情简洁明了，因为我喜欢^[1]，但还有其他选择。这将涉及步骤2、3、7、8和未列出的步骤10“更新我的依赖关系并测试它们的兼容性”，一旦发现有问题，这将令人讨厌。

使用诗歌时的坏消息是，您需要将所有打包配置都移到一个新文件中pyproject.toml。好消息是，你并不需要一个单独的setup.py，setup.cfg，MANIFEST.in，或requirements.txt更多，因为pyproject.toml是用于包装和其他工具临时标准，诗也有演练如何在端口的所有相关信息。

设置就绪后，新的部署工作流程将是：

$ poetry update           # update dependencies, may be skipped 
$ poetry version          # bump version
Bumping version from 1.1.2 to 1.1.3
# finalize git stuff, e.g. add -u, commit -m 'v1.1.3', tag v1.1.3, push
$ poetry publish --build  # build and publish to PyPI
Building my_django_lib (1.1.3)
 - Building sdist
 - Built my_django_lib-1.1.3.tar.gz

 - Building wheel
 - Built my_django_lib-1.1.3-py3-none-any.whl

Publishing my_django_lib (1.1.3) to PyPI
 - Uploading my_django_lib-1.1.3-py3-none-any.whl 100%
 - Uploading my_django_lib-1.1.3.tar.gz 100%

这应该已经比您目前正在做的要短得多。如果您始终执行完全相同的git命令，不怕自动执行推送，并妥善保管您的.gitignore文件，请随时向您的函数中添加类似此函数的名称，~/.bashrc然后调用它：

git_cord () {
  version=$(grep pyproject.toml -e '(?<=^version = ")(.*)(?=")' -Po)
  git add -u
  git commit -m "${version}"
  git tag "${version}"
  git push -u origin "${version}"
}

gitlab-CI入门

CI原则上可以处理部署过程中的所有事宜，包括版本变更和发布。但是第一个要求您的CI可以推送到您的存储库（具有令人讨厌的副作用），而第二个要求它可以将其发布到您的PyPI（这是有风险的，并且使调试CI变得很痛苦）。我认为通常不愿意手动执行这两个步骤，因此这种最小的方法只能处理步骤1和9。此后可以包括更广泛的测试和构建工作。

配置项的正确设置取决于您计划使用的配置项。github的清单很长，因此我将重点关注gitlab的内置CI。它是免费的，几乎没有什么魔力（这使得它具有可移植性），并且CI运行程序的二进制文件是开放的，免费的，并且实际记录在案，因此您可以在本地调试CI或在免费运行程序没有启动的情况下启动并连接新的运行程序。帮你剪

.gitlab-ci.yml您可以在项目根目录中放入一个小文件，以运行测试。流水线中的每个作业（跳过设置和安装命令）也应该在您的开发环境中可执行，保持这种方式可以使维护人员获得更好的体验。

image: python:3.7-alpine

stages:
  - build
  - test

packaging:
  stage: build
  script:
    - pip install poetry
    - poetry build
  artifacts:
    paths: 
      - dist

pytest:
  stage: test
  script:
    - pip install dist/*.whl
    - pip install pytest
    - pytest

像这样设置buildand test阶段可一次完成第1步和第9步，同时还针对已安装的软件包而不是源文件运行测试套件。尽管只有在您的项目中有src布局时，它才能正常工作，这会使本地资源无法从项目根目录导入。一些信息，为什么在这里和这里将是个好主意。

诗歌可以创建一个src-layout模板，您可以使用将该代码移入其中poetry new my_django_lib --src。

变更日志

尽管有一些工具可以根据提交消息自动创建变更日志，但是保持良好的变更日志是从手动维护中受益匪浅的事情之一。因此，我的建议是不要对步骤4进行自动化。

考虑它的一种方法是，手册CHANGELOG文件包含与您的用户相关的信息，并且仅应包含新功能，重要的错误修正和弃用之类的信息。

对于贡献者或插件编写者而言可能更重要的更细粒度的信息将位于MR，提交消息或进行讨论中，而不应纳入CHANGELOG。您可以尝试以某种方式收集它，但是浏览这样的AUTOLOG内容可能与筛选我刚才提到的主要资源一样麻烦。

简而言之，可以跳过步骤5和6中与变更日志相关的部分。

---

带CD的CI

添加CD不会发生太大变化，只是您不必手动释放。如果CI中断，越野车出现，或者您不想等待管道发布修补程序，则仍然可以以诗歌形式发布。

这将通过以下方式更改工作流程：

• 日常工作
  • 编写代码（尚无法避免）
  • 在提交消息和/或MR中记录进度（我更喜欢MR，即使是我自己进行更改，也压缩合并时的所有提交）
  • 推送到gitlab /合并MR
• 发布时
  • 创建一个标签，运行poetry version，也许poetry update
  • 写发行说明 CHANGELOG
  • 推送到gitlab

.gitlab-ci.yml如果您提供以下机密信息 PYPI_USER，则可以立即对前一个文件进行添加PYPI_PASSWORD：

stages:
  - build
  - test
  - release

[...]  # packaging and pytest unchanged

upload:
  stage: release
  only:
    - tags
    # Or alternatively "- /^v\d+\.\d+\.\d+/" if you also use non-release
    # tags, the regex only matches tags that look like this: "v1.12.0"
  script:
    - pip install poetry
    - poetry publish -u ${PYPI_USER} -p ${PYPI_PASSWORD} dist/*

---

一些有用的链接：

• .gitlab-ci.yml 文件资料
• 预定义变量列表，这是大多数gitlab CI晦涩之处所在
• 我.gitlab-ci.yml模板的长版，以及可能对您有用或无用的其他阶段。它期望代码的src布局。
  • lint：类型检查，覆盖率和代码样式
  • security：检查您自己的代码和依赖项是否存在价差
  • release.docs：公共gitlab页面部分，在其中提供根据您的文档字符串自动创建的文档
  • 该build阶段从poetry.lock文件中创建一个操舵室，该文件可用于以后安装依赖项以支持PyPI。这样可以更快一点，可以节省网络带宽，并且可以在需要调试时声明使用特定版本，但是这样做可能会过大，并且需要使用诗歌预发行版。

---

^{[1] _{除其他事项外，诗歌还（1）为您处理virtualenv，（2）创建哈希散列的锁定文件，以防您需要可复制的构建，以及（3）使贡献更容易，因为克隆后只需运行“诗歌安装”即可回购，并准备开始。}}