Arc 4 Quest 15

The Eternal Forges

CI/CD, Git platforms and first steps toward automation

The heavy metal door opens with a rumble of gears. A blast of hot air strikes your face, laden with the scent of molten metal and ancient magic. Before you stretches the Valley of the Eternal Forges - a titanic landscape of chimneys spewing blue flames, enchanted conveyors transporting scrolls from one workshop to another, and iron golems hammering, testing and assembling without rest. Every forge is linked to the others by luminous conduits, forming a pulsing network of energy.

The Master Archivist contemplates the spectacle with undisguised admiration.

"Welcome to the Eternal Forges, Master Archivist. Here, scrolls are no longer verified by hand. Enchanted constructs test them automatically as soon as they arrive. If a scroll contains an error, the forge rejects it before it can corrupt the Archives. If it is perfect, the forge deploys it directly to the halls of the kingdom. This system is called CI/CD - Continuous Integration and Continuous Deployment. It is the next step of your journey."

What is CI/CD?

CI/CD is a set of practices that automate the verification and delivery of code. Imagine an enchanted forge: as soon as an Archivist sends a scroll, the forge takes over automatically.

CI - Continuous Integration

Continuous Integration means that every change is integrated frequently into the shared repository, and that with each integration, automated tests verify that nothing is broken.

In practice:

  • You make a commit and push it
  • An automated system retrieves your code
  • It runs the tests
  • It tells you whether everything is fine or something is broken

"In the Eternal Forges, every scroll deposited is immediately inspected by the tester golems. If a word is malformed, if an incantation is incorrect, you know within minutes, not weeks. That is Continuous Integration."

CD - Continuous Delivery/Deployment

CD has two closely related meanings:

  • Continuous Delivery: tested code is ready to be deployed at any time, but a human decides when
  • Continuous Deployment: tested code is automatically deployed to production, without human intervention

"Continuous Delivery is when the forge prepares the scroll for shipment and awaits your command. Continuous Deployment is when the forge sends the scroll directly to the kingdom's libraries as soon as it passes the tests. Both approaches have their place depending on the level of trust you have in your tests."

Why CI/CD matters

Without CI/CD, here is what often happens:

  • You work for weeks on a feature
  • You integrate your code with everyone else's
  • Everything is broken
  • You spend days figuring out which change caused the problem

With CI/CD:

  • You integrate often (multiple times per day)
  • Tests run on every push
  • If something breaks, you know immediately
  • The culprit is necessarily in the latest changes (a few lines, not thousands)

An Archivist who waits weeks to send scrolls to the Forges accumulates errors the way dust accumulates on an old grimoire. An Archivist who sends every day detects problems when they are still small and easy to fix.

The pipeline concept

A pipeline is a series of automated steps that your code passes through. Think of it as a chain of forges, each specialized in a task.

The classic stages

Code --> [Build] --> [Test] --> [Deploy]
  1. Build: the code is compiled or assembled
  2. Test: automated tests are executed
  3. Deploy: validated code is put into production

Each stage must succeed for the next one to begin. If the Build fails, we don't test. If Tests fail, we don't deploy.

A more realistic pipeline

In practice, a pipeline can have more stages:

Code --> [Lint] --> [Build] --> [Unit tests] --> [Integration tests] --> [Staging] --> [Production]
  • Lint: verification of code style and syntax
  • Unit tests: fast tests on individual functions
  • Integration tests: tests that verify components work together
  • Staging: deployment to a pre-production environment
  • Production: final deployment for users

"Each forge in the Valley has its specialty. The first checks the shape of the runes. The second tests their power. The third assembles them. The fourth sends them to the libraries. If a single forge rejects the scroll, everything stops. This is the chain of trust of the Eternal Forges."

Git platforms - The great Forges of the kingdom

To use CI/CD, you need a platform that hosts your code and runs the pipelines. These are the great Forges of the kingdom, each with its own characteristics.

GitHub - The People's Forge

GitHub is the most popular platform in the world for hosting code.

  • Owner: Microsoft (since 2018)
  • CI/CD: GitHub Actions (integrated, powerful, free for open source projects)
  • Strengths: enormous community, actions marketplace, GitHub Pages, Copilot
  • Ideal for: open source projects, public collaboration, developer portfolios

