A common concern is regarding the order of the stages and the order of the jobs, which job should be
executed in parallel, which should be executed one after the other.
To be honest, this is totally up to you.
There are no hard truths, there are a few guidelines.
The main idea that can guide you in this process is to go by the rule of failing fast.
You want to execute the tests that take the least time in the beginning so that if they fail, you will
get instant feedback.
For example, say, does more tests, takes 15 minutes to complete four or any other tests.
It doesn't really make sense to put a smoke test before the code quality test, which may fail in only
30 seconds.
For example.
Typically you want to group tests or things either in parallel here you can execute multiple things
at once or putting things that execute really, really fast in the beginning so that you don't execute
the rest of the pipeline needlessly.
In this case, even if called quality fails, the smoke test will still be executed.
In this case, if I put a job that takes only a few seconds and in parallel with another one, which
takes 15 minutes, as I said, then the entire stage will take 15 minutes to get answer.
It will not automatically fail.
So the smoke test will not be interrupted because the code quality fails.
Now, if I would put a code quality or any other similar test in size before the test stage, before
the smoke test, then if any of those would fail, then the entire pipeline will fail and we'll get
a faster feedback.
The main idea here is to play around with the jobs to understand what they are doing, how you can arrange
them and when it makes sense to arrange them.
For example, code quality can be even placed before the build itself because it doesn't rely on the
build output.
On the other hand, smoke tests must always be after the built do play around with the code quality
before the build lives, a smoke test in the test stage and see how the pipeline works.