有没有办法在不同的开发生命周期环境中使用 SendGrid 模板版本控制?



SendGrid 中的版本控制允许 API 客户端仅通过此处记录的模板 ID 发出模板请求,但是,一次只能有一个版本的模板处于"活动状态"。 显然,用于生产应用程序的模板需要始终设置为活动状态,但是在即将发布的版本中添加新的模板版本呢? 如何利用模板版本在我们的测试环境中测试此"非活动"版本? 这里讨论了这个问题,但是当您开始点击链接时,它似乎只是关闭并丢失了。

如果无法指定版本控制,则只剩下几个选项,这些选项需要创建特定于环境的模板并在发布完成后将它们提升为特定于生产的模板,或者为不同的 SDLC 环境创建单独的帐户并随着过程的推进而迁移它们。

这里也讨论了关于语言版本控制的问题,但它真的对我的问题没有帮助。

鉴于 SendGrid 的 API 提供的利用版本控制的工具,最佳实践是什么?使用不同的 SDLC 步骤命名模板似乎是一个灾难,需要维护数百个模板(更不用说每个环境有多个模板了)。 在迁移到生产环境时进行测试时,管理多个帐户似乎是一场噩梦。 我只是在这里错过了一些完全明显的东西吗?

我与 SendGrid 的技术代表进行了交谈,他们的 API 或 UI 不提供此功能。 一次只能"激活"一个模板。 您需要为每个环境提供一个单独的模板,或者需要从 API 使用者管理模板。 如果有人阅读本文并对不同的解决方案有疑问,请随时发布,我将解释我如何根据应用程序的需求解决此问题。

显然有未记录的方法来处理这个问题。

我有一些库代码可以解析动态模板的句柄栏逻辑,并以编程方式注入绑定任何变量所需的最小数据量。 因此,在设计时,如果我们愿意,可以在模板中添加您喜欢的任何随机项,而无需每次都更新后端。

因此,后端的所有逻辑对于确保传递的电子邮件实际上是我绑定数据的版本相同并且我不会经常刷新缓存至关重要。

今天稍微深入研究了一下,

我没有在任何 sendgrids 存储库或文档中看到它被记录在案,因此该功能将来可能会更改或中断,但您可以使用:

{"template_id": "d-#{template-guid}.#{version-guid}">

以控制在 v3/发送/邮件调用中使用哪个版本的模板。

从原始帖子到这个问题已经过去了两年,我不得不说,尽管 SendGrid 很好用并且易于集成,但我们应该使用版本和多个电子邮件模板的方式令人震惊。

我们有 20 个电子邮件模板。我们需要做的是修改模板(创建一个新版本),然后通过我们的环境对其进行测试。就目前情况而言,几乎不可能在不同的环境中工作而不影响生产。

特威利奥需要解决这个问题。

我想通过我们为小型电子邮件活动的实现来扩展实际答案

正如CodeKiller所写的那样,一种可能的解决方法是You need a separate template for every environment

问题是应用程序按 id 引用模板,但在将模板从 env 移动到 env 时无法保留模板 id。

您可以保留模板名称。SendGrid API 不允许按名称检索模板,而是可以检索所有模板并按名称查找模板。

var templatesRaw = await client.RequestAsync(
BaseClient.Method.GET,
null,
"{'page_size': 200, 'generations': 'dynamic'}",
"templates");
var templatesJson = await templatesRaw.DeserializeResponseBodyAsync(templatesRaw.Body);
var templates = (JArray)templatesJson["result"];
var template = templates.Single(templ => templ["name"].ToString() == name);
return template["id"].ToString();

为什么我不建议将其用于中型/大型广告系列:

  1. 使用无服务器时的成本。当您需要发送一封电子邮件时,您需要为处理所有模板所需的资源付费
  2. 性能。每次您需要发送电子邮件时,用户都在等待处理所有模板
  3. 创建/更新模板时,手动将模板从 env 复制到 env
  4. 亲吻违规。当您有 <200 个模板时,它看起来很简单,否则您必须处理从分页 API 查询所有模板、可能的内存不足异常、批处理电子邮件请求以防止最终使应用程序复杂化的高成本/性能率。

最新更新