This is the platform we will use in the upcoming quests.

GitLab - The Autonomous Forge

GitLab is a complete platform with a very powerful built-in CI/CD.

  • CI/CD: GitLab CI/CD (natively integrated, very mature)
  • Strengths: self-hostable (you can install your own Forge), all-in-one (issues, CI/CD, Docker registry, monitoring)
  • Ideal for: companies that want full control, private projects, complete DevOps

Bitbucket - The Atlassian Guild's Forge

Bitbucket is the Git platform of the Atlassian ecosystem (Jira, Confluence, Trello).

  • CI/CD: Bitbucket Pipelines
  • Strengths: native integration with Jira, good for small teams
  • Ideal for: teams already using Jira/Confluence

Quick comparison

Feature GitHub GitLab Bitbucket
Built-in CI/CD GitHub Actions GitLab CI/CD Pipelines
Self-hostable Enterprise (paid) Yes (free) Data Center (paid)
Free private repos Yes Yes Yes (5 users max)
Community The largest Large Medium
Ecosystem Actions Marketplace All integrated Atlassian (Jira, etc.)

"There are several great Forges in the kingdom. The People's Forge (GitHub) is the most popular - that's where most Archivists of the world gather. The Autonomous Forge (GitLab) lets you build your own independent forge. The Atlassian Forge (Bitbucket) integrates perfectly with the management tools of the great guilds. Choose your forge according to your needs, but learn at least one thoroughly."

Create a GitHub account

GitHub will be our reference forge for the rest of the course. Here's how to create your account.

  1. Go to github.com
  2. Click on Sign up
  3. Enter your email address
  4. Choose a strong password
  5. Choose a username (this will be your public developer identity!)
  6. Verify your email

Choose a professional username - it will appear on your public profile and is what recruiters will see!

Create a repository on GitHub

Once logged into GitHub:

  1. Click the + in the top right, then New repository
  2. Give your repository a name (e.g.: my-chronicles)
  3. Add a description (optional but recommended)
  4. Choose Public or Private
  5. You can check "Add a README file", "Add .gitignore", "Choose a license"
  6. Click Create repository

GitHub's special files

  • README.md: the homepage of your repository. It is the first file visitors see. Write it in Markdown
  • LICENSE: defines the usage rights of your code (MIT, GPL, Apache, etc.)
  • .gitignore: lists the files Git should ignore (you already know this from the magical seals quest!)

A repository without a README is like a library without a catalogue. Visitors don't know what they'll find inside. Always add a README.

Connect a local repository to GitHub

You have a local Git repository and you want to send it to GitHub? Here's how to link the two.

Add a remote

git remote add origin https://github.com/YOUR-NAME/my-repo.git

You already know git remote from Quest 09 (The Distant Portals). Here, origin points to GitHub instead of a local repository.

Push for the first time

git push -u origin main

The -u option (or --set-upstream) creates a tracking link between your local branch main and the remote branch origin/main. After this first push, you can simply type git push without specifying the destination.

Verify the connection

git remote -v

You should see something like:

origin  https://github.com/YOUR-NAME/my-repo.git (fetch)
origin  https://github.com/YOUR-NAME/my-repo.git (push)

Authentication: SSH vs HTTPS

To communicate with GitHub, you have two authentication methods.

HTTPS - The simple method

git remote add origin https://github.com/YOUR-NAME/my-repo.git
  • You use your username and a Personal Access Token
  • Easy to set up
  • GitHub no longer supports classic passwords since 2021 - you need a token

SSH - The key-based method

git remote add origin git@github.com:YOUR-NAME/my-repo.git
  • You generate a key pair (public + private) on your machine
  • You add the public key to your GitHub account
  • No need to type anything for each push/pull

Generate an SSH key

# Generate the key pair
ssh-keygen -t ed25519 -C "your@email.com"

# Display the public key (to copy to GitHub)
cat ~/.ssh/id_ed25519.pub

Then, on GitHub: Settings > SSH and GPG keys > New SSH key > paste your public key.

