diff --git a/DMS_paper15_gitlab.tex b/DMS_paper15_gitlab.tex
index be8b68d..a0023c1 100644
--- a/DMS_paper15_gitlab.tex
+++ b/DMS_paper15_gitlab.tex
@@ -267,12 +267,12 @@ build-image:
   script:
     - docker build -t app:$CI_COMMIT_SHA .
 
-deploy-staging:
+deploy:prod:
   stage: deploy
   script:
     - ssh user@host 'docker pull app'
-  only:
-    - main
+  rules:
+    - if: '$CI_COMMIT_BRANCH == "main"'
 \end{lstlisting}
 
 		Die starre Stage-Reihenfolge lässt sich mit dem Schlüsselwort \texttt{needs} aufbrechen. Durch \texttt{needs} entsteht ein gerichteter Graph ohne Zyklen, ein sogenannter \ac{DAG}. Ohne Zyklen heißt, dass kein Job direkt oder über Umwege wieder von sich selbst abhängt. Wenn die definierten Vorgänger eines Jobs fertig sind, startet dieser automatisch und wartet nicht auf die gesamte vorherige Stage \cite{cowell_automating_2023}. Dadurch entfallen unnötige Wartezeiten, und unabhängige Jobs können bei mehreren verfügbaren Runnern parallel laufen. Wiederkehrende Pipeline-Bausteine, die an mehreren Stellen gebraucht werden, lassen sich über \texttt{include} aus anderen Repositories nachladen \cite{gitlab_gitlab_nodate}.
@@ -340,7 +340,7 @@ stages:
 				\end{tabular}%
 			}
 		\end{table}
-		Die ersten beiden Stages werden bei jedem Push auf jeden Branch automatisch gestartet. Sie entsprechen den klassischen \ac{CI}-Schritten nach Duvall et al.~\cite{duvall_continuous_2007} und Fowler~\cite{fowler_continuous_2006}. Ihr Zweck ist es, für jeden Codestand ein schnelles, automatisches Feedback zu liefern. Die Stage \texttt{deploy} deckt den Continuous-Delivery-Anteil ab. Hier trennen sich zwei Pfade. Auf einem Feature-Branch steht der Job \texttt{deploy:staging} als manueller Schritt bereit, der in der Pipeline-Übersicht sichtbar ist. So lässt sich eine Änderung bei Bedarf in einer laufenden Vorschau begutachten und testen, bevor sie in den Hauptzweig übernommen wird. Ein Push auf \texttt{main} baut die Anwendung automatisch und liefert sie nach \texttt{production} aus. Nach der Begriffsabgrenzung von Shahin et al.~\cite{shahin_continuous_2017} entspricht der automatische Pfad nach \texttt{main} damit Continuous Deployment, während der manuelle Pfad nach Staging dem klassischen Continuous Delivery entspricht.
+		Die ersten beiden Stages werden bei jedem Push auf jeden Branch automatisch gestartet. Sie entsprechen den klassischen \ac{CI}-Schritten nach Duvall et al.~\cite{duvall_continuous_2007}. Ihr Zweck ist es, für jeden Codestand ein schnelles, automatisches Feedback zu liefern. Die Stage \texttt{deploy} deckt den Continuous-Delivery-Anteil ab. Hier trennen sich zwei Pfade. Auf einem Feature-Branch steht der Job \texttt{deploy:staging} als manueller Schritt bereit, der in der Pipeline-Übersicht sichtbar ist. So lässt sich eine Änderung bei Bedarf in einer laufenden Vorschau begutachten und testen, bevor sie in den Hauptzweig übernommen wird. Ein Push auf \texttt{main} baut die Anwendung automatisch und liefert sie nach \texttt{production} aus. Nach der Begriffsabgrenzung von Shahin et al.~\cite{shahin_continuous_2017} entspricht der automatische Pfad nach \texttt{main} damit Continuous Deployment, während der manuelle Pfad nach Staging dem klassischen Continuous Delivery entspricht.
 
 			Diese Jobs laufen auf zwei verschiedenen Runnern. \texttt{lint} und \texttt{unit-test} nutzen einen gemeinsamen Runner mit Docker-Executor und führen ihre Schritte in einer Container-Umgebung mit \texttt{node:20-alpine} aus. Über \texttt{tags} sind die Deploy-Jobs an einen zweiten Runner mit Shell-Executor gebunden. Sie bauen das Image mit \texttt{docker build} und starten es anschließend mit \texttt{docker run}. Für diese Befehle braucht der Runner direkten Zugriff auf den Docker-Daemon des Hostsystems. Die Prüfung bleibt so in einem isolierten Container, während die Veröffentlichung selbst auf dem Hostsystem läuft.