Portfolio Delivery.
The pipeline behind the page you’re reading.
Problem.
The old portfolio split my work across separate identities and pages. I rebuilt it around the projects, but the first releases still meant copying source and rebuilding a container on the server. Every update repeated the same manual checks. I wanted one coherent site, and the image I tested to be the image visitors received—with a way back if activation failed.
Implementation.
- 01
Rebuilt the site around one identity, project stories, and reusable SVG diagrams in a Gruvbox palette. One content collection supplies the pages, author metadata, social images, and sitemap; the homepage keeps Work, About, and Contact together.
- 02
Added GitHub Actions checks for lint, TypeScript, and release safety. The workflow builds a standalone Docker image and runs Chromium against that image before packaging it.
- 03
Made the browser suite follow the project collection: server-rendered stories, author identity, sitemap, social images, filters, narrow screens, and the torus’s motion controls. A new project doesn’t need a new hardcoded count.
- 04
Packaged the tested image with its exact source archive, Git revision, image ID and SHA-256 checksums. The release tool accepts successful main-branch artifacts from the expected workflow and repository.
- 05
Kept production activation explicit, through existing administration access. GitHub holds no server credentials. Before switching, the tool checks for drift, captures the current image and configuration, then waits for health and checks the public site. Failed activation restores the previous release.
Result.
This portfolio now ships a tested image instead of rebuilding on production. The release records its source revision and previous state, and the same tool handles rollback. The last step in the diagram is this browser window. You made it through the pipeline without having to read a build log.
Six Chromium suites cover the site’s content, SEO and interactions; release tests exercise artifact rejection, drift detection and automatic rollback on activation or smoke-check failure. Hosted workflow and live release verification are recorded with the source revision and image ID. Rollback failure tests use controlled fixtures, not a deliberate production outage.
What I learned.
The first hosted run exposed a container startup race. The first release stopped safely because CI identified the image by its config digest while production used its OCI manifest digest. I fixed readiness retries and verified both digests from the saved image instead of weakening the check. This remains a single-container deployment with a brief interruption during replacement; host recovery is a separate problem.
Questions about this project?
Email Binh ↗