Which method to choose?

Criterion HTTPS SSH
Ease of setup Simpler Initial configuration needed
Authentication Token each time (or credential manager) Automatic after setup
Daily use May ask for the token Seamless
Recommended for Getting started quickly Regular use

"SSH keys are like personal seals - once engraved, they identify you without needing to state your name at every passage. For an Archivist who pushes scrolls several times a day, it's a considerable time saver."

Hands-on exercise - Send your chronicles to the Forge

Send your chronicles to the Eternal Forge:

  1. Create a chronicles-forge repository with git init
  2. Create a README.md and make a first commit
  3. Add two more files with one commit each (at least 3 commits total)
  4. Create a bare repository eternal-forge.git (your local Forge)
  5. Add it as remote origin
  6. Push your chronicles to the Forge with git push -u origin main
  7. Run the verification script

Step 1 - Create your chronicles

mkdir chronicles-forge
cd chronicles-forge
git init -b main

Step 2 - Write the first scroll

cat > README.md << 'EOF'
# Chronicles of the Forge

Welcome to my chronicles - a collection of scrolls
sent to the Eternal Forges for verification and archiving.

## Contents

- Chronicle of the first day
- Apprentice blacksmith's notes
EOF

git add README.md
git commit -m "Create the README for the Forge chronicles"

Step 3 - Add more scrolls

cat > chronicle-01.txt << 'EOF'
Chronicle of the First Day at the Forges

Today I discovered the Eternal Forges.
The enchanted constructs test each scroll automatically.
CI verifies, CD deploys. The chain never stops.
EOF

git add chronicle-01.txt
git commit -m "Add the chronicle of the first day at the Forges"
cat > blacksmith-notes.txt << 'EOF'
Apprentice Blacksmith's Notes

The three great Forges of the kingdom:
- GitHub: the People's Forge
- GitLab: the Autonomous Forge
- Bitbucket: the Atlassian Forge

A CI/CD pipeline:
Build -> Test -> Deploy
EOF

git add blacksmith-notes.txt
git commit -m "Add notes about the forges and the CI/CD pipeline"

Step 4 - Create the Forge (bare repository)

cd ..
git init -b main --bare eternal-forge.git

A bare repository is a Git repository without a working directory - exactly like a GitHub or GitLab server. It only contains Git data, not the working files.

Step 5 - Connect and push

cd chronicles-forge
git remote add origin ../eternal-forge.git
git push -u origin main

Step 6 - Verify

# See the configured remote
git remote -v

# See the log with remote references
git log --oneline --all

You should see origin/main next to your latest commit.

Step 7 - Run the verification

bash verifier.sh
.\verifier.ps1

Command summary

Command Description
git remote add origin <url> Add a remote repository named origin
git push -u origin main Push and create the tracking link
git push Push (after the first push with -u)
git remote -v Display configured remotes
git init --bare name.git Create a bare repository (server)
ssh-keygen -t ed25519 Generate an SSH key pair

Concept summary

Concept Description
CI (Continuous Integration) Automatically integrate and test on every push
CD (Continuous Delivery/Deployment) Automatically deploy validated code
Pipeline Chain of automated steps (build, test, deploy)
GitHub Most popular Git platform, with GitHub Actions
GitLab Platform with built-in CI/CD, self-hostable
Bitbucket Git platform in the Atlassian ecosystem
Bare repository Repository without a working directory (server)
SSH vs HTTPS Two authentication methods for platforms

You watch your chronicles travel through the luminous conduit and land in the Eternal Forge. The metal golems spring into action immediately - they inspect, sort and archive each scroll with mechanical precision.

The Master Archivist places a hand on your shoulder.

"You have just completed your first shipment to the Forges. Your scrolls are now safe, duplicated and accessible from any outpost in the kingdom. This is the foundation of everything that follows."

He points to the deepest forges in the valley, where more intense flames illuminate even more complex mechanisms.

"Now that you know how to send your chronicles to the Forges, it is time to learn how to command the constructs that work within. In the next quest, you will write your first forge blueprints - what the modern world calls pipeline files. The Forges await your orders."