Why do we build and publish as two steps when publish also builds?










0















Sorry if this is a stupid question, but why does the dockerfile include steps to build and publish when the publish also builds?



The following Dockerfile is created in my web application:



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"]









share|improve this question



















  • 3





    Early failure detection?

    – cricket_007
    Nov 16 '18 at 6:33











  • Maybe, but the build is early enough in the publish that it may not make a difference.

    – Martin Lottering
    Nov 16 '18 at 6:37











  • You're welcome to edit the Dockerfile. You don't have to use what it provides

    – cricket_007
    Nov 16 '18 at 6:41











  • Depends on what "publish" is doing exactly. If there are steps taken on the deploy target before the "build" step, it may mess up your deployment if the build fails only then. So better check up front if it will build. I'd say only a "security" measure that may not be necessary, but probably "good practice".

    – Fildor
    Nov 16 '18 at 8:00















0















Sorry if this is a stupid question, but why does the dockerfile include steps to build and publish when the publish also builds?



The following Dockerfile is created in my web application:



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"]









share|improve this question



















  • 3





    Early failure detection?

    – cricket_007
    Nov 16 '18 at 6:33











  • Maybe, but the build is early enough in the publish that it may not make a difference.

    – Martin Lottering
    Nov 16 '18 at 6:37











  • You're welcome to edit the Dockerfile. You don't have to use what it provides

    – cricket_007
    Nov 16 '18 at 6:41











  • Depends on what "publish" is doing exactly. If there are steps taken on the deploy target before the "build" step, it may mess up your deployment if the build fails only then. So better check up front if it will build. I'd say only a "security" measure that may not be necessary, but probably "good practice".

    – Fildor
    Nov 16 '18 at 8:00













0












0








0








Sorry if this is a stupid question, but why does the dockerfile include steps to build and publish when the publish also builds?



The following Dockerfile is created in my web application:



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"]









share|improve this question
















Sorry if this is a stupid question, but why does the dockerfile include steps to build and publish when the publish also builds?



The following Dockerfile is created in my web application:



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"]






c# .net asp.net-core visual-studio-2017 dockerfile






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 16 '18 at 6:34









cricket_007

83.5k1146116




83.5k1146116










asked Nov 16 '18 at 6:25









Martin LotteringMartin Lottering

8571322




8571322







  • 3





    Early failure detection?

    – cricket_007
    Nov 16 '18 at 6:33











  • Maybe, but the build is early enough in the publish that it may not make a difference.

    – Martin Lottering
    Nov 16 '18 at 6:37











  • You're welcome to edit the Dockerfile. You don't have to use what it provides

    – cricket_007
    Nov 16 '18 at 6:41











  • Depends on what "publish" is doing exactly. If there are steps taken on the deploy target before the "build" step, it may mess up your deployment if the build fails only then. So better check up front if it will build. I'd say only a "security" measure that may not be necessary, but probably "good practice".

    – Fildor
    Nov 16 '18 at 8:00












  • 3





    Early failure detection?

    – cricket_007
    Nov 16 '18 at 6:33











  • Maybe, but the build is early enough in the publish that it may not make a difference.

    – Martin Lottering
    Nov 16 '18 at 6:37











  • You're welcome to edit the Dockerfile. You don't have to use what it provides

    – cricket_007
    Nov 16 '18 at 6:41











  • Depends on what "publish" is doing exactly. If there are steps taken on the deploy target before the "build" step, it may mess up your deployment if the build fails only then. So better check up front if it will build. I'd say only a "security" measure that may not be necessary, but probably "good practice".

    – Fildor
    Nov 16 '18 at 8:00







3




3





Early failure detection?

– cricket_007
Nov 16 '18 at 6:33





Early failure detection?

– cricket_007
Nov 16 '18 at 6:33













Maybe, but the build is early enough in the publish that it may not make a difference.

– Martin Lottering
Nov 16 '18 at 6:37





Maybe, but the build is early enough in the publish that it may not make a difference.

– Martin Lottering
Nov 16 '18 at 6:37













You're welcome to edit the Dockerfile. You don't have to use what it provides

– cricket_007
Nov 16 '18 at 6:41





You're welcome to edit the Dockerfile. You don't have to use what it provides

