Project structures in Bamboo - Bamboo Tutorial

- [Instructor] So, now it's time to start compiling our code and create artifacts. Before that, we have to learn about the structure of projects and plans in Bamboo, because it's quite a learning curve, and a bit confusing for people who are new to Bamboo, so we need to elaborate on this quite a bit. So, in Bamboo, when you create a project, it comes with a plan. A plan is a container for your stages. So, every project has one plan, and every plan has one, or potentially more, stages. Every stage is responsible to do something on your code and produce an artifact. An artifact may be the result of compilation and build of your code. Stages run in sequential manner, that means that stage number two has to wait for stage number one to finish in order to execute and run, and there, like the likewise of stage number three, can only be executed once the stage number two is executed and is finished. Every stage comes with one or more jobs. So, when you create a plan, it comes with a default stage, and every stage comes with a default job, but you can add more jobs if you need to. Jobs run in parallel, they don't run sequentially, so job number two doesn't have to wait for job number one to finish. They can run at the same time. One thing you need to bear in mind, and it's very important, because it can cause a lot of confusion and frustration at times, is that every job has its own working directory. That means that, for example, if you check out, or clone, your source code in job number one, that source code one exists in job number two, and job number two won't be able to do anything on that source code. If you need the source code in job number two, you have to check it out, or clone it, in the job number two as well. So, running jobs in parallel has benefits. For example, if you want to run unit tests on your source code, and at the same time you want to run code quality checks, and calculate, for example, quality metrics, you don't have to wait for the unit test to run in order to run the code quality checks. So, you can do that in parallel, and eventually every job, potentially, if you want to, it can create an artifact. You will define the artifact, and then once the job is completed successfully, it'll produce an artifact. And, the aggregation of all the artifacts that multiple jobs produce is basically the artifact of the stage, which if you want to, you can pass it to the next stage. And, every job is made of one or more tasks. For example, if you want to check out your source code and compile it, you will need one task to check out, or clone, your source code, and then you need another task to compile that source code. And from this, it becomes obvious that tasks run sequentially, they don't run in parallel, because you have to wait until your source code is checked out, completely and successfully, and then start compiling it. Most build plans are made of one stage, one job, and multiple tasks. And, you have to be careful when you create your plan and your projects, because this strike check can quickly go out of hand and become too complicated. You better to keep it as simple and as possible. So, I have graded this topic as an independent topic, so that if in case you need to brush up on this, and come back and look at this diagram as a reference, then you can just do it, and come to the topic. So, in the next topic, we will start to compile, and build, and then deploy an example website, so let's go and do that.