Scratch ist eine blockbasierte, visuelle Programmiersprache, die am MIT Media Lab entwickelt wurde. Die erste Version erschien 2003, das heute verbreitete Scratch 3.0 läuft seit 2019 im Browser (HTML5/WebGL). Zielgruppe sind Kinder und Einsteiger ab etwa 5 Jahren: Programme entstehen, indem farbige Blöcke wie Puzzleteile zusammengesteckt werden — Tippfehler und Syntaxfehler gibt es nicht, weil nur passende Blockformen ineinandergreifen.

Die wichtigsten Blockkategorien

Scratch unterscheidet farbcodierte Blöcke nach ihrer Funktion. Die zentralen Kategorien sind:

• Bewegung (blau): Blöcke wie gehe 10er-Schritt, drehe dich um 15 Grad, gehe zu x: 0 y: 0 — steuert die Figur (Sprite) auf der Bühne.
• Aussehen (lila): sage Hallo für 2 Sekunden, denke Hmm ..., wechsle Kostüm zu Kostüm1, ändere Effekt Farbe um 25.
• Klänge (pink): spiele Klang Miau, spiele Ton 60 für 0,25 Schläge.
• Ereignisse (gelb): Wenn Fahne angeklickt, Wenn Taste Leertaste gedrückt wird, Sende Nachricht1 an alle — der Einstiegspunkt jedes Skripts.
• Steuerung (orange): wiederhole 10 Mal, falls dann sonst, warte 1 Sekunde, wiederhole fortlaufend.
• Fühlen (hellblau): frage Wie heißt du? und warte, wird Mauszeiger berührt?, Antwort.
• Operatoren (grün): +, -, *, /, Zufallszahl von 1 bis 10, und, oder, nicht, Textverkettung verbinde Hallo mit Welt.
• Variablen (orange): Setze Variable auf 0, ändere Variable um 1 — außerdem Listen und seit Scratch 3.0 eigene Blöcke (Funktionen).

Die Bühne (Stage) mit den Koordinaten x (von −240 bis 240) und y (von −180 bis 180) ist das Spielfeld; Figuren heißen Sprites und können Kostüme und Klänge tragen. Skripte werden pro Sprite an Blöcke gehängt, die typischerweise mit Wenn Fahne angeklickt starten.

Verwandte Konzepte

Scratch geht konzeptionell auf Logo-Befehle zurück: Beide wurden für den spielerischen Einstieg ins Programmieren entwickelt, und beide arbeiten mit einer grafischen Figur auf einer Fläche. Während Logo mit Textbefehlen (FD 100, RT 90) arbeitet, setzt Scratch vollständig auf Blöcke. Als nächste Schritte nach Scratch empfehlen sich Python-Befehle oder JavaScript-Befehle — viele Scratch-Konzepte wie Schleifen, Bedingungen und Variablen übertragen sich direkt.

Wer Scratch erweitern möchte, findet in der Community auf scratch.mit.edu Millionen geteilter Projekte. Für das Verständnis von Block-Bibliotheken lohnt außerdem ein Blick auf Blockly-Befehle, die Google-Alternative, die Blöcke in echten Quellcode übersetzt.

