从 GIT 仓库管理您的 dev.to 博客文章并使用持续部署自动发布/更新它们

设置需要很长时间吗？

告诉我如何设置！

感谢阅读

发现拼写错误？

跟我来

您可能还喜欢阅读

2023年4月更新：虽然这篇博文的整体思路保持不变且仍然具有现实意义，但我不再建议使用 Travis。请改用 Github Actions （如果您不使用 Github，也可以选择任何其他 CI 运行器）。模板仓库已更新为使用 Github Actions。您可以阅读这篇博文来了解主要思路，然后前往模板仓库获取最新的分步指南。

您是否曾经希望拥有一个 monorepo（*1），其中包含 GitHub 上的所有 dev.to 帖子，并且一旦将更新合并到主分支，它们就会自动在 dev.to 上更新？

1）或多个存储库，没关系😃

然后你就会对接下来发生的事情感到满意，否则我会在下一部分告诉你为什么你可能想要它。

为什么我要把我所有的博客文章都放在 git repo 上？

不要害怕在编辑文章时弄乱它
与开发时相同的良好做法（格式化、提交、保留更改历史记录、编辑时进行比较等）
使用Prettier格式化 Markdown 和所有代码片段
让人们通过创建 PR 来为你的文章做出贡献（厌倦了因为一些拼写错误而导致的评论偏离主题？只需让人们知道他们可以在你的博客文章末尾创建 PR）
借助Embedme ( *1 ) ，在您的博客文章附近创建代码示例并确保它们正确无误

*1：Embedme 允许您在实际文件中而不是 Markdown 文件中编写代码，然后在需要的地方为您注入代码。

如果您不想使用 Prettier 或 Embedme，您可以简单地将其删除，但我认为拥有它们是一件好事！

设置需要很长时间吗？

只需几分钟。大概最多 3 到 5 分钟，从零开始到使用这个新设置自动在 dev.to 上的一篇博客文章上部署更新🔥！

告诉我如何设置！

您可以选择是否将此工作流程集成到现有存储库中，或者使用我制作的模板来简化从头开始的过程。

在这篇博文中，我们将重点介绍如何使用模板，但阅读本文后，您会发现将其集成到您自己的工作流程中是多么容易。

主要步骤：

1.复制模板
2. 创建 dev.to 令牌
3. 将该令牌传递给 Travis CI
4. 将你的博客文章放入新的存储库

1.复制模板

前往https://github.com/maxime1992/dev.to并复制模板：

根据需要设置存储库的名称和描述：

（注意：如果您想使用 Travis 的免费实例来持续部署您的博客文章，则存储库必须是公开的）

一旦你的存储库生成，你应该会看到类似以下内容：

2. 创建 dev.to 令牌

转到https://dev.to/settings/account并为令牌命名，以便您可以记住在哪里使用它：

暂时保持页面打开。

3. 将该令牌传递给 Travis

编辑：2020年7月8日

Beeman在dev.to上写了一篇很棒的文章来介绍如何使用Github Actions：

使用 GitHub Actions 自动发布您的 DEV 帖子

beeman 🐝 ・ 2020 年 7 月 5 日

#devto #publication #stackbit #github

Github Actions 相对于 Travis 的主要优势在于，如果 repo 是私有的，您可以获得 2000mn 的空闲时间（这应该足够了！）。

虽然我们将重点介绍如何使用 Travis 作为我们的 CI，但如果您更喜欢使用 Github Actions，请查看 Beeman 的文章！=)

前往https://travis-ci.org/account/repositories

由于 GitHub 仓库刚刚创建，Travis 可能尚未看到该仓库。如果出现这种情况，请点击左侧的“同步帐户”按钮强制刷新您的仓库。

完成后，您应该能够找到您的项目，并且需要单击右侧的切换按钮来激活它：

您现在可以点击“设置”。

现在我们需要将 dev.to 令牌传递给 Travis。在“环境变量”部分中，定义一个名为的新变量DEV_TO_GIT_TOKEN。返回生成令牌的 dev.to 选项卡，将其复制并粘贴到“值”输入框中。

准备好后，单击“添加”按钮。

4. 将你的博客文章放入新的存储库

首先，你需要确保你的 package.json 文件定义了一个属性repository.url。它应该类似于：https://github.com/maxime1992/my-dev.to.git，其中包含你自己的用户名/仓库名称。它将用于从那里检索你的文章图片。

dev-to-git.json然后，请注意项目根目录下有一个。我们将在这里管理要发布的博客文章。

该 json 文件应包含一个数组，并且每个条目应有 2 个字段：id和relativePathToArticle。

例子：



[
  {
    "id": 133785,
    "relativePathToArticle": "./blog-posts/manage-dev-to-blog-posts-with-continuous-deployment/manage-dev-to-blog-posts-with-continuous-deployment.md"
  }
]

目前还没有简单的方法来管理文章的创建（目前还没有？），但这是一个快速且一次性的操作。前往https://dev.to，点击顶部的“撰写文章”按钮。输入标题（稍后可以更新），然后点击“保存草稿”按钮。这样，文章尚未发布，只有您可以查看。

由于 dev.to 页面本身不显示博客文章的 ID，我做了一个小查询来在页面中找到它。打开浏览器控制台，在文章对应的 dev.to 页面上粘贴以下内容：



+$('div[data-article-id]').getAttribute('data-article-id');

这将为您提供要放入的帖子的 ID dev-to-git.json。

你的博客文章应该有一个“前言”标题。例如，我正在写的一篇博客文章是：



---
published: false
title: "Manage your dev.to blog posts from a GIT repo and use continuous deployment to auto publish/update them"
cover_image: "https://raw.githubusercontent.com/maxime1992/my-dev.to/master/blog-posts/manage-dev-to-blog-posts-with-continuous-deployment/assets/github-travis-dev-to.png"
description:
tags: devto, publication, blogpost, continuousdeployment, github, travis
series:
canonical_url:
---

这意味着你可以直接从用 Markdown 撰写的博客文章中管理所有这些属性。是不是很酷？

最后，所有本地图片链接都会被重写为指向 GitHub 文件的远程链接。没错，就连你的图片也可以成为版本控制的一部分了🙌！

感谢阅读

别害羞，请在评论区告诉我你对这个项目的看法☺️。你喜欢它吗？你会考虑使用它吗？如果没有，我很想知道它还缺少什么，以便更好地适应你的工作流程。

我在伦敦市中心的CloudNC工作，我们正在招聘！

我们每个月第一个星期五都会举办一次黑客日，正是在最后一个黑客日期间，我决定开始这个项目。我开源了一个名为dev-to-git的 npm 模块，它负责处理在 dev.to（模板仓库使用）上读取和发布代码的大部分繁重工作。

发现拼写错误？

如果您发现本博文中有拼写错误、需要改进的句子或其他任何需要更新的内容，您可以通过 Git 仓库访问并提交拉取请求。无需发表评论，请直接前往https://github.com/maxime1992/my-dev.to并提交新的拉取请求，提交您的修改。如果您对我如何通过 Git 和 CI 管理我的 dev.to 帖子感兴趣，请点击此处了解更多信息。