Guided architecture tour · 6–8 min
Build and test an app the same way each time — CodeBuild
Plan a repeatable build that checks code and produces a useful release artifact.
This tour teaches architecture decisions. Its services are not provisioned in the emulator.
Your goal
Plan a repeatable build that checks code and produces a useful release artifact.
Why this matters
“It works on my laptop” is not enough for a team release. You will define build steps, stop on failed checks, and pass a known output to the next stage.
Words you will use
A build turns source files into usable output. A buildspec describes build commands and outputs. An artifact is the result saved for another step, such as a deployment.
How to proceed
Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.
1. Make the recipe repeatable
Different laptops have different tools and dependency versions. The team wants a shared recipe that can run in a managed build environment.
What should be defined?
The environment, dependency versions, and buildspec steps.
Define the tools and steps needed to build and test the source. Use appropriate dependency locking and controlled configuration. A managed build environment still needs a clear, reproducible recipe.
The build process is documented in executable steps.
Source + build environment + buildspec → repeatable build2. Respect a failed check
A test fails during the build, but a script is written to ignore all error codes. That could send broken output to deployment.
What should the build do?
Fail clearly and keep the release from advancing.
Make required checks fail the build when they fail, and preserve useful diagnostic logs. A green status should mean the defined checks passed. It is not a guarantee that the app has no defects.
Failed checks stop this release attempt.
Required check fails → build fails → investigate3. Pass a clean output forward
The build succeeds and must hand its output to deployment. Secrets used during the build must not be packed into the artifact or printed in logs.
What should be published?
The intended artifact, tied to the source revision, with secrets excluded.
Publish only the outputs the next stage needs and record their source revision. Use scoped build permissions and protected secret handling. Check artifact contents and logs so sensitive values do not travel with the release.
The next stage receives a traceable, appropriate release package.
Successful checks → intended artifact + revision identityPractice, then check your understanding
In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.
Read the official AWS documentation for service behavior and production details.