anchor.diff:  
   It is not atypical (though it is changing slowly) to deploy a build which has gone through all of these tests onto a set of deployment environments such as a UAT, pre-production and production environment. We'll look at how you can model these in your deployment pipelines in our next post.
   
  - 
  +
   <div class='row'>
     <%= partial "partials/downloadbanner" %>
   </div>
  
positive.code: 
  <%= image_tag 'blog/beginnings-real-pipeline/pipeline-04.jpg', :alt => 'Pipeline', :title => 'Pipeline' %>
  
  Hopefully, that change didn't feel like the ["How to draw an owl"image] ("http://sethgodin.typepad.com/seths_blog/2014/01/how-to-draw-an-owl.html")!
  
  Since stages run one after another, only if Stage 1 passes does it go to Stage 2 and so on. Also, since jobs run parallelly (assuming agents are available), the two jobs which run tests in Stage 2 can potentially run parallelly and provide quicker feedback than when run serially. Also, if both unit tests and integration tests fail for a changeset, then both parts of that feedback will be available simultaneously (in a single pipeline run). This is different from when they were all run serially as tasks in a single job.
  
  ## More Jobs vs More Pipelines
  
  We did mention earlier that our application was cross-platform. So, let's assume that the functional tests need to be run on three different operating systems - Mac OS X, Windows and Linux. We could start to approach this by adding jobs in Stage 4 and use GoCD's [*resource*]("https://docs.gocd.io/current/introduction/concepts_in_go.html#resources") concept to make sure that the jobs are picked up by [*agents*]("https://docs.gocd.io/current/introduction/concepts_in_go.html#agent") with the right operating system. This will involve running agents on the different operating systems and tagging them with resources "mac", "windows" and "linux". Once that's done, we could setup our pipeline to look like this:
  
  <%= image_tag 'blog/beginnings-real-pipeline/pipeline-05.jpg', :alt => 'Pipeline', :title => 'Pipeline' %>
  
  
negative.code: 
  ## Does breaking it up into parallelizable jobs help?
  
  In the current setup, all the tasks still run one after the other and still run on the same agent. Assuming that the tests can be run separately, we can try and use GoCD's *jobs* to parallelize these. The assumption, at this time, is that the "make build" task creates some [*artifact*](https://docs.gocd.io/current/introduction/concepts_in_go.html#artifacts) which is necessary for the tests to run.
  
  So, we can try to split up the single job into multiple jobs like this:
  
  