Testing and Deployment · Topic 5 of 6
Source Control and CI/CD Pipelines
Use Git branches and tags with CodePipeline and CodeBuild: pipeline triggers, stages, approvals, buildspec files and AI tools that support CI/CD.
- 4 min
- CodePipeline orchestrates, CodeBuild builds and tests, and CodeDeploy or CloudFormation deploys.
- Third party Git providers connect through a connection, which an administrator must authorize.
- The buildspec file sits in the repository root unless you configure another location.
What it is
A CI/CD pipeline turns a change in a Git repository into a tested, deployed release without manual steps. Source control supplies the trigger and the version history, and the pipeline supplies the repeatable path to each environment.
On AWS, CodePipeline orchestrates the stages, CodeBuild compiles and tests, and CodeDeploy or CloudFormation deploys.
How it works
Repositories and versions
A pipeline source can be a Git repository reached through a connection (GitHub, GitHub Enterprise Server, GitLab or Bitbucket Cloud), an AWS CodeCommit repository, an Amazon S3 bucket or an Amazon ECR image. A connection is created once and authorized by an administrator of the Git provider.
Git features map directly onto releases:
- Branches isolate work. A common layout deploys a feature branch to a test environment and the main branch to production, and AWS Amplify can build each connected branch on its own URL.
- Tags label a specific commit, such as
v1.4.0, so you always know what is running. A pipeline can start when a release tag is pushed. - Pull requests review changes before they merge, and merging the branch starts the pipeline.
Record the commit ID or tag with the build output, for example in the image tag or Lambda version description. That ties a running deployment back to its source.
CodeBuild and the buildspec file
CodeBuild runs commands in a managed container using a buildspec.yml file in the repository root. The file has phases that run in order.
| Phase | Purpose |
|---|---|
| install | Install tools and runtimes |
| pre_build | Log in to ECR, run linting |
| build | Compile, run tests, build the image |
| post_build | Push the image, write output files |
The artifacts section lists files to pass to the next stage, and the reports section publishes test and coverage results. A failed command fails the build, which stops the pipeline.
CodePipeline structure
A pipeline is a series of stages, and each stage holds actions. Action types include Source, Build, Test, Deploy, Approval and Invoke (for example a Lambda function). Output of one action is stored as an artifact in an S3 artifact store and handed to the next.
To move through multiple environments, add a stage for each: test, then staging, then production. Put a manual approval action before production. It pauses the pipeline and notifies reviewers, usually through an Amazon SNS topic, until someone approves or rejects.
Pipelines start from a connection webhook on a push, a pull request or a Git tag, from a schedule, or manually with StartPipelineExecution. Each action runs with an IAM role, and the pipeline service role must be allowed to use those roles. Actions can deploy across accounts by assuming a role in the target account.
CodePipeline can also roll a stage back to its last successful execution, either manually or automatically on failure.
AI tools in the delivery workflow
Generative AI tools help author and review pipeline assets. Kiro and Amazon Q Developer can draft a CloudFormation or CDK template, a buildspec file or a deployment script from a plain language request, and can explain a failed build log.
They also help with post deployment validation, for example by drafting smoke test scripts. A human still owns the gates. The approval action, alarms and tests stay in the pipeline, and generated code is reviewed before it is merged.
How the exam asks about this
- "The pipeline must pause until a lead approves production." -> Add a manual approval action before the production stage.
- "Start a release pipeline only when a version is tagged." -> Use a Git tag trigger on the source action.
- "Compile code and run unit tests in the pipeline." -> A CodeBuild action driven by buildspec.yml.
What to remember for the exam
- CodePipeline orchestrates, CodeBuild builds and tests, and CodeDeploy or CloudFormation deploys.
- Third party Git providers connect through a connection, which an administrator must authorize.
- The buildspec file sits in the repository root unless you configure another location.
- Artifacts move between stages through an S3 artifact store.
- A manual approval action gates a stage and can notify through SNS.
- Tags identify a release commit, and branches usually map to environments.
A pipeline that deploys across accounts needs the target account role to trust the pipeline account. A missing trust relationship shows up as an AccessDenied on the deploy action, not on the build.
Common mistakes
Putting secrets in the buildspec file. The file is in source control. Reference Secrets Manager or Parameter Store values in the env section instead.
Expecting CodeBuild to deploy by itself. It builds and tests. Deployment is a separate action handled by CodeDeploy, CloudFormation or another provider.
Skipping the approval step because tests pass. Automated tests do not replace a required human decision when the question states one.
Check yourself
Which file tells CodeBuild what commands to run?
buildspec.yml.How does a pipeline pause for human sign off?
A manual approval action, with notifications sent through SNS.
How can a Git commit be marked as a release?
With a Git tag, which can also start a pipeline.
Topic 5 of 6 in Testing and Deployment
Test yourself on Testing and Deployment
The full AWS DVA-C03 question bank has 850 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by AWS. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.