小编Reb*_*cum的帖子

我有一个带有 WebAPI 控制器的 ASP.NET Core Web 应用程序。我想要做的就是，在一些控制器中，能够启动一个将在后台运行的进程，但控制器应该在该进程完成之前继续并返回。我不希望服务的消费者不得不等待这项工作完成。

我看过所有关于 IHostedService 和 BackgroundService 的帖子，但似乎没有一个是我想要的。此外，所有这些示例都向您展示了如何设置，但并未实际调用它，或者我不了解其中的一些内容。

我尝试了这些，但是当您在 Startup 中注册 IHostedService 时，它​​会立即在该时间点运行。这不是我想要的。我不想在启动时运行任务，我希望能够在需要时从控制器调用它。另外，我可能有几个不同的，所以只注册 services.AddHostedService() 将不起作用，因为我可能有一个 MyServiceB 和 MyServiceC，那么我如何从控制器中获得正确的一个（我不能只注入 IHostedService） ?

最终，我所看到的一切都是一大堆复杂的代码，这些代码看起来应该是一件很简单的事情。我错过了什么？

我们正在尝试在最新的Visual Studio TFS分支和合并指南中实现ALM Rangers所描述的"基本双分支计划" .从指导:

具有MAIN,DEV和RELEASE分支的基本分支计划支持您的下一个版本的并发开发,用于测试的稳定MAIN分支和用于任何船舶阻止错误修复的RELEASE分支.通过从MAIN创建其他开发分支来支持多个开发区域.这些是彼此的对等和MAIN的孩子.

通过为每个产品版本创建发布分支来支持其他版本.每个发布分支都是MAIN的子级和彼此的对等(例如,发布2.0分支是对等发布3.0并且都是MAIN的子级).如果一次只支持生产中的单个版本,您可以考虑单个版本分支,并直接在此分支上修复错误.创建RELEASE分支后,MAIN和开发分支机构可以开始接受为下一个产品发布批准的更改.

我们尚未决定是否要使用单个Release分支(和标签发布),或者每个版本创建一个新的发布分支.但是,有一些问题适用于任何一种方式,这些问题似乎没有得到指导的解决.

我的主要问题是:在什么时候我们应该创建一个RELEASE分支(或者将测试代码移动到单个RELEASE分支,如果这是我们的方式)？

1. 我的第一反应是只在准备好发布时才创建它,但是你遇到了为开发和测试下一个sprint的工作创建死锁的问题; 在创建RELEASE分支之前,您无法将这些更改检查到MAIN(如果这样做,则更难分离您只想转到RELEASE的更改).
2. 第二个想法是在sprint开始时创建RELEASE分支,并且当更改通过MAIN中的测试时,将它们合并到当前的RELEASE分支.一旦我们到达sprint的末尾,我们就可以锁定RELEASE分支,并为下一个sprint创建一个新的分支.这听起来像它可以工作,但我看不到任何地方的讨论,所以我只是想看看人们在做什么.