Jenkinsfile ist die Pipeline-Definition von Jenkins, direkt im Repository gespeichert („Pipeline as Code"). Die Declarative Pipeline ist die empfohlene, gut lesbare Syntax mit festen Blöcken.

Grundgerüst

pipeline {
    agent any
    stages {
        stage('Build') {
            steps { sh 'make' }
        }
    }
    post { always { cleanWs() } }
}

• pipeline – Wurzelblock jeder deklarativen Pipeline.
• agent – legt fest, wo die Pipeline läuft: any, label '...', docker oder none.
• stages/stage – strukturieren den Ablauf (Build, Test, Deploy); steps enthalten die eigentlichen Schritte.
• sh – führt Shell-Befehle aus; echo, input (manuelle Freigabe), junit (Testreports).
• post – reagiert auf den Status: always, success, failure, unstable, aborted.

Direktiven für echte Pipelines

environment definiert Variablen (auch aus credentials(...)), parameters erlaubt Build-Parameter, when steuert Bedingungen (z. B. branch 'main'), options setzt Timeouts (timeout(time: 1, unit: 'HOURS')) und Retries. Mit stash/unstash werden Dateien zwischen Stages übertragen, archiveArtifacts speichert Build-Artefakte. tools aktiviert installierte Werkzeuge wie JDK oder Maven.

Pipelines werden aus dem SCM geladen (Multibranch Pipeline) und laufen in Agents, die Jenkins über SSH oder Docker verbindet.

Verwandte Themen: Bash-Befehle (sh-Schritte), Dockerfile-Befehle (Container-Builds), GitHub-Actions-Befehle (Alternative in der Cloud), YAML/TOML/JSON-Befehle (Konfigurationsformate).

GitHub Actions ist die CI/CD-Plattform von GitHub. Workflows liegen als YAML-Dateien unter .github/workflows/ und werden bei Events (push, pull_request, schedule) automatisch ausgeführt.

Aufbau eines Workflows

name: CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: make test

• name – Anzeigename; on – auslösende Events (auch workflow_dispatch für manuellen Start).
• jobs – enthält die Jobs; jeder Job läuft isoliert auf einem Runner (runs-on: ubuntu-latest, windows-latest, macos-latest oder self-hosted).
• steps – Schritte im Job: uses ruft fertige Actions auf (z. B. actions/checkout@v4), run führt Shell-Befehle aus.
• env – Umgebungsvariablen; with – Parameter der verwendeten Action.
• secrets.<NAME> – greift auf gespeicherte Geheimnisse zu; GITHUB_TOKEN ist automatisch verfügbar.

Fortgeschrittene Bausteine

strategy.matrix fährt dieselben Schritte mit mehreren Kombinationen (z. B. Node-Versionen), if steuert Bedingungen über Ausdrücke (${{ }}), timeout-minutes begrenzt die Laufzeit. Mit actions/upload-artifact und actions/download-artifact werden Artefakte zwischen Jobs geteilt, permissions schränkt Token-Rechte ein, concurrency verhindert parallele Läufe auf derselben Referenz. Reusable Workflows werden per workflow_call eingebunden.

Verwandte Themen: YAML/TOML/JSON-Befehle (Workflow-Syntax), Jenkinsfile-Befehle (klassische CI/CD-Alternative), Dockerfile-Befehle (Container-Builds in Actions), Bash-Befehle (run-Schritte).

Dockerfile ist die deklarative Bauanleitung für Docker-Images. Jede Zeile ist eine Instruktion, die eine eigene Bildschicht (Layer) erzeugt. Wer Container produktiv einsetzt, sollte die zentralen Befehle sicher beherrschen.

Die wichtigsten Instruktionen

• FROM <image> – legt das Basis-Image fest und startet jeden Build. Erstes Kommando eines jeden Dockerfiles.
• RUN <befehl> – führt Shell-Befehle aus (z. B. Pakete installieren) und legt die Änderungen als neue Schicht ab.
• CMD – definiert den Standard-Befehl beim Container-Start; kann durch docker run ... <befehl> ersetzt werden. Nur eine CMD-Zeile zählt.
• ENTRYPOINT – setzt den festen Einstiegspunkt; Argumente des Starts werden an ihn angehängt. Kombination ENTRYPOINT + CMD ist der klassische Weg zu ausführbaren Containern.
• COPY – kopiert Dateien vom Build-Kontext ins Image; ADD kann zusätzlich URLs und Archive auflösen.
• ENV – setzt Umgebungsvariablen für den Build und zur Laufzeit; ARG nur für Build-Argumente (docker build --build-arg).
• WORKDIR – wechselt das Arbeitsverzeichnis für alle folgenden Befehle (entspricht cd, aber schicht-korrekt).
• EXPOSE – dokumentiert Container-Ports; USER wechselt den Benutzer (Sicherheit: nicht als root laufen lassen).
• VOLUME – deklariert persistente Datenverzeichnisse; HEALTHCHECK prüft die Container-Gesundheit (z. B. HEALTHCHECK CMD curl -f http://localhost/).

Multi-Stage-Builds und Best Practices

Mit FROM ... AS <name> lassen sich mehrere Build-Stufen definieren: In der ersten Stufe wird kompiliert, in der letzten nur das fertige Artefakt in ein schlankes Laufzeit-Image kopiert (COPY --from=build /app/out /app). So bleiben Images klein und ohne unnötige Werkzeuge.

Weitere Empfehlungen: Häufig wechselnden Code ans Ende der Datei legen (Layer-Caching), eine .dockerignore für unnötige Dateien anlegen und die offizielle # syntax=docker/dockerfile:1-Direktive für BuildKit nutzen.

Verwandte Themen: Bash-Befehle (RUN-Shell), Make-Befehle (Build-Steuerung), Jenkinsfile-Befehle und GitHub-Actions-Befehle (CI/CD-Pipelines bauen Container).