anchor.diff:    <img src="/assets/images/blog/dotnet-core-gocd/value-stream-map.png" alt="Value Stream Map" />
   </figure>
   
  -Now we can setup a task that fetches the artifacts from the first pipeline and another task to deploy. Here is what setting up a fetch task would look like. The “pkg” folder name came from the artifacts configuration from the first pipeline.
  +Now we can setup a task that fetches the artifacts from the first pipeline and another task to deploy. Here is what setting up a fetch task would look like. The "pkg" folder name came from the artifacts configuration from the first pipeline.
   <figure>
     <img src="/assets/images/blog/dotnet-core-gocd/fetch_artifacts.png" alt="Fetch Artifacts" />
   </figure>
   
   Now if we trigger the first pipeline again and manually trigger the second one we can see the agent was able to fetch the build output from the first pipeline.
   
  -```
  -  21:31:26.919 [go] Start to execute task: .
  -  21:31:26.920 [go] Fetching artifact [pkg] from [hwPackagePipeline/8/defaultStage/1/defaultJob]
  -  21:31:32.017 [go] Saved artifact to [pipelines\hwDeployPipeline] after verifying the integrity of its contents.
  -  21:31:32.052 [go] Current job status: passed. ```
  -
  -  <figure>
  -    <img src="/assets/images/blog/dotnet-core-gocd/agent-pkg.png" alt="Agent Pkg" />
  -  </figure>
  +    21:31:26.919 [go] Start to execute task: .
  +    21:31:26.920 [go] Fetching artifact [pkg] from [hwPackagePipeline/8/defaultStage/1/defaultJob]
  +    21:31:32.017 [go] Saved artifact to [pipelines\hwDeployPipeline] after verifying the integrity of its contents.
  +    21:31:32.052 [go] Current job status: passed.
  +
  +<figure>
  +  <img src="/assets/images/blog/dotnet-core-gocd/agent-pkg.png" alt="Agent Pkg" />
  +</figure>
   
   ### Review
   
  -GoCD has a very good model and abstraction for how to build deployment pipelines. For example, when working on a task like packaging you don’t need to worry about anything else. It leads you to using smaller focused scripts in the right places. Also, the concept of pipelines as a material give a powerful way to break up your deployment process. In my example I used another pipeline, setup with an initial task to wait for manual approval. Then after approval a fetch task runs which copies the artifacts from the build of the first pipeline, which then can be used for deployment.
  -
  -<style type="text/css">
  -.float-image {
  -  max-width: 25%;
  -}
  -
  -.float-image img {
  -  max-width: 100%;
  -}
  -
  -.float-image img.pad-right {
  -  padding-right: 10px;
  -}
  -
  -.float-image img.pad-left {
  -  padding-left: 10px;
  -}
  -
  -.float-article {
  -  max-width: 75%;
  -}
  -
  -.float-left {
  -  float: left;
  -}
  -
  -.float-right {
  -  float: right;
  -}
  -
  -.clear {
  -  clear: both;
  -}
  -
  -@media (max-width: 699px) {
  -  .float-left, .float-right {
  -    float: none;
  -  }
  -
  -  .float-image {
  -    max-width: 100%;
  -  }
  -
  -  .float-article {
  -    max-width: 100%;
  -  }
  -}
  -</style>
  +GoCD has a very good model and abstraction for how to build deployment pipelines. For example, when working on a task like packaging you don't need to worry about anything else. It leads you to using smaller focused scripts in the right places. Also, the concept of pipelines as a material give a powerful way to break up your deployment process. In my example I used another pipeline, setup with an initial task to wait for manual approval. Then after approval a fetch task runs which copies the artifacts from the build of the first pipeline, which then can be used for deployment.
  
positive.code: title_tag_of_header: ".NET Core and GoCD | GoCD Blog"
  meta_description: "GoCD is a great way to learn the concepts and abstractions to help model your delivery pipeline and work towards improving it. This post documents setting up a .NET core project in GoCD in a minimal way for demo purposes."
  meta_keywords: "GoCD, continuous delivery, goforcd, open source, software, contribute to open source, agile continuous delivery, code contribution, Go, dotnet, .NET, .NET core, pipeline"
  summary_image: "/assets/images/blog/high-centered-team/sunkcosts_masthead.jpg"
  ---
  
  I’ve been reading up on continuous delivery and the GoCD tool is a great way to learn the concepts and abstractions to help model your delivery pipeline and work towards improving it.
  
  This post documents setting up a .NET core project in GoCD in a minimal way for demo purposes. I cover setting up a hello world app and simple scripts to build, test, and package. Then I will create a pipeline in GoCD to build our site and run unit tests. Finally I’ll show how to add additional pipelines for manual acceptance tests and deployment.
  
  If you want to know about my environment and .NET core project for this demo you can read the next section Demo Environment Setup. If you want to just jump ahead to the GoCD you can scroll down to the GoCD Setup or GoCD Pipelines sections.
  
  ## Demo Environment Setup
  
  ### Demo Environment
  For this post I’ll be using the following file structure:
  
  Where I keep my development git repo.
  
  
negative.code: 
  ### Material Setup
  
  - First I'll setup a file based git server in `C:\demo\git_server`. I'm just doing this for simplicity. You could also use Github or another SCM server.
  
        mkdir hwapp
        cd hwapp
        git init --bare
  
  - Then I'll setup a share so the git repo can be used as a material and cloned into my development folder.
  
        \\lenovo-pc\git_server\hwapp
  
  - Then clone that into my development folder.
  
        cd development
        git clone \\lenovo-pc\git_server\hwapp
  
  - Now we will just setup the [hello world .NET Core](https://www.microsoft.com/net/core#windows) app.
  
        cd hwapp
        dotnet new
  
  - Then run it to make sure everything is working.
  
        dotnet restore
        dotnet run
  
  - Add a .gitignore file (with contents):
  
        bin/
        obj/
        project.lock.json
        _build
  
  - To keep things simple I won't use a build tool and just write a few small windows commands.
  
    - build.cmd file contents:
  
          git clean -xfd
          dotnet restore
          dotnet build
  
    - test.cmd file contents:
  
          dotnet test
  
    - package.cmd file contents:
  
          IF [%1] == [] GOTO error
          @Echo Off
          dotnet pack -o _build --version-suffix %1
          EXIT /B
          :error
          Echo version required.
  
  - Add some example unit tests using [Xunit.net](https://xunit.codeplex.com/):
  
    Here is my updated project json to allow me to run xunit tests.
  
          {
            "version": "1.0.0-*",
            "testRunner": "xunit",
            "buildOptions": {
  