– cricket_007
Nov 16 '18 at 6:41













Depends on what "publish" is doing exactly. If there are steps taken on the deploy target before the "build" step, it may mess up your deployment if the build fails only then. So better check up front if it will build. I'd say only a "security" measure that may not be necessary, but probably "good practice".

– Fildor
Nov 16 '18 at 8:00





Depends on what "publish" is doing exactly. If there are steps taken on the deploy target before the "build" step, it may mess up your deployment if the build fails only then. So better check up front if it will build. I'd say only a "security" measure that may not be necessary, but probably "good practice".

– Fildor
Nov 16 '18 at 8:00












2 Answers
2






active

oldest

votes


















0














Build is used when we add some reference/service/entities in our code and when partial completed code need to debug . in debug mode every time we need to compile with build when the code is 100% completed it no need to built . directly build by publish.






share|improve this answer























  • Are you saying that the "dotnet build" will always build, whereas the "dotnet publish" may skip the build, even if a reference was added? I find that hard to believe, but it might explain the explicit build step.

    – Martin Lottering
    Nov 16 '18 at 8:02


















-1














According to the book .NET Microservices: Architecture for Containerized .NET Applications (Microsoft EBook), the first build instruction is redundant because the publish instruction also builds, and it is right after the first build instruction. Page 94 (86), line 10.



Here is a short excerpt from the book:



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"]



For the final optimization, it just happens that line 20 is redundant,
as line 23 also builds the application and comes, in essence, right
after line 20, so there goes another time-consuming command.







share|improve this answer

























  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review

    – Roy Scheffers
    Nov 30 '18 at 12:28






  • 1





    @RoyScheffers, I fixed it. Thanks for pointing that out.

    – Martin Lottering
    Dec 6 '18 at 9:38






  • 1





    I've added the code from the book related to the quote as well.

    – Roy Scheffers
    Dec 8 '18 at 13:08










Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53332539%2fwhy-do-we-build-and-publish-as-two-steps-when-publish-also-builds%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









0














Build is used when we add some reference/service/entities in our code and when partial completed code need to debug . in debug mode every time we need to compile with build when the code is 100% completed it no need to built . directly build by publish.






share|improve this answer























  • Are you saying that the "dotnet build" will always build, whereas the "dotnet publish" may skip the build, even if a reference was added? I find that hard to believe, but it might explain the explicit build step.

    – Martin Lottering
    Nov 16 '18 at 8:02















0














Build is used when we add some reference/service/entities in our code and when partial completed code need to debug . in debug mode every time we need to compile with build when the code is 100% completed it no need to built . directly build by publish.






share|improve this answer























  • Are you saying that the "dotnet build" will always build, whereas the "dotnet publish" may skip the build, even if a reference was added? I find that hard to believe, but it might explain the explicit build step.

    – Martin Lottering
    Nov 16 '18 at 8:02













0












0








0







Build is used when we add some reference/service/entities in our code and when partial completed code need to debug . in debug mode every time we need to compile with build when the code is 100% completed it no need to built . directly build by publish.






share|improve this answer













Build is used when we add some reference/service/entities in our code and when partial completed code need to debug . in debug mode every time we need to compile with build when the code is 100% completed it no need to built . directly build by publish.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 16 '18 at 6:54









Vignesh DVignesh D

85




85












  • Are you saying that the "dotnet build" will always build, whereas the "dotnet publish" may skip the build, even if a reference was added? I find that hard to believe, but it might explain the explicit build step.

    – Martin Lottering
    Nov 16 '18 at 8:02

















  • Are you saying that the "dotnet build" will always build, whereas the "dotnet publish" may skip the build, even if a reference was added? I find that hard to believe, but it might explain the explicit build step.

    – Martin Lottering
    Nov 16 '18 at 8:02
















Are you saying that the "dotnet build" will always build, whereas the "dotnet publish" may skip the build, even if a reference was added? I find that hard to believe, but it might explain the explicit build step.

– Martin Lottering
Nov 16 '18 at 8:02





Are you saying that the "dotnet build" will always build, whereas the "dotnet publish" may skip the build, even if a reference was added? I find that hard to believe, but it might explain the explicit build step.

– Martin Lottering
Nov 16 '18 at 8:02













-1














