AWS CodePipeline - Part 3 (Stages)

Stages are logical units in AWS CodePipeline which provide the capability to isolate environments within the pipeline. This article will cover everything you must know about Stages in AWS CodePipeline. We discussed about AWS CodePipeline from previous articles from WitCentre. They cover the basic understanding of what AWS CodePipeline and how it can be used. If you missed it, you may read it here! It is very short but covers a lot. AWS CodePipeline artifacts are explained here! You may interest it too. Let's move on to understand stages!

What are stages in AWS CodePipeline?

Stages are logical units in AWS CodePipeline which provides the capability to isolate environments based on our requirements. We can define stages based on the functionality we expect. Thus, we can define a Build stage where source code build will happen, a Test stage where we can define test environment, a Deployment stage where we can define deployment environment and so on. The most important fact is that stages are doing an amazing work to control the pipeline executions based on it's isolation property.

How isolation happens and behaves?

We can think a stage in pipeline as a unique environment. When pipeline executes, a pipeline execution travels through the pipeline from start to end. Stages are the stopping points for each pipeline execution. Thus, when a pipeline execution stops at a stage, that stage serves the execution uniquely based on the actions configured in the stage (next article will explain about actions!). Think this as a formula race and when a car comes to it's service stations, workers will serve the car uniquely and do not focus on any other thing at that time. Thus, a stage is fully responsible for serving the pipeline execution at it's best. Just think what will happens if another car (of the same team) wants to get the service from the same service station during the race at the same time one car is under service. Obviously, the second car needs to wait until the first car is leaving from the service station after getting complete it's service. In the same manner, a stage in the pipeline will serve one pipeline execution at a time inside the pipeline. All other pipeline executions need to wait until the stage is free to serve for other pipeline executions. That is what meant by the stage isolation. You may get the same idea by referring to the figure below.

As you can see, pipeline execution 1 is in stage A and because of that execution 2 and execution 3 should wait outside the stage until execution 1 is completed inside the stage. There is another important fact regarding these executions. You may think that why execution 2 is directed away from the stage. This is because, pipeline executions are superseded by the latest executions of the pipeline. As per the numerical order, execution 3 is the latest one above, execution 2 get superseded by execution 3. Thus, only the execution 3 will continue through the pipeline when the stage A is free. Execution 2 will be discarded and there will be no way to get that execution into the pipeline back (this is the default behavior of AWS CodePipeline when this article is written).

What is the must having stage in AWS CodePipeline?

AWS CodePipeline must have a source stage! Source stage is the entry point to the pipeline. This is where we should supply input artifacts to the pipeline. Therefore, this must be configured. Otherwise, there will be no artifacts to process through the pipeline :(.

Do stages do the expected tasks in AWS CodePipeline?

Nope! Stages do not do work inside the pipeline. Instead, there are set of actions that AWS supports to configure inside stages in pipeline. These actions are the actual workers inside stages. Just think actions as the workers in a service station in a race as explained stages above :). Next article will cover about actions!

Hope you  may get something new from this article. Let us know anything you want to clarify. You can comment below or contact us via the contact form too.