最近在探索「如何发布 NPM 包」的过程中，发现多数人的思路要么完全不用 CI，修改 package.json 内版本号之后手动发布；要么结合 CI，但需要 CI 生成新版本号之后修改 package.json，最后机器人执行 Git Commit + Git Tag 并推送到仓库内。这两种做法我都不是很喜欢，前者没有 CI 不能忍，后者不仅要求 CI 有写权限，而且会仓库内增加许多形如 Release v... 之类的提交，强迫症表示接受不了。 不过经过一番研究，我还是找到了两种比较「干净」的思路，来看看吧。
已发布的 DevOps 自动化实践 - 定时任务监控的进化之路 一次 KubeCPUOvercommit 告警排查过程小记 DevOps 自动化实践 — 在 K8s 上自动化执行 Database Migration 基于 UniFi 全家桶的企业 Wi-Fi 客户端管理 DevOps 自动化实践 — 管理 Incident 工作流 迁移至个人博客的 由于相关人员长期拖延审稿、发稿，将部分文章迁移至个人博客发布。
在之前的文章中，我介绍了： 如何使用 GitLab CI 实现持续部署。 如何使用 Helm 和 Helmfile 部署应用到 Kubernetes 集群中。 但这其中缺少了关键的一环：创建一个属于你的项目的 chart，这样才能把我们开发的项目通过 Helm 部署到集群中。本文将会为大家介绍我们如何创建并维护 chart，从而打通从提交代码到部署的完整流程。
在上一篇文章中，为大家介绍了 Helm 的初步使用。然而这仍然不能满足我司的工作流，主要问题有： Helm 不提供 apply 命令；因此在 CI/CD 场景中必须考虑到判断是 install 还是 upgrade。 不方便控制安装的 chart 版本；例如指定版本范围、锁定某一版本等。 Values 必须是纯文本；不支持模板渲染、不方便区分环境。 因此我们需要 Helm Releases as Code。我听说过的产品有 Helmsman 和 Helmfile 两款。目前我们团队已经使用后者一段时间，并且有团队成员贡献过部分代码。
为了能够使代码在不同项目复用，我司抽象、编写了许多私有 libraries。它们的源代码被统一存放在 GitLab，由 CI 确保代码风格一致，并执行单元测试和静态检查等。由于仓库数量众多，如何有效地组织和管理 CI 配置成了问题。经过长时间的探索和优化，我整理了一些经验，希望对你有所帮助。
Recently, I’ve been working against Kubernetes and Helm for a while. Today, I faced a strange problem that could only be triggered in a very very specific condition. After determined what happened under the hood, I decided to write it down in case someone else needs it. Also, BTW, to practice my English. :D
（接上文） 前面的部分介绍了如何为我的博客打包 Docker 镜像，接下来就是重头戏 —— 部署到 Kubernetes。
最近 Kubernetes 的发展，以及在我司的大量应用，自己也迫不及待想要尝尝鲜，虽然我的博客是基于 Hexo 的纯静态站点，但这并不能阻挡我把它迁移上 Kubernetes！毕竟… 相比于 GitHub Pages 灵活性更好可控性更高，emmmm… 好了我编不下去了，总之，生命在于折腾😂，我们开始吧。
hustcc/lint-md 是一款中文 Markdown 写作规范检查工具，检查规则来源于 ruanyf/document-style-guide。 配合 CI/CD 使用，即能够以完全自动化的方式，确保优秀的博文质量，长期使用还可培养良好的写作习惯。
大概想法：转换我的简历 HTML 到 PDF -> 将 PDF 部署到七牛云 -> 访客可直接下载最新版本 PDF 且与在线简历同步。 以上过程均基于 Travis CI 实现，替换成其它亦可。平时我们提到的 CI/CD，而本例即为简易的 CD（Continuous Delivery）实例。