According to the book .NET Microservices: Architecture for Containerized .NET Applications (Microsoft EBook), the first build instruction is redundant because the publish instruction also builds, and it is right after the first build instruction. Page 94 (86), line 10.



Here is a short excerpt from the book:



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"]



For the final optimization, it just happens that line 20 is redundant,
as line 23 also builds the application and comes, in essence, right
after line 20, so there goes another time-consuming command.







share|improve this answer

























  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review

    – Roy Scheffers
    Nov 30 '18 at 12:28






  • 1





    @RoyScheffers, I fixed it. Thanks for pointing that out.

    – Martin Lottering
    Dec 6 '18 at 9:38






  • 1





    I've added the code from the book related to the quote as well.

    – Roy Scheffers
    Dec 8 '18 at 13:08















-1














According to the book .NET Microservices: Architecture for Containerized .NET Applications (Microsoft EBook), the first build instruction is redundant because the publish instruction also builds, and it is right after the first build instruction. Page 94 (86), line 10.



Here is a short excerpt from the book:



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"]



For the final optimization, it just happens that line 20 is redundant,
as line 23 also builds the application and comes, in essence, right
after line 20, so there goes another time-consuming command.







share|improve this answer

























  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review

    – Roy Scheffers
    Nov 30 '18 at 12:28






  • 1





    @RoyScheffers, I fixed it. Thanks for pointing that out.

    – Martin Lottering
    Dec 6 '18 at 9:38






  • 1





    I've added the code from the book related to the quote as well.

    – Roy Scheffers
    Dec 8 '18 at 13:08













-1












-1








-1







According to the book .NET Microservices: Architecture for Containerized .NET Applications (Microsoft EBook), the first build instruction is redundant because the publish instruction also builds, and it is right after the first build instruction. Page 94 (86), line 10.



Here is a short excerpt from the book:



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"]



For the final optimization, it just happens that line 20 is redundant,
as line 23 also builds the application and comes, in essence, right
after line 20, so there goes another time-consuming command.







share|improve this answer















According to the book .NET Microservices: Architecture for Containerized .NET Applications (Microsoft EBook), the first build instruction is redundant because the publish instruction also builds, and it is right after the first build instruction. Page 94 (86), line 10.



Here is a short excerpt from the book:



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"]



For the final optimization, it just happens that line 20 is redundant,
as line 23 also builds the application and comes, in essence, right
after line 20, so there goes another time-consuming command.








share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 8 '18 at 13:06









Roy Scheffers

2,258102027




2,258102027










answered Nov 19 '18 at 7:22









Martin LotteringMartin Lottering

8571322




8571322












  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review

    – Roy Scheffers
    Nov 30 '18 at 12:28






  • 1





    @RoyScheffers, I fixed it. Thanks for pointing that out.

    – Martin Lottering
    Dec 6 '18 at 9:38






  • 1





    I've added the code from the book related to the quote as well.

    – Roy Scheffers
    Dec 8 '18 at 13:08

















  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review

    – Roy Scheffers
    Nov 30 '18 at 12:28






  • 1





    @RoyScheffers, I fixed it. Thanks for pointing that out.

    – Martin Lottering
    Dec 6 '18 at 9:38






  • 1





    I've added the code from the book related to the quote as well.

    – Roy Scheffers
    Dec 8 '18 at 13:08
















While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review

– Roy Scheffers
Nov 30 '18 at 12:28





While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review

– Roy Scheffers
Nov 30 '18 at 12:28




1




1





@RoyScheffers, I fixed it. Thanks for pointing that out.

– Martin Lottering
Dec 6 '18 at 9:38





@RoyScheffers, I fixed it. Thanks for pointing that out.

– Martin Lottering
Dec 6 '18 at 9:38




1




1





I've added the code from the book related to the quote as well.

– Roy Scheffers
Dec 8 '18 at 13:08





I've added the code from the book related to the quote as well.

– Roy Scheffers
Dec 8 '18 at 13:08

















draft saved

draft discarded
















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53332539%2fwhy-do-we-build-and-publish-as-two-steps-when-publish-also-builds%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Top Tejano songwriter Luis Silva dead of heart attack at 64

ReactJS Fetched API data displays live - need Data displayed static

Evgeni Malkin