Skip to main content
Nothing in Telemetry is deployed by hand, and nothing is built on a track machine. One CDK pipeline per stage builds the container images, publishes the distribution/ folder, and deploys the AWS side. The track machines then pull, on their own schedule. This page is how a change ships. For what the deployed cloud resources then do with a run, see DAQ Upload and Conversion.

​
Two Stages, Two Pipelines

The CDK app defines one stack per stage, TelemetryDev and TelemetryProd, and each creates its own self mutating CodePipeline named TelemetryPipeline-{stage}.
The stage is the branch. The pipeline source is the GitHub repository connected through CodeConnections, and the branch it watches is the stage name itself. So dev builds from the dev branch and prod builds from the prod branch. Merging to prod is the act of releasing.
Everything the pipelines create is suffixed with the stage, so the two are fully separate: separate ECR repositories, separate queues, separate Lambdas, and separate buckets. Both deploy into the same AWS account and region, eu-west-2.
The pipeline is selfMutation: true, so it updates its own definition from the branch before running the rest. A change to the pipeline itself takes effect on the run after the one that introduced it.

​
What A Run Does

A run has three parts, in order.
1

Synth

Builds the Python Lambda bundles as a side input, then installs and synthesises the CDK app. The Lambda step installs each function’s requirements.txt into its own folder and zips it, and the synth step copies those zips into build_assets/ before running cdk synth.
2

ECR repositories, then the images

A stage creates the ECR repositories, and eight docker build steps then run after it, one per image. Each logs in to ECR, builds from its own context and Dockerfile, and pushes.
3

The application stack

Deploys the topic, queues, Lambdas and bucket notifications that make up the cloud side of the pipeline.
The distribution publish also runs after the ECR stage, alongside the image builds.

​
The Images

Eight images are built on every run, each pushed to telemetry/{image}-{stage} in ECR: The first seven run on a track machine. offloaded-data-converter is the odd one out: it is built from the same API project but deployed as the conversion Lambda in AWS, not to a track.

​
Tags

Each image is pushed twice, as latest and as the resolved commit SHA of the run that built it.
That SHA tag is the only version handle in the system. The track scripts pull latest, so the SHA is what lets you identify exactly what a track is running, and what you would pin to in order to go back.
Each repository has a lifecycle rule keeping only the last 3 images. Rollback is therefore limited to roughly the last three merges to that branch, and older SHAs are deleted rather than archived. Tags are mutable, so latest moves under you.

​
The Distribution Publish

The step that actually reaches the tracks is a one line sync:
--delete means the bucket is made to match the branch exactly. A file removed from distribution/ in the repository is removed from the bucket on the next run, and the next track machine to run setup loses it. There is no versioning on this prefix.
This is the first half of getting a change to a track. The second half is a person running setup_application.bat at that track, which is normally once per event. See Getting An Update Onto The Machine.
So a merge to prod never changes a track by itself. It changes what a track will pick up the next time someone runs setup there, which is why the same change can be live at one region and not another for weeks.

​
What The Application Stack Creates

The cloud side is small: one topic, three queues and two Lambdas. Both Lambdas run with 3008 MB and a 5 minute timeout.
The ingest queue has maxReceiveCount: 1, so a message that fails once goes straight to the dead letter queue with no retry. The DLQ keeps it for 5 days and the main queue keeps messages for 1 day. A conversion that fails is therefore a dead letter within minutes and gone within five days, which is the real reason a failed conversion needs a deliberate re-upload rather than waiting. See Triggering A Reconversion Deliberately.
The converter Lambda’s image tag is resolved at synth time from the build’s commit SHA, falling back to latest. So the cloud converter is pinned to the exact image from its own pipeline run, unlike the track machines which always pull latest.

​
Deploying By Hand

The pipelines are the supported route. The CDK app is a standard TypeScript project, so npx cdk synth and npx cdk diff from CdkBuild/ are the way to see what a change would do before merging it.
Deploying a stage’s stacks directly with cdk deploy bypasses the image builds and the distribution publish, so the stack can end up referencing image tags that were never pushed. Prefer the pipeline, and use diff locally.

​
Where Things Are Named

Everything is derived from the stage, so the whole estate can be located from it:
Production ECR repositories are retained on stack deletion. Dev repositories are destroyed with the stack, as is the pipeline artifacts bucket in both stages.

​
Key Files

All paths are under CdkBuild/ in can-wifi.
Last modified on September 8, 2026