[](https://res.cloudinary.com/practicaldev/image/fetch/s--krC99TWb--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https ://thepracticaldev.s3.amazonaws.com/i/2sz1pxsnuzu89ypwspn8.png)

制作钻石固体工艺的最佳方法是自动化

一个与现实有任何相似之处的故事纯属巧合......

[fictitious user] : ...我有一个页面,上面写着五百个错误。那是很多!

[你,别说500是错误码,不是错误数]:嗯......不应该是这样的......你运行的是哪个版本?

啊。

究竟是哪个版本?

棘手的问题......页脚的页脚中的小数字?隐藏评论? API 的版本化 URL ?等等...

[user] :它说 0.3.1

[你]:谢谢。让我检查一下变更日志

啊。

啊。

变更日志到底在哪里?

我们有一个开始吗?它是最新的吗?它是为营销人员编写的吗?好吧,如果你有一个变更日志,那么很有可能它并没有真正的帮助......

目标

为了促进上述类型的对话,我想向您介绍一些处理和一些工具。

最终目标应该是

$ make release
...

进入全屏模式 退出全屏模式

你会被设置为

1. github上新分支rc-X.X.X

2.基于此分支在github上发布新版本

3. 更新的变更日志,包含有意义的信息......

4. ...这实际上来自此版本与上一个版本之间的差异

5. 一种检查当前/下一个版本代码的方法

6. README 上的更新徽章(因为徽章很酷)

一个命令来统治他们

先决条件

• 使

• 你在 github 上的应用

• 码头工人

Docker 将使您免于安装其他依赖项,例如 ruby(用于生成变更日志)或 python(用于管理版本)

设置

个文件

此存储库 (release-maker) 被设计为插件:您应该将以下文件复制粘贴到应用程序的存储库中

文件

描述

├── 生成文件

所有命令的入口点

├── 斌

│ ├── Dockerfile

定义了一个(非常)简单的来自 python:3 的 docker 镜像,并带有可用的 requests 库。镜像在本地构建,make build

│ └── update_release.py

管理脚本,运行健全性检查,更新版本号,发布到 github

├── .env.sample

定义环境变量的值

└── 版本.py

版本号写入/读取/导入的位置

环境变量

只需将 .env.sample 文件复制粘贴(或重命名)为 .env 并填写您的详细信息:

$ cp .env.sample .env
$ vi .env
# GITHUB_* are used for github APIs, to automatically create release & Changelog
GITHUB_OWNER?=repo owner
GITHUB_REPO?=repo name
GITHUB_USER?=your github user
GITHUB_KEY?=your key
CHANGELOG_GITHUB_TOKEN?=${GITHUB_KEY}

进入全屏模式 退出全屏模式

码头工人

一旦你“导入”了存储库内容并定义了你的变量,你需要构建/拉取将要使用的 docker 镜像。否则你会得到这样的错误:

$ make vars
Unable to find image 'python-requests:latest' locally

进入全屏模式 退出全屏模式

python 镜像是在本地使用make build构建的。它是一个简单的 Dockerfile,它依赖于 python 3 官方镜像,并将安装库 requests。

# bin/Dockerfile
FROM python:3

WORKDIR /usr/src/app
RUN pip install --no-cache-dir requests

ENTRYPOINT ["python"]
CMD ["--help"]

进入全屏模式 退出全屏模式

由于我们正在设置 docker,因此您实际上可以拉取第二个将生成 Changelog 的图像。make pull也会为你运行make build

$ make pull
...

进入全屏模式 退出全屏模式

该命令现在应该可以正常工作(使用您的环境变量值)

$ make vars
  Version: 0.1.1-rc

  GITHUB_OWNER=ebreton
  GITHUB_REPO=release-maker
  GITHUB_USER=ebreton
  GITHUB_TOKEN=xxx
  CHANGELOG_GITHUB_TOKEN=xxx

进入全屏模式 退出全屏模式

版本

Changelog 的生成取决于(至少)一个 git 标签的存在。如果你没有,你应该运行

git tag 0.1.0 # or whatever initial version number you prefer
git push --tags

进入全屏模式 退出全屏模式

您可以检查当前配置

$ make version
CHANGELOG GENERATOR:
Version: 1.14.3

APPLICATION:
Version: 0.1.1-rc

Updating release numbers...
INFO - compute - will set _version=0.1.1-rc
INFO - compute - will set _build=5026db3b8b001c5d8991c90d0528161abec7bbeb
INFO - compute - will set _release=0.1.0-12-g5026db3

进入全屏模式 退出全屏模式

用途

实际上,每次您想要发布时,您只会使用make release(惊讶吗?)

就这样。

当然,还有一些命令,我们见过一些用于设置的命令,一些用于诊断或检查情况的命令。这是列表:

命令

描述

评论

make version

显示应用程序的当前版本(不是以前部署的),以及 github-changelog-generator 的版本

-

make vars

显示环境变量的值

需要 .env 文件

make build

从 python:3 构建一个 docker 镜像,请求可用

-

make pull

拉取 github-changelog-generator 的最后一个 docker 镜像

-

make ps

列出 docker 容器(信息比 docker ps 少)

-

make changelog

根据标签和 PR 构建/更新新版本的 Changelog

必须在 .env (或环境)中定义有效的环境变量

make release

确认版本号后,执行所有发布流程。

必须在分支master中执行

make push-qa

更新标签 qa-release 并重建变更日志

-

make push-prod

更新标签 q a-release 并重建变更日志

要求确认分支和版本

我们还没有讨论最后两行......它们背后有某种好处,这将在最后一节中看到。

窗帘后面

我猜你看到了它的到来:

1\。 github 上的一个新分支 rc-X.X.X

这充当紧急分支,以防需要快速修复

2\。基于此分支的 github 上的新版本

这允许更新徽章或从 github API 获取版本号

3\。更新的变更日志,包含有意义的信息...

这是您在诊断任何问题时要查找的强制性上下文

4\。这实际上来自此版本与上一个版本之间的差异

谢谢法拉利!

5\。一种检查代码当前/下一个版本的方法

感谢_versions.py_,您可以在代码中的任何地方导入和使用它

6\。 README 上的更新徽章(因为徽章很酷)

的确

奖金

使用 git 标签进行持续集成和持续部署

如果你发生

1. 在 docker 容器中运行您的应用程序,

2. 并在您的注册表(或 docker hub)中设置自动构建,

3.使用编排器

使用标签进行持续集成和部署很方便

在我的例子中,编排器依赖qa-release标签来升级集成环境,并依赖prod-release标签来升级生产。

这一切都是自动化的,除了触发器,它仍然在你的手上。因此,运行make release将调用make push-qa,并启动升级过程进行集成。您也可以通过调用自己make push-qa(无确认)来升级,而无需完成所有发布过程

为了更新生产,您必须拨打make push-prod,它会要求您确认。

请注意,这两个命令将更新您的变更日志(通过调用make changelog),因为我们希望它与每个标签指出的提交保持同步。

$ make push-qa
# update tags
git tag -f qa-release
Updated tag 'qa-release' (was db42b2e)
git push --tags --force
...

$ make push-prod
You are on branch 'master'
on version '0.1.2-rc'

Type [y] to comfirm push
or any other key to abort:
...

进入全屏模式 退出全屏模式

不用说,如果你没有配置你的编排器来更新基于新构建的容器,并且如果你没有配置你的注册表来更新基于 git 标签的构建......那么......上面的这两个命令不会很有用。

结论

我不能过分强调自动版本控制和发布的便利性,以及一致的(自动生成的)变更日志。它只是节省了数小时的团队工作来支持最终用户和诊断问题。

在我的团队中,我们很早就意识到了这一点,并且我们努力构建我们的拉取请求、变更日志和版本号。但只要是手动的,这就是行不通的。太麻烦了,绝对没有价值(直到狗屎击中风扇)。

Firstofall release maker 让我们能够专注于开发和评论的内容。其次,它极大地促进了发布过程,以至于我们实际上可以显着提高我们的发布频率,从每月一次到每周一次(有时更多)。

好的。便利。

希望你也会发现它很有用:)