Metadata Card

• Prerequisites: Ch1-7 (all of Vol 0)
• Estimated time: 35 min
• Core difficulty:
• Completion marker: Can describe the full lifecycle from writing code to running in production, understand the roles of compilation, packaging, deployment

Your Progress

The tool wall in the workshop is full. You've collected all eight tools. Now, take a step back. You know the individual tools: editor, Git, terminal, debugger, package manager, Docker. But you've never connected them in a full chain. What is the actual path a piece of code takes from "written in my editor" to "running on a real server"?

Your Task

You're building a complete application. It has a frontend, a backend, and a database. You're working with a team. The code is on GitHub. You want a process where: you push code → automatically tested → automatically deployed. This is called CI/CD. This chapter connects everything you've learned so far into one coherent pipeline — the actual journey from code to running.

Chapter Layers

• Required reading: The full lifecycle from code to production: write → compile → package → deploy → run
• Optional reading: CI/CD basics, environment separation (dev/staging/prod)
• Advanced: Blue-green deployment, canary release, feature flags

This chapter will NOT require you to understand

• Kubernetes deployment details
• Full CI/CD pipeline YAML configuration
• Infrastructure as Code (Terraform)

The Breakthrough · Tracing the Origins

Phase 1: Writing Code

It starts here. Your editor of choice (VS Code, IntelliJ), your fingers on the keyboard. You write a function. You test it locally. You commit to Git.

git add .
git commit -m "feat: add user login endpoint"
git push origin main

That's day one.

Phase 2: Building

Your code is on GitHub. But it's not ready to run. It needs to be compiled (if it's Java, Go, Rust, C++) or bundled (if it's JavaScript, Python, Ruby).

Building is the process of turning source code into an executable artifact.

# Java: compile + package
mvn clean package
# Produces: target/my-app-1.0.0.jar

# Node.js: bundle (if needed)
npm run build
# Produces: dist/

# Python: freeze dependencies
pip freeze > requirements.txt

What happens during a build?

1. Source code is compiled (for compiled languages)
2. Tests are run (unit tests, integration tests)
3. Dependencies are resolved
4. An artifact is produced (jar, war, Docker image, npm package)

Phase 3: Packaging

The build artifact is packaged into a deployable unit.

In modern development, this usually means a Docker image:

FROM eclipse-temurin:17-jre
WORKDIR /app
COPY target/my-app-1.0.0.jar app.jar
EXPOSE 8080
CMD ["java", "-jar", "app.jar"]

docker build -t my-app:1.0.0 .
docker push my-app:1.0.0  # Push to a registry

Now your artifact is portable. It can run on any machine with Docker, any OS, any cloud.

Phase 4: Deploying

The packaged artifact is placed onto a server (or cluster).

Manual deployment:

ssh myserver
docker pull my-app:1.0.0
docker stop my-app
docker run -d --name my-app -p 8080:8080 my-app:1.0.0

Automated deployment (CI/CD):

• GitHub Actions, GitLab CI, Jenkins detect the push
• They build, test, package, and deploy automatically

Phase 5: Running

Your service is live. Users hit your API. Logs are streaming. You monitor metrics.

When something goes wrong, you check:

• Logs (docker logs my-app, or a log aggregator)
• Metrics (CPU, memory, request latency)
• Alerts (pager duty, Slack notifications)

The Full Pipeline (Simplified)

Editor → Git → CI Server → Build → Package → Deploy → Run
  ↑           ↓         ↓         ↓        ↓       ↓     ↓
 Write      Commit    Test     Compile   Docker  Server Live
  code       push                          image

Each stage is an opportunity to catch problems early. Tests catch bugs before packaging. CI catches integration issues before deployment. Monitoring catches runtime issues before users notice.

Common Pitfalls

Environment Drift

Your dev environment has Java 17, but the server has Java 11. Your Python tool works locally with 3.10, but the server has 3.9. This is environment drift — the difference between environments that causes "it works on my machine."

Solution: Use Docker to standardize environments. The Docker image that runs on your dev machine is the same image that runs in production.

The Artifact Is Not the Source Code

Never deploy from source. Always build an artifact once, then promote that same artifact through environments: dev → staging → production.

If you rebuild on each server, you might get different results due to different dependency versions, different compilation flags, different OS.

Configuration != Code

Don't hardcode DB_URL or API_KEY in your code. Use environment variables:

String dbUrl = System.getenv("DB_URL");

docker run -e DB_URL=jdbc:postgresql://prod-db:5432/myapp my-app

Final Challenge

Map the full pipeline for a project you've worked on or imagine building:

1. Where do you write the code?
2. Where is it stored?
3. How is it built?
4. How is it packaged?
5. Where is it deployed?
6. How does it run?

Checklist

• [ ] Can describe the phases from code to production
• [ ] Understand why each phase exists
• [ ] Can explain environment drift and how Docker solves it
• [ ] Can explain why you should build an artifact once and promote it
• [ ] Knows that configuration belongs in environment variables, not in code

Traveler's Notes

Code to production is a pipeline, not a one-step jump.
Build once, promote through environments.
Docker makes the artifact portable.
Environment variables make configuration flexible.
CI/CD makes deployment automatic and repeatable.

→ Volume Complete

You've completed Vol 0: Developer Workshop. You now have the survival skills:

• Terminal: talking to your computer
• Git: time travel for code
• Debugger: seeing inside running programs
• Package Manager: borrowing from the world's libraries
• Logs: the program's memory
• Docker: packaging everything together

You're ready for Vol 1: Programming Basics. The forge is set. Time to start shaping code.