2

我们目前有两个应用程序用于同一个网站。原因是我们想要一个暂存环境。在部署之前，我们还需要预览我们的站点以与利益相关者共享。我们的暂存应用程序目前促进了这两者，这使得管理分支合并有点复杂。staging 中的代码错误地到达我们的地方是很常见的master。我们有一个指南，如果遵循，可以防止这种情况发生。

我看到 Heroku在一个管道中同时支持preview、staging和deploy ，而不是我们的两个应用程序。但我对如何设置它来支持我们的用例感到困惑。

概述

我在想，我们不应该拥有两个应用程序，而应该只拥有一个具有更好管道的应用程序。但我不确定预览功能是如何工作的。成本也可能是一个问题。

  • 我们希望在 [stakeholder name].firefund.net 或 preview.firefund.net 上为利益相关者提供一个预览站点。我们通常同时有多个利益相关者。我们从 master 为每个利益相关者创建一个新的 git 分支。利益相关者是否可以看到其他利益相关者的东西并不重要，但我们不会合并所有利益相关者的代码。有时，根据利益相关者的不同，一个分支永远不会因为各种原因被合并。
  • 我们需要一个临时区域来对网站进行一般更改。我们是这些更改的利益相关者，这些更改始终纯粹是技术性的，可能会破坏网站。我们需要在类似于生产的环境中测试我们的更改。staging.firefund.net 是这个的 URL。如果一切正常，我们将功能分支合并到 master 并部署到 Heroku。
  • 我们有一个生产站点，它始终是 master 分支中的代码。

当前的 Heroku 设置

应用程序 PL* 预览 PL* 分期 PL* 生产 Git 分支 网址
消防基金分期 - ✓</td> - staging https://staging.firefund.net/
firefund-生产 - - ✓</td> master https://www.firefund.net/

*PL：管道

git 分支示例：

campaign/lbf           <- stakeholder branch
campaign/weresistburma <- stakeholder branch
feature/gulp           <- feature branch
feature/server-next    <- feature branch
master                 <- production site
staging                <- preview and staging branch

问题

从 git 和 Heroku 管道的角度来看，有助于“概述”中的愿望的设置如何？

最好创建一个活动，将其推送到 github 并获得一个预览站点以与利益相关者共享并进行迭代，直到准备好上线。也没有在组合中发生重大变化。

并且无需知道哪些活动处于预览状态并确保它们在本地更新，以便可以合并最新版本并显示在 staging.firefund.net 上来测试代码会很好。

编辑

所以这个问题没有得到任何答案，Heroku 支持只提供了指向https://devcenter.heroku.com/articles/pipelines的链接。即使在阅读了管道文章（以及更多文章）之后，我仍然有一些悬而未决的问题。下面我根据我目前的理解添加了可能的场景，以及关于细节的进一步问题。我可能对它的工作方式非常错误 - 非常感谢您的更正！

情景“新战役”

步骤 1-3 同时发生在我们“管道”中的 1-5 个广告系列中。

  1. 我们从我们的master分支创建一个拉取请求（PR）并将其推送到 github.com
  2. Heroku 将检测 github PR 并创建一个带有类似https://firefund-campaign-pr-77.herokuapp.com的 URL 的评论应用程序
    1. 我们的活动分支遵循命名方案并始终以campaign/[campaign name]- 我们如何告诉 Heroku 只为具有该命名约定的 PR 创建评论应用程序？
    2. 我们是否可以自动自定义子域，例如https://firefund-weresistburma.herokuapp.com或通过 CloudFlare（我们用于 DNS）设置子域，例如https://preview-weresistburma.firefund.net？可预测模式屏幕截图不显示分支名称。
  3. 我们与利益相关者一起迭代设计等，并不断向 PR 推送新的提交，这会自动更新 Heroku Preview 应用程序。
  4. 当活动准备好发布时，我们将其推广到staging.
    1. staging我们可以在推广评论应用时合并多个 PR吗？
    2. 如果我们将 4 个广告系列（评论应用程序）推广到staging其中但只有 3 个应该与它们合并，它是如何工作的master？它们是并行推广还是合并？
    3. 让我感到震惊的是，我们更容易 git 合并一个活动，准备上线staging，然后运行 ​​CI，将其合并master然后部署到 Heroku。或者也许staging一起跳过并与master.

场景“新功能”

此场景不得与“新战役”场景相冲突。

  1. 我们使用命名方案创建一个 PR feature/[name of feature]。
  2. 此 PR 不会创建 Review 应用，但我们手动将其与https://staging.firefund.net/staging合并并访问它
  3. 如果一切看起来都不错，我们可以手动将其与Heroku 合并master并部署在 Heroku 上。

我非常不确定这两种情况如何不会冲突以及提升功能。它是并行推广应用程序还是合并分支？我认为我们希望预览应用程序和 具有相同的数据库配置staging，因此该staging阶段对于预览应用程序可能是多余的。还是我错过了什么？

我们可以配置我们希望 CI 在哪个阶段运行还是在所有阶段都运行？

我们如何管理成本？在https://www.heroku.com/pricing “集成 CI/CD 选项”上，它说包含“Heroku Review Apps”。这是否意味着创建的评论应用程序是免费的？我们目前为每个应用支付 7 美元。只要我们可以控制我们的每月费用，这不是问题 - ei 限制每月应用程序或类似的。我担心有人会在一个月内创建 30 个竞选分支，而我们直到收到账单才意识到。-我们没有任何稳定的收入

4

0 回答 0