A few times a day I push code, and about twenty minutes later whatever I changed is running live, checked, and confirmed healthy, without me touching anything in between. The machinery that does this is my pipeline, and Giant Context, the website platform I build, runs its entire pipeline from one file. That file runs twenty-nine jobs, and one push crosses all of them.
First, the term. CI/CD stands for continuous integration and continuous deployment. Integration means every change is merged, checked, and tested against the whole system soon after it is written. Deployment means the changes that pass actually ship, to live servers, automatically. A pipeline is the ordered set of jobs that does both. Testing is in there, but testing is maybe half of it. The other half is building the software, deciding what needs to ship, shipping it, and confirming it survived the trip.
jobs in the pipeline
phases
minutes from keyboard to live
The pipeline starts locally, with two small gates that git itself runs.
The first fires on every commit. A tool called Prettier rewrites each changed file into the house code style, so no human ever argues about formatting and no diff is ever noise. It costs milliseconds. This happens through a git hook, which is a script git runs automatically at fixed moments, like commit or push.
The second fires on push, and it is bigger:
.husky/pre-push
# .husky/pre-push# …BRANCH=$(git rev-parse --abbrev-ref HEAD)if [ "$BRANCH" = "main" ]; then echo "ERROR: Direct pushes to 'main' branch are not allowed." exit 1fi# …echo "Running pre-push validation..."It refuses to push straight to main, the branch that production ships from. Then it runs four checks in order. The format check confirms Prettier has done its job. The typecheck runs the TypeScript compiler, which proves every function is called with the shapes it declared. The tests run. The build compiles everything into the artifacts that would actually deploy. Cheapest check first, most expensive last, so a mistake dies at the lowest price available.
If all four pass, the push leaves my machine, and the cloud half begins.
Cheapest check first, most expensive last, so a mistake dies at the lowest price available.
Everything from here on is defined in one file in the repository, .github/workflows/ci.yml, which GitHub reads and executes on its own servers every time a push lands on the dev branch, the shared branch where finished work integrates. The file's table of contents is just its job names in order:
The job names in ci.yml, in order
validate-secrets:detect-changes:test-ts-lint:test-ts-unit:test-ts-integration-api:test-ts-integration-core:test-ts-integration-apps:test-ts-rbac:test-python-logger: # …and five more python suitesci-report:deploy-web: # …and six more deploysweb-health: # …and six more health checksTwenty-nine jobs, four phases. Check that the pipeline can run at all. Figure out what changed. Prove the change is sound. Ship it and confirm it lives. One push flows through all four.
Check it can run
What was touched
12 tests fan out
Deploy, then health
Check it can run
What was touched
12 tests fan out
Deploy, then health
The first job validates secrets. The pipeline needs credentials to do its work, keys for the cloud project it deploys into, connection strings for the test database, and this job confirms every one of them exists before anything is spent. The most expensive pipeline failure is the one that runs the entire test phase and then dies at the deploy step because a key was missing. Check the cheapest fatal thing first.
The second job detects changes. The platform is not one program. It is a set of services, separately built and separately deployed. There is the console customers work in, the frontend that renders their public websites, the API, the router that steers each customer's domain to the right site, the file service, the AI service, and the error-triage service. This job diffs the push against what is already live and decides which of those services the change actually touched, so a fix to the file service does not redeploy the AI. Everything downstream consults this decision.
Then the test jobs fan out, all at once, on parallel machines. Twelve of them. Lint and format verification. Unit tests, the fast checks of individual functions. Three separate integration suites that start a live connection to a real Postgres database and exercise the API the way the product actually uses it, because a test against a fake database proves nothing about the real one. A dedicated RBAC suite that checks every declared permission against what the routes actually enforce. And six Python suites covering the Python services and their shared libraries, because the platform speaks two languages and both get the same treatment.
A reporting job collects all twelve verdicts into one summary. Any red, and the pipeline stops here. Nothing ships.
All green, and the deploy jobs start, one per service that detect-changes flagged. Each one builds its service into a container, an image that packages the program with everything it needs to run, and hands it to Google Cloud, where the new version replaces the old one.
Deploying is not the end. The last seven jobs are health checks, one per service. Each asks its freshly deployed service to answer for itself before the pipeline confirms the push succeeded. A deploy that goes out but cannot say hello is a failure, and the pipeline says so out loud rather than letting me find out from a customer.
The crossing takes about twenty minutes, and I push a few times a day. That price is not small. The test half of the pipeline grows every week, several hundred test files two months in, and cloud minutes cost money at that cadence. I have fought with this file more than with any other part of the platform, and the fight is mostly economics, not correctness. Where the settlement lands is still in motion.
What the twenty minutes buys is the property the design aims at. Between my keyboard and my customers stand twenty-nine jobs that either confirm my work and ship it or tell me what I got wrong. When it is green, the platform is live and checked. When it is red, production never heard about my mistake. For a company of one, that is not process for its own sake. It is the only coworker who reviews everything I ship.
If you're interested in my work or Giant Context, contact me!