Modeling and configuring your automated release process is easier if you understand the concepts and terms used in AWS CodePipeline. Here are some concepts to know about as you use CodePipeline.

For an example of a DevOps pipeline, seeDevOps pipeline example.

The following terms are used in CodePipeline:

Pipelines

Apipeline is a workflow construct that describes how software changes go through a release process. Each pipeline is made up of a series ofstages.

Stages

A stage is a logical unit you can use to isolate an environment and to limit the number of concurrent changes in that environment. Each stage contains actions that are performed on the applicationartifacts. Your source code is an example of an artifact. A stage might be a build stage, where the source code is built and tests are run. It can also be a deployment stage, where code is deployed to runtime environments. Each stage is made up of a series of serial or parallelactions.

Transitions

Atransition is the point where a pipeline execution moves to the next stage in the pipeline. You can disable a stage's inbound transition to prevent executions from entering that stage, and then you can enable the transition to allow executions to continue. When more than one execution arrives at a disabled transition, only the latest execution continues to the next stage when the transition is enabled. This means that newer executions continue to supersede waiting executions while the transition is disabled, and then after the transition is enabled, the execution that continues is the superseding execution.

Actions

Anaction is a set of operations performed on application code and configured so that the actions run in the pipeline at a specified point. This can include things like a source action from a code change, an action for deploying the application to instances, and so on. For example, a deployment stage might contain a deployment action that deploys code to a compute service like Amazon EC2 or AWS Lambda.

Valid CodePipeline action types aresource,build,test,deploy,approval, andinvoke. For a list of action providers, seeValid action providers in CodePipeline.

Actions can run in series or in parallel. For information about serial and parallel actions in a stage, see therunOrder information inaction structure requirements.

Pipeline executions

Anexecution is a set of changes released by a pipeline. Each pipeline execution is unique and has its own ID. An execution corresponds to a set of changes, such as a merged commit or a manual release of the latest commit. Two executions can release the same set of changes at different times.

While a pipeline can process multiple executions at the same time, a pipeline stage processes only one execution at a time. To do this, a stage is locked while it processes an execution. Two pipeline executions can't occupy the same stage at the same time. The execution waiting to enter the occupied stage is referred to aninbound execution. An inbound execution can still fail, be superseded, or be manually stopped. For more information about how inbound executions work, seeHow Inbound Executions Work.

Pipeline executions traverse pipeline stages in order. Valid statuses for pipelines areInProgress,Stopping,Stopped,Succeeded,Superseded, andFailed.

For more information, seePipelineExecution.

Stopped executions

The pipeline execution can be stopped manually so that the in-progress pipeline execution does not continue through the pipeline. If stopped manually, a pipeline execution shows aStopping status until it is completely stopped. Then it shows aStopped status. AStopped pipeline execution can be retried.

There are two ways to stop a pipeline execution:

For information about use cases for stopping an execution and sequence details for these options, seeHow pipeline executions are stopped.

Failed executions

If an execution fails, it stops and does not completely traverse the pipeline. Its status isFAILED status and the stage is unlocked. A more recent execution can catch up and enter the unlocked stage and lock it. You can retry a failed execution unless the failed execution has been superseded or is not retryable. You can roll back a failed stage to a previous successful execution.

Execution modes

To deliver the latest set of changes through a pipeline, newer executions pass and replace less recent executions already running through the pipeline. When this occurs, the older execution is superseded by the newer execution. An execution can be superseded by a more recent execution at a certain point, which is the point between stages. SUPERSEDED is the default execution mode.

In SUPERSEDED mode, if an execution is waiting to enter a locked stage, a more recent execution might catch up and supersede it. The newer execution now waits for the stage to unlock, and the superseded execution stops with aSUPERSEDED status. When a pipeline execution is superseded, the execution is stopped and does not completely traverse the pipeline. You can no longer retry the superseded execution after it has been replaced at this stage. Other available execution modes are PARALLEL or QUEUED mode.

For more information about execution modes and locked stages, seeHow executions are processed in SUPERSEDED mode.

Stage operations

When a pipeline execution runs through a stage, the stage is in the process of completing all of the actions within it. For information about how stage operations work and information about locked stages, seeHow executions are processed in SUPERSEDED mode.

Valid statuses for stages areInProgress,Stopping,Stopped,Succeeded, andFailed. You can retry a failed stage unless the failed stage is not retryable. For more information, seeStageExecution. You can roll back a stage to a specified previous successful execution. A stage can be configured to roll back automatically on failure as detailed inConfiguring stage rollback. For more information, seeRollbackStage.

Action executions

Anaction execution is the process of completing a configured action that operates on designatedartifacts. These can be input artifacts, output artifacts, or both. For example, a build action might run build commands on an input artifact, such as compiling application source code. Action execution details include an action execution ID, the related pipeline execution source trigger, and the input and output artifacts for the action.

Valid statuses for actions areInProgress,Abandoned,Succeeded, orFailed. For more information, seeActionExecution.

Execution types

A pipeline or stage execution can be either a standard or a rolled-back execution.

For standard types, the execution has a unique ID and is a full pipeline run. A pipeline rollback has a stage to be rolled back and a successful execution for the stage as the target execution to which to roll back. The target pipeline execution is used to retrieve source revisions and variables for the stage to rerun.

Action types

Action types are preconfigured actions that are available for selection in CodePipeline. The action type is defined by its owner, provider, version, and category. The action type provides customized parameters that are used to complete the action tasks in a pipeline.

For information about the AWS services and third-party products and services you can integrate into your pipeline based on action type, seeIntegrations with CodePipeline action types.

For information about the integration models supported for action types in CodePipeline, seeIntegration model reference.

For information about how third-party providers can set up and manage action types in CodePipeline, seeWorking with action types.

Artifacts

Artifacts refers to the collection of data, such as application source code, built applications, dependencies, definitions files, templates, and so on, that is worked on by pipeline actions. Artifacts are produced by some actions and consumed by others. In a pipeline, artifacts can be the set of files worked on by an action (input artifacts) or the updated output of a completed action (output artifacts).

Actions pass output to another action for further processing using the pipeline artifact bucket. CodePipeline copies artifacts to the artifact store, where the action picks them up. For more information about artifacts, seeInput and output artifacts.

Source revisions

When you make a source code change, a new version is created. Asource revision is the version of a source change that triggers a pipeline execution. An execution processes source revisions. For GitHub and CodeCommit repositories, this is the commit. For S3 buckets or actions, this is the object version.

You can start a pipeline execution with a source revision, such as a commit, that you specify. The execution will process the specified revision and override what would have been the revision used for the execution. For more information, seeStart a pipeline with a source revision override.

Triggers

Triggers are events that start your pipeline. Some triggers, such as starting a pipeline manually, are available for all source action providers in a pipeline. Certain triggers depend on the source provider for a pipeline. For example, CloudWatch events must be configured with event resources from Amazon CloudWatch that have the pipeline ARN added as a target in the event rule. Amazon CloudWatch Events is the recommended trigger for automatic change detection for pipelines with a CodeCommit or S3 source action. Webhooks are a type of trigger configured for third-party repository events. For example, WebhookV2 is a trigger type that allows Git tags to be used to start pipelines with third-party source providers such as GitHub.com, GitHub Enterprise Server, GitLab.com, GitLab self-managed, or Bitbucket Cloud. In the pipeline configuration, you can specify a filter for triggers, such as push or pull request. You can filter code push events on Git tags, branches, or file paths. You can filter pull request events on event (opened, updated, closed), branches, or file paths.

For more information about triggers, seeStart a pipeline in CodePipeline. For a tutorial that walks you through using Git tags as triggers for your pipeline, seeTutorial: Use Git tags to start your pipeline.

Variables

Avariable is a value that can be used to dynamically configure actions in your pipeline. Variables can be either declared on the pipeline level, or emitted by actions in the pipeline. Variable values are resolved at the time of pipeline execution and can be viewed in the execution history. For variables declared at the pipeline level, you can either define default values in the pipeline configuration, or override them for a given execution. For variables emitted by an action, the value is available after an action succesfully completes. For more information, seeVariables reference.

Conditions

Acondition contains a set of rules that are evaluated. If all rules in a condition succeed, then the condition is met. You can configure conditions so that when the criteria are not met, the specified result, such as failing the stage, engages. Conditions are also referred to as gates because they allow you to specify when an execution will enter and run through a stage or exit the stage after running through it. This is analogous to allowing a line of traffic on a roadway to gather at a closed gate, and then specifying the opening of the gate to allow flow of traffic into an area. Results for condition types include failing the stage or rolling back the stage. Conditions help you to specify when these actions happen in a pipeline stage. You can override conditions at runtime.

There are three types of conditions. Entry conditions answer the question “If the rules for the condition are met, then enter the stage.” The stage is locked when the execution enters the stage, and then the rules are run. For On Failure conditions, the rule engages when a stage has failed, with a result of rolling back a failed stage. For On Success conditions, the rule engages when a stage is successful, such as checking a successful run for alarms before proceeding. For example, an On Success condition would result in a rollback of a successful stage if the CloudWatchAlarm rule finds that there are alarms in the deployment environment. For more information, seeHow do stage conditions work?.

Rules

Conditions use one or more preconfiguredrules that run and perform checks that will then engage the configured result for when the condition is not met. For example, meeting all rules for an Entry condition rule that checks for alarm status and deployment window times will deploy a successful stage after all checks pass. For more information, seeHow do stage conditions work?.

Thanks for letting us know we're doing a good job!

If you've got a moment, please tell us what we did right so we can do more of it.

Thanks for letting us know this page needs work. We're sorry we let you down.

If you've got a moment, please tell us how we can make the documentation better.