Hi,
I am struggling to pick up the concepts behind all the aspects of GO. so was wondering if the community could help me out.
so first here is what i think each entity represents.
1. Pipelines - These are distinct projects that would feed into a larger system (i.e. a receipt system that might connect to other core systems)
2. Stages - These are the build stages examples I have seen in the documentation include. Build, Unit Tests, Functional Test, Performance Tests.
3. Jobs - These are the things that do the work and you can have multiple jobs per stage, they run concurently.
now the confusion lies with the Stages and Jobs, should i define a stage for each of the tasks above(build, unit test, etc). If so how does this all work, how do I pass the DLL's etc around so that they are available to each stage. (It seems that materials are defined per pipeline)
Or should I define a Job that builds and then runs the unit tests. or should i define multiple jobs, one builds the other unit tests. (This dosnt seem right as they can run concurently on multiple agents)
Thanks for your input.
Pipelines Jobs and Stages What goes where
Comments
2 comments
The main difference between Stages and Jobs is that Stages are sequential within the pipeline, wheras jobs are concurrent, so if you want to run tasks in parallel define them as jobs within a stage, if you want to know the build succeeded before unit testing, use a build stage and a test stage.
So in your example the Pipeline would have a Build stage which fetches material from your source repository, and has a job that builds the code. The output of the build is written to \output under the pipeline working directory. If this succeeds then the next stage, Test, is run which has a job that runs Nunit for instance and references the DLLs in \output. The results XML is then shown under the Test tab on that stage.
Save the \output to artifact TestedCode and then the next pipeline which deploys to a QA environment can fetch the material from Pipeline, Test stage, TestedCode. Use resources to assign the appropriate agent to run the build, test and deploy jobs
A note if you are using enterprise edition:
Since your jobs run in parallel, you could get into a situation where a different agent will run a later stage (and therefore job) than your initial build stage. That means the Go agent's working directory in the later stage won't have the "\output" directory that ian mentioned. The exception to this is if you assign the same resource to jobs in your pipeline. Or, you just need to designate an artifact from an earlier stage that you can fetch in the later stage.
If you have a relatively small number of unit tests, you're probably better off doing your build and unit tests in the same job. If you split them across stages and you haven't assigned the same resource to the jobs (build and unit test), you'll have to publish and fetch the build artifacts which will add a bit of time to your overall pipeline execution.
Please sign in to leave a comment.