{"id":187187,"date":"2023-10-22T13:56:30","date_gmt":"2023-10-22T12:56:30","guid":{"rendered":"https:\/\/liora.io\/de\/?p=187187"},"modified":"2026-02-06T06:10:32","modified_gmt":"2026-02-06T05:10:32","slug":"azure-devops-yaml-pipeline-warum-ci-cd-pipelines-mit-yaml-konfigurieren","status":"publish","type":"post","link":"https:\/\/liora.io\/de\/azure-devops-yaml-pipeline-warum-ci-cd-pipelines-mit-yaml-konfigurieren","title":{"rendered":"Azure DevOps Yaml Pipeline: Warum CI\/CD-Pipelines mit YAML konfigurieren?"},"content":{"rendered":"

Die Sprache YAML erm\u00f6glicht es, CI\/CD-Pipelines auf Microsoft Azure DevOps in Form von Code zu konfigurieren. Erfahre, warum und wie du dich f\u00fcr diesen Ansatz entscheiden solltest und welche Vorteile er gegen\u00fcber dem klassischen Editor bietet!<\/strong><\/p>\t\t\n\t\t

Durch das Hinzuf\u00fcgen von Pipelines zu seinem Cloud-Dienstleistungsangebot Azure DevOps<\/a> hat Microsoft es erm\u00f6glicht, den Entwicklungsprozess um CI\/CD-Praktiken (Continuous Integration and Delivery) zu erweitern.<\/a><\/p>

Es gibt jedoch zwei M\u00f6glichkeiten, eine Azure Devops-Pipeline zu erstellen<\/a>. Die erste Methode ist die Verwendung der „klassischen“ Tools, die zweite nutzt die neue, 2020 eingef\u00fchrte Funktion der mehrstufigen YAML-Pipeline.<\/p>\t\t\n\t\t\t

Was sind klassische Pipelines?<\/h3>\t\t\n\t\t

Was sind herk\u00f6mmliche Pipelines?<\/a> Eine Build-Pipeline wird beispielsweise ausgef\u00fchrt, bevor ein Entwickler die Code\u00e4nderungen in die Codebasis integriert.<\/strong><\/p>

Die Pipeline kann eine Build-Aufgabe ausf\u00fchren, Unit-Tests starten oder statische Code-Analysen durchf\u00fchren. Sie kann dann je nach den Ergebnissen dieser Aufgaben neue \u00c4nderungen annehmen oder ablehnen.<\/p>

Continuous Delivery (CD)<\/strong> wird \u00fcber die Azure DevOps-Relax-Pipelines durchgef\u00fchrt. Nachdem die Build-Pipeline ein Artefakt produziert hat, ver\u00f6ffentlicht eine Relax-Pipeline das Artefakt auf verschiedenen Umgebungen f\u00fcr manuelles funktionales Testen, User Experience Testing und Qualit\u00e4tssicherung.<\/strong><\/p>

Wenn die Tester die eingesetzten Artefakte rigoros getestet haben, kann die Relax-Pipeline die Artefakte in die Produktionsumgebung schieben.<\/p>

Diese klassischen CI\/CD-Pipelines haben jedoch einige Nachteile. Zun\u00e4chst einmal bieten die Werkzeuge zur Erstellung von Build- und Relax-Pipelines keine einheitliche Erfahrung.<\/strong><\/p>

CI-Pipelines bieten eine intuitive grafische Benutzeroberfl\u00e4che zum Erstellen und Visualisieren von Integrationsschritten und erm\u00f6glichen es auch, dieselben Schritte in YAML zu definieren<\/strong>.<\/p>

Relax-Pipelines bieten ebenfalls eine grafische Benutzeroberfl\u00e4che zum Erstellen und Anzeigen von Pipeline-Schritten, aber das Problem ist, dass sich diese Benutzeroberfl\u00e4che von der der Build-Pipeline unterscheidet und keine YAML-Definitionen zul\u00e4sst.<\/p>\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t

\n\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t
<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t

Was sind mehrstufige Pipelines?<\/h3>\t\t\n\t\t

Um dieses Problem zu beheben, hat Microsoft die Multi-Step-Pipelines<\/strong> entwickelt. Diese Pipelines sind seit 2020 verf\u00fcgbar und erm\u00f6glichen es einem Ingenieur, eine Build-, Relax- oder Hybrid-Pipeline in Form eines einzigen YAML-Dokuments zu definieren.<\/p>

Neben dem Vorteil einer einheitlichen Entwicklungserfahrung bietet YAML viele Vorteile gegen\u00fcber herk\u00f6mmlichen Pipelines. Und das sowohl f\u00fcr Builds als auch f\u00fcr Relaxes.<\/p>

YAML-Definitionen werden direkt \u00fcber die Versionskontrolle validiert, wodurch die gleichen Vorteile genutzt werden k\u00f6nnen, die Entwicklern seit Jahrzehnten durch die Versionskontrolle geboten werden.<\/p>\t\t\n\t\t\t

Was ist YAML?<\/h3>\t\t\n\t\t

YAML ist eine Sprache zur Serialisierung von Daten, die oft zum Schreiben von Konfigurationsdateien verwendet wird. Ihr Name ist ein Akronym f\u00fcr „Yet Another Markup Language“.<\/strong><\/p>

Diese Programmiersprache i<\/strong>st beliebt, da sie leicht verst\u00e4ndlich und f\u00fcr Menschen lesbar ist. Sie kann auch in Verbindung mit anderen Sprachen verwendet werden. Ihre Flexibilit\u00e4t und Zug\u00e4nglichkeit sind ihre gr\u00f6\u00dften St\u00e4rken.<\/p>

YAML \u00fcbernimmt Merkmale aus verschiedenen Sprachen wie Perl, C, XML und HTML<\/a>. Es verwendet auch die Einr\u00fcckung im Stil von Python, um Nested anzuzeigen. Tabulatorzeichen sind nicht erlaubt, stattdessen werden Leerzeichen verwendet.<\/p>

Es gibt keine \u00fcblichen Formatsymbole wie Klammern oder Anf\u00fchrungszeichen. YAML-Dateien haben die Erweiterung .yml oder .yaml und ihre Struktur ist eine Karte oder eine Liste.<\/p>

Mit Karten k\u00f6nnen Paare von Schl\u00fcsseln und Werten verkn\u00fcpft werden. Jeder Schl\u00fcssel muss eindeutig sein, aber die Reihenfolge spielt keine Rolle. Eine YAML-Karte muss aufgel\u00f6st werden, bevor sie geschlossen werden kann. Eine neue Karte wird erstellt, indem man die Einr\u00fcckungsebene erh\u00f6ht oder die vorherige Karte aufl\u00f6st, um eine benachbarte Karte zu beginnen.<\/p>

Eine Liste schlie\u00dft Werte in einer bestimmten Reihenfolge ein und kann eine beliebige Menge der ben\u00f6tigten Elemente enthalten. Eine Listensequenz beginnt mit einem Dash (-) und einem Leerzeichen, und die Einr\u00fcckung trennt sie von ihrem Elternteil. Man kann sie mit einer Python-Liste oder einem Bash- oder Perl-Array vergleichen.<\/strong> Eine Liste kann in eine Karte eingebettet werden.<\/p>

Die YAML-Sprache nutzt auch Skalare: beliebige Daten, die in Unicode codiert sind und als Werte wie Strings, ganze Zahlen oder Datumsangaben verwendet werden k\u00f6nnen.<\/p>

Neben dem Schreiben von Konfigurationsdateien, die einfacher und verst\u00e4ndlicher als JSON sind, wird YAML<\/strong> h\u00e4ufig von den Ansible Playbooks f\u00fcr die Orchestrierung von IT-Prozessen und f\u00fcr Kubernetes-Eins\u00e4tze verwendet.<\/a><\/p>\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t

\n\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t
<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t

Die Vorteile von YAML-Pipelines<\/h3>\t\t\n\t\t

Einer der Hauptvorteile von YAML-Pipelines<\/strong> ist die M\u00f6glichkeit, jede \u00c4nderung an der Pipeline seit ihrer Erstellung mithilfe der vom Versionsverwaltungssystem gebotenen Historie zu \u00fcberpr\u00fcfen.<\/p>

Es ist auch m\u00f6glich, eine dysfunktionale Definition mit der letzten bekannten funktionalen Definition<\/strong> zu vergleichen. Dadurch k\u00f6nnen Probleme im Build effizienter gel\u00f6st und die Wiederherstellungszeit verk\u00fcrzt werden.<\/p>

Ebenso kann es hilfreich sein, zu sehen, wer den fehlerhaften Code, der den Misserfolg verursacht hat, eingereicht hat und wer die Pull-Anfrage genehmigt hat.<\/p>

Dadurch k\u00f6nnen die Teammitglieder einberufen werden, um mit ihnen nach dem besten Weg zur Behebung des Problems zu suchen und gleichzeitig sicherzustellen, dass die urspr\u00fcnglichen Ziele erreicht werden.<\/p>

Ein weiterer Pluspunkt:<\/strong> Die Arbeitselemente helfen dabei, herauszufinden, warum \u00c4nderungen vorgenommen wurden. Indem man an jeden Beitrag zur Pipeline eine Benutzeraufgabe anh\u00e4ngt, muss man sich nicht mehr an die \u00dcberlegungen erinnern, die zu einer bestimmten \u00c4nderung gef\u00fchrt haben.<\/p>

Wenn eine Pipeline-\u00c4nderung zu Problemen f\u00fchrt, wie z. B. einer falsch konfigurierten QA-Umgebung<\/strong>, kannst du einfach zur letzten bekannten funktionalen Version zur\u00fcckkehren. So wird deine QA-Umgebung innerhalb von Minuten wiederhergestellt.<\/p>

Der eigentliche Vorteil von YAML ist, dass Entwickler die Anwendung, die Infrastruktur, aber auch die Build- und Relax-Pipelines als Code in einem einzigen Versionsverwaltungs-Repository haben k\u00f6nnen. Dies bietet einen vollst\u00e4ndigen Snapshot des Systems f\u00fcr jeden beliebigen Zeitraum in der Vergangenheit.<\/p>

Wenn man eine \u00e4ltere Version des Repositoriums aufruft, kann man die Umgebung sehr einfach klonen, die gleichen Pipelines ausf\u00fchren<\/strong> und den Code genau so einsetzen, wie er damals war. Dies ist eine sehr n\u00fctzliche Funktion.<\/p>

Au\u00dferdem wird das Teilen oder Duplizieren einer Pipeline mit einem einfachen Kopieren und Einf\u00fcgen durchgef\u00fchrt. Dabei handelt es sich um einen einfachen Text, der sogar per E-Mail an einen Kollegen geschickt werden kann, wenn er wiederverwendet werden soll.<\/p>

CI\/CD-Pipelines<\/strong> sind breit und komplex, und \u00c4nderungen an derselben YAML-Datei, die von mehreren Ingenieuren vorgenommen werden, k\u00f6nnen zu Konflikten f\u00fchren. Gl\u00fccklicherweise l\u00f6sen Versionsverwaltungsplattformen dieses Problem, indem sie intuitive Werkzeuge zum Zusammenf\u00fchren von konfliktbehafteten \u00c4nderungen bereitstellen. YAML-Definitionen erm\u00f6glichen es daher mehreren Ingenieuren, gleichzeitig an derselben Datei zu arbeiten.<\/p>

Genau wie beim Anwendungscode ist auch bei Pipelines die Peer Review<\/strong> wichtig. Durch die M\u00f6glichkeit, eine Pull-Anfrage zu stellen, bevor neue \u00c4nderungen vorgenommen werden, k\u00f6nnen die Teammitglieder sicherstellen, dass die \u00c4nderungen den gew\u00fcnschten Effekt haben.<\/p>

Branching oder Verzweigung schlie\u00dflich erm\u00f6glicht es, einen neuen Zweig zu schaffen, um untypische Ideen auszuprobieren. Von diesem Zweig aus kann eine Pipeline-Ausf\u00fchrung gestartet<\/strong> und wieder gel\u00f6scht werden, wenn sich die Idee als erfolglos erweist.<\/p>

Die Einf\u00fchrung von vollst\u00e4ndig textbasierten Pipeline-Definitionen, die \u00fcber die Versionsverwaltung hinterlegt werden k\u00f6nnen, bringt Vorteile gegen\u00fcber den klassischen Definitionen, die auf einer grafischen Benutzeroberfl\u00e4che basieren. Dies gilt insbesondere f\u00fcr gro\u00dfe Organisationen, die gut daran tun, YAML f\u00fcr ihre n\u00e4chste Azure DevOps-Pipeline-Implementierung in Betracht zu ziehen…<\/p>\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t

\n\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t
<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t

Herk\u00f6mmliche Pipelines VS YAML: Der Vergleich<\/h3>\t\t\n\t\t

Klassische Pipelines<\/strong> werden \u00fcber eine Benutzeroberfl\u00e4che eingerichtet, indem du aus den angebotenen Optionen ausw\u00e4hlst. Dies gilt sowohl f\u00fcr Build- als auch f\u00fcr Relax-Pipelines.<\/p>

YAML-Pipelines wiederum werden mithilfe von Code in einer YAML-Datei konfiguriert. Der Azure DevOps Task Wizard<\/strong> kann dir dabei helfen, die ben\u00f6tigten Tasks zu finden und sie zur YAML-Datei hinzuzuf\u00fcgen.<\/p>

Es ist durchaus m\u00f6glich, eine Anwendung mithilfe von herk\u00f6mmlichen Pipelines zu erstellen und einzusetzen. YAML-Pipelines erm\u00f6glichen jedoch den Einsatz in verschiedenen Umgebungen.<\/p>

YAML-Pipelines vereinfachen die Zusammenarbeit und machen es leicht, mehrere Werte gleichzeitig zu \u00e4ndern. Es ist z. B. m\u00f6glich, das Suchwerkzeug einer IDE zu verwenden, um mehrere Vorkommen desselben Wertes zu finden und zu ersetzen.<\/p>

Ein Versionsverwaltungswerkzeug wie git<\/a> macht es auch sehr einfach, \u00c4nderungen zu vergleichen. Da sich die Pipeline in einer YAML-Datei im Repository befindet, ist es m\u00f6glich, eine alte Version der Pipeline zusammen mit einer alten Version des Code-Repositorys wiederherzustellen.<\/p>

YAML ist zur Standardoption f\u00fcr den Aufbau von Pipelines in Azure DevOps geworden, und die meisten CI\/CD-Tools sind mit dieser Sprache kompatibel<\/strong>. Au\u00dferdem sind Container-Jobs exklusiv f\u00fcr YAML-Pipelines.<\/p>

Andererseits kann dieser Ansatz mehr Zeit und Aufwand erfordern als herk\u00f6mmliche Pipelines. Beachte dennoch, dass der Job-Assistent eine wertvolle Hilfe ist und dass es m\u00f6glich ist, eine bestehende klassische Pipeline als YAML zu exportieren. Hierf\u00fcr sind jedoch mehrere Anpassungen erforderlich.<\/p>

Ein weiterer Schwachpunkt ist, dass einige Konfigurationen nicht in der Datei ge\u00e4ndert werden k\u00f6nnen. Die \u00c4nderungen m\u00fcssen \u00fcber die Benutzeroberfl\u00e4che vorgenommen werden, und die Option kann beim ersten Mal schwer zu finden sein.<\/p>

Schlie\u00dflich sind einige CD-Funktionen, die f\u00fcr Relax-Pipelines verf\u00fcgbar sind, noch nicht f\u00fcr YAML-Pipelines verf\u00fcgbar. Microsoft f\u00fcgt jedoch nach und nach neue Funktionen hinzu.<\/p>

Die klassischen Pipelines ihrerseits sind intuitiv und einfach zu bedienen. Es ist auch sehr einfach, die verschiedenen Optionen zu entdecken, indem man die Oberfl\u00e4che mit der Maus erkundet, ohne auch nur einen Blick in die Dokumentation werfen zu m\u00fcssen. Allerdings ist dies nicht mehr die Standardoption f\u00fcr den Aufbau von Pipelines f\u00fcr Azure DevOps.<\/p>

Zusammenfassend l\u00e4sst sich sagen, dass die Wahl zwischen der klassischen Pipeline und der YAML-Pipeline von deinen Bed\u00fcrfnissen abh\u00e4ngt. Achte darauf, zu analysieren, wie die Pipelines in Gang gesetzt werden und auf welchen Umgebungen die Anwendung bereitgestellt wird, wie die Verzweigungsstrategie funktioniert und wie sie sich auf den Bereitstellungsablauf auswirkt.<\/p>

Du solltest auch wissen, ob du eine einzige CI\/CD-Pipeline oder zwei separate Pipelines ben\u00f6tigst. Achte auch darauf, dass du deinen Workflow und deine Anforderungen kennst.<\/p>\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t

\n\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t
<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t

Wie erstellt man eine CI\/CD-Pipeline in YAML auf Azure DevOps?<\/h3>\t\t\n\t\t

Um eine CI\/CD-Pipeline in YAML auf Azure DevOps zu erstellen<\/strong>, beginne zun\u00e4chst damit, dich in ein Microsoft Azure-Konto einzuloggen, um Azure DevOps und Azure Pipelines zu nutzen.<\/p>

Erstelle ein Teamprojekt, das auf Basic, Agile, Scrum oder CMMI basiert, und erstelle dann eine Build-Pipeline<\/strong>. Du musst die Quelle des Codes angeben und die IDs, mit denen man sich mit dem Code verbinden kann. Dabei kann es sich z. B. um ein GitHub-Repository handeln.<\/a><\/p>

Nachdem du das Repository hinzugef\u00fcgt hast, erh\u00e4ltst du Vorschl\u00e4ge f\u00fcr Templates, die auf verschiedenen Sprachen wie Java<\/a> oder .Net basieren. W\u00e4hle ein Template aus, speichere die YAML-Datei (.yml) und aktiviere den Build. Es k\u00f6nnen beliebig viele Schritte und Jobs zur Pipeline hinzugef\u00fcgt werden.<\/p>

Der n\u00e4chste Schritt besteht darin, eine Relax-Definition hinzuzuf\u00fcgen und die Webanwendung auf dem Azure Web App Service bereitzustellen. W\u00e4hle auf der Registerkarte „Relaxes“ die Option „Neue Pipeline“ und w\u00e4hle die Vorlage f\u00fcr den App Service Deployment.<\/strong><\/p>

Du musst einen Web App Service auf Azure haben, um die Anwendung dort einzusetzen. Falls nicht, erstelle einen neuen \u00fcber das Azure-Portal.<\/p>

Um den Einsatz abzuschlie\u00dfen, m\u00fcssen die im Build erstellten Artefakte unbedingt ver\u00f6ffentlicht werden. Dies erfordert, dass du der YAML-Datei eine Aufgabe hinzuf\u00fcgst, um die Artefakte am Ende zu ver\u00f6ffentlichen.<\/p>

Bearbeite die Definition des Builds, gehe zum Ende der YAML-Datei, suche die Option zum Ver\u00f6ffentlichen von Build-Artefakten und klicke auf „Hinzuf\u00fcgen“. Speichere den Build und f\u00fchre ihn aus, damit die Artefakte ver\u00f6ffentlicht und zum Relaxen verwendet werden k\u00f6nnen.<\/p>

Es ist notwendig, den Build, aus dem die Artefakte stammen, f\u00fcr jede Relax-Definition bereitzustellen. Du musst daher die Aufgabe f\u00fcr den Azure App Service in der Relax-Definition<\/strong> einrichten und der Aufgabe erlauben, den erstellten Service mit deinem Azure-Konto zu nutzen. Speichere die Relax-Definition und erstelle eine Relax. Wenn die Bereitstellung abgeschlossen ist, solltest du die bereitgestellte Anwendung sehen.<\/p>

Bearbeite anschlie\u00dfend die Build-Definition, um den Schalter f\u00fcr die kontinuierliche Integration und den Schalter f\u00fcr die kontinuierliche Bereitstellung zu aktivieren. Klicke einfach auf die Ellipsen-Schaltfl\u00e4che und w\u00e4hle die Schalter aus. Aktiviere und speichere die Schalter f\u00fcr die Relax-Definition und \u00e4ndere den Code in GitHub, um sicherzustellen, dass beide Schalter wie gew\u00fcnscht funktionieren. Speichere die Pipeline ab.<\/p>

Anschlie\u00dfend kannst du die Build-Pipeline anpassen, indem du bei Bedarf Aufgaben hinzuf\u00fcgst oder bestehende Aufgaben \u00e4nderst. Insbesondere ist es m\u00f6glich, Variablen und Jobs hinzuzuf\u00fcgen.<\/p>\t\t\n\t\t\t

Wie kann man Azure DevOps-Experte werden?<\/h3>\t\t\n\t\t

Der Aufbau von Pipelines in YAML<\/strong> ist nur eine der vielen Feinheiten von Azure DevOps. Um zu lernen, diese Plattform zu beherrschen, kannst du dich an Liora wenden.<\/p>

In unserem Data Engineer-Kurs lernst du Techniken und Werkzeuge des Data Engineering kennen, darunter Python-Programmierung, CI\/CD, Datenbanken<\/strong>, Big Data, Machine Learning oder auch Automatisierung und Deployment.<\/p>

Wir bieten auch einen zertifizierenden Kurs f\u00fcr die Microsoft Azure Cloud an, der die Zertifizierungen AZ-104 Microsoft Azure<\/strong> Administrator und DP-203 Engineering on Microsoft erm\u00f6glicht. Beide Kurse k\u00f6nnen in nur f\u00fcnf Tagen absolviert werden.<\/p>

Alle unsere Kurse werden als Fernkurse, Intensiv-BootCamps oder Weiterbildungskurse durchgef\u00fchrt. Unsere Organisation ist staatlich anerkannt und kann \u00fcber den Bildungsgutschein finanziert werden. Entdecke Liora!<\/p>\t\t\n\t\t\t\n

Entdecke unsere Kurse<\/a><\/div><\/div>\n","protected":false},"excerpt":{"rendered":"

Die Sprache YAML erm\u00f6glicht es, CI\/CD-Pipelines auf Microsoft Azure DevOps in Form von Code zu konfigurieren. Erfahre, warum und wie du dich f\u00fcr diesen Ansatz entscheiden solltest und welche Vorteile er gegen\u00fcber dem klassischen Editor bietet! Durch das Hinzuf\u00fcgen von Pipelines zu seinem Cloud-Dienstleistungsangebot Azure DevOps hat Microsoft es erm\u00f6glicht, den Entwicklungsprozess um CI\/CD-Praktiken (Continuous […]<\/p>\n","protected":false},"author":76,"featured_media":187189,"comment_status":"open","ping_status":"open","sticky":false,"template":"elementor_theme","format":"standard","meta":{"_acf_changed":false,"editor_notices":[],"footnotes":""},"categories":[2476],"class_list":["post-187187","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-dev"],"acf":[],"_links":{"self":[{"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/posts\/187187","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/users\/76"}],"replies":[{"embeddable":true,"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/comments?post=187187"}],"version-history":[{"count":1,"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/posts\/187187\/revisions"}],"predecessor-version":[{"id":217094,"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/posts\/187187\/revisions\/217094"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/media\/187189"}],"wp:attachment":[{"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/media?parent=187187"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/categories?post=187187"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}