当发布也构建时，为什么我们将构建和发布分为两个步骤？答案

【问题标题】：Why do we build and publish as two steps when publish also builds?当发布也构建时，为什么我们将构建和发布分为两个步骤？
【发布时间】：2018-11-16 06:25:54
【问题描述】：

对不起，如果这是一个愚蠢的问题，但为什么 dockerfile 包含构建和发布的步骤，而发布也构建了？

在我的 Web 应用程序中创建了以下 Dockerfile：

FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 80

FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
RUN dotnet restore "WebApplication1/WebApplication1.csproj"
COPY . .
WORKDIR "/src/WebApplication1"
RUN dotnet build "WebApplication1.csproj" -c Release -o /app

FROM build AS publish
RUN dotnet publish "WebApplication1.csproj" -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]

【问题讨论】：

早期故障检测？
也许可以，但构建在发布中足够早，可能不会产生影响。
欢迎您编辑 Dockerfile。你不必使用它提供的东西
取决于“发布”到底在做什么。如果在“构建”步骤之前对部署目标采取了步骤，那么如果构建失败，那么它可能会扰乱您的部署。所以最好预先检查它是否会构建。我只想说一个可能不必要的“安全”措施，但可能是“良好做法”。

标签： c# .net asp.net-core visual-studio-2017 dockerfile

【解决方案1】：

当我们在我们的代码中添加一些引用/服务/实体以及部分完成的代码需要调试时使用构建。在调试模式下，每次我们需要使用 build 编译时，当代码 100% 完成时，就不需要 build 了。通过发布直接构建。

【讨论】：

您是说“dotnet build”将始终构建，而“dotnet publish”可能会跳过构建，即使添加了引用？我觉得这很难相信，但它可能解释了显式构建步骤。

【解决方案2】：

根据.NET Microservices: Architecture for Containerized .NET Applications (Microsoft EBook) 的书，第一个构建指令是多余的，因为发布指令也会构建，它就在第一个构建指令之后。第 94 (86) 页，第 10 行。

这是本书的简短摘录：

1 FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
2 WORKDIR /app
3 EXPOSE 80
4
5 FROM microsoft/dotnet:2.1-sdk AS build
6 WORKDIR /src
7 COPY src/Services/Catalog/Catalog.API/Catalog.API.csproj …
8 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.AspNetCore.HealthChecks …
9 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions.HealthChecks …
10 COPY src/BuildingBlocks/EventBus/IntegrationEventLogEF/ …
11 COPY src/BuildingBlocks/EventBus/EventBus/EventBus.csproj …
12 COPY src/BuildingBlocks/EventBus/EventBusRabbitMQ/EventBusRabbitMQ.csproj …
13 COPY src/BuildingBlocks/EventBus/EventBusServiceBus/EventBusServiceBus.csproj …
14 COPY src/BuildingBlocks/WebHostCustomization/WebHost.Customization …
15 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions …
16 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions …
17 RUN dotnet restore src/Services/Catalog/Catalog.API/Catalog.API.csproj
18 COPY . .
19 WORKDIR /src/src/Services/Catalog/Catalog.API
20 RUN dotnet build Catalog.API.csproj -c Release -0 /app
21
22 FROM build AS publish
23 RUN dotnet publish Catalog.API.csproj -c Release -0 /app
24
25 FROM base AS final
26 WORKDIR /app
27 COPY --from=publish /app
28 ENTRYPOINT ["dotnet", "Catalog.API.dll"]

对于最终的优化，恰好第 20 行是多余的，因为第 23 行也构建了应用程序，并且本质上是正确的在第 20 行之后，还有另一个耗时的命令。

【讨论】：

我也添加了书中与报价相关的代码。