Die CI/CD-Integration ist die Verkabelung, die Ihre code-Repository mit einer automatischen Pipeline verbindet, sodass jede Änderung ohne manuelle Handlungen durch die Build-, Test- und Release-Stufen geht. Bis 2024, 83% der Entwickler wurden in DevOps-bezogenen Aktivitäten involviert, und die Verwendung von CI/CD-Werkzeugen war mit einer besseren Lieferleistung in Bezug auf die Auslieferungshäufigkeit, die Zeit bis zum Wiederherstellen der Dienstleistung, die Fehlerrate bei Änderungen und die Zeit bis zum Wiederherstellen der Dienstleistung verbunden gemäß dem State of CI/CD-Bericht der Cloud Native Computing Foundation.
Wenn Sie ein mobiles Team leiten, haben Sie wahrscheinlich das Gefühl, dass es einen Gap zwischen 'die Build ist erfolgreich' und 'die App ist sicher zum Versand' gibt. Ein Release kann in Slack aussehen, als wäre alles in Ordnung, und dann auseinanderbrechen, wenn jemand die richtige Signierungsdatei, die richtige Zweig, die richtige Store-Checkliste und die richtige Rollover-Route benötigt, um es um 23 Uhr zu schaffen. Das ist der Punkt, an dem die CI/CD-Integration nicht mehr ein Buzzword ist, sondern das Betriebssystem dafür, wie Ihr Team versendet.
Inhaltsverzeichnis
- Der Release-Tag, den Sie vergessen möchten
- CI und CD zerlegen
- Anatomie eines CI/CD-Pipelines
- Wie sich CI/CD für mobile und Desktop-Anwendungen unterscheidet
- Kernkomponenten, die die Integration ermöglichen
- Sicherheit und Compliance in der Pipeline
- Fehlersuche und Beobachtung nach der Live-Veröffentlichung
- Wo Sie Weitergehen auf Ihrer CI/CD-Reise
Der Tag der Veröffentlichung, den jeder vergessen möchte
Am Dienstagmorgen beginnt ein Hotfix, der eigentlich einfach sein sollte. Bis Freitagnacht sitzt der gleiche Patch immer noch in einem Zweig, weil die manuelle QA ein weiteres Problem gefunden hat, die Veröffentlichungsnotizen sind noch nicht fertig und drei Personen fragen in Slack, wer das letzte Build hat. Der aufgerufene Ingenieur läuft den Veröffentlichungsskript am 11 Uhr abends noch einmal durch, und niemand ist sich ganz sicher, ob das Artefakt im Staging mit dem im Quellcode übereinstimmt.
Das Chaos ist genau das, was die CI/CD-Integration beseitigen soll. Der Punkt ist nicht nur, einige Aufgaben zu automatisieren, sondern alle Quellcode-Verwaltung, Build-Server, Test-Runner, Artefakt-Depotund Ziel-Systeme für die Bereitstellung zum einen Fluss zu verbinden, damit jeder Commit auf eigene Faust vorankommt. Die Übersicht von Red Hat zu CI/CD beschreibt dies als einen automatisierten DevOps-Prozess, der häufig das Bauen, Testen, Scannen, Paketieren, Verteilen und Bereitstellen umfasst.
Was bricht, wenn die Verkabelung fehlt
Wenn Teams CI/CD als ein einzelnes Werkzeug behandeln, erhalten sie normalerweise nur eine teilweise Automatisierung und behalten die gefährlichen Handlungen bei. Code wird integriert, aber jemand muss dennoch den Build starten. Der Build ist abgeschlossen, aber ein Mensch muss das Artefakt irgendwo kopieren. Die Staging-Veröffentlichung funktioniert, aber die Produktion benötigt einen anderen Skript, ein anderes Konto und einen anderen Menschen, der sich daran erinnert, wie alles zusammenpasst.
Praktische Regel: Wenn eine Veröffentlichung von der Erinnerung, Nebenverhandlungen oder „dem Menschen, der das Skript kennt“, abhängt, ist der Pipeline noch nicht integriert.
Der Bericht der Cloud Native Computing Foundation aus dem Jahr 2024 warnt auch davor, dass die Verwendung mehrerer Werkzeuge desselben Typs die Lieferleistung schädigen kann, weil die Interoperabilität schwieriger wird Zustand von CI/CD-BerichtDas ist wichtig in großen Teams, weil Integration nicht darum geht, mehr Werkzeuge zu besitzen, sondern darum, dass die Werkzeuge sich auf die gleiche Wahrheit einigen.
Ein gesunder CI/CD-Einrichtung gibt dir einen Weg von Commit zu Benutzern. Ein schwacher gibt dir eine Sammlung von Inseln, jede mit ihrem eigenen manuellen Brücke. Die Differenz zeigt sich am schnellsten an Veröffentlichungstag, genau wenn das Team am wenigsten Zeit für Verwirrung hat.
Zerlegung von CI und CD
Aufteilung der Ideen erleichtert das Verständnis eines Release-Workflows erheblich. CI CI konzentriert sich auf die automatische Überprüfung kleiner Änderungen, die häufig vorgenommen werden. CD CD konzentriert sich darauf, validierte code bereitzustellen, um sie dann zu entscheiden, ob die Produktion diese code mit oder ohne eine manuelle Genehmigungsstufe erhält.
CI ist die Vorbereitungsstation
Die kontinuierliche Integration beginnt mit einer einfachen Gewohnheit: Halten Sie Änderungen klein und überprüfen Sie sie sofort. In Software-terms löst jeder Commit oder Merge-Request automatisierte Überprüfungen aus, damit beschädigte code nicht bis zu einer großen Release-Veröffentlichung herumliegen.
Die Definition von CI aus dem Leitfaden von Red Hat zur CI/CD entspricht diesem Modell. CI ist die automatisierte Build- und Test-Discipline, die Integrationsschwierigkeiten frühzeitig aufdeckt. Kleine Änderungen sind leichter zu überprüfen, und wenn etwas fehlschlägt, kann das Team ohne Vermutungen zurückverfolgen, welcher Teil der Veröffentlichung das Problem verursacht hat.
CD hat zwei Bedeutungen, und Teams vermischen sie
Kontinuierliche Lieferung bedeutet, dass das code immer bereit ist, aber eine Person entscheidet immer noch, wann die Produktion stattfindet. Kontinuierliche Bereitstellung geht einen Schritt weiter und schickt jede erfolgreiche Änderung automatisch. Diese Unterscheidung ist für Compliance, Risikotoleranz und die Art der Release-Kontrolle wichtig, die mobile und Desktop-Teams normalerweise benötigen.
Ein Release-Manager auf einem Verbraucher-App mag kontinuierliche Lieferung bevorzugen, weil der Zeitpunkt des Stores noch koordiniert werden muss. Ein Backend-Team mit starken automatisierten Überprüfungen kann für low-Risiko-Dienste kontinuierliche Bereitstellung wählen. Die richtige Wahl hängt von der Governance und nicht von Slogans ab.
Für Teams, die versuchen, die CI-Seite zu stärken, bevor sie die Releases automatisieren, dieser CI-fokussierte Leitfaden ist ein nützlicher Begleiter. Er hält den Fokus auf die Integrationqualität, die ist, wo die Verlässlichkeit der Releases beginnt.
| CI/CD-Stufen Vergleich über Web, Mobile und Desktop | Web-Anwendung | CapacitorJS Mobile | Elektron Desktop |
|---|---|---|---|
| Trigger | Push oder Merge-Anfrage startet die Validierung | Push oder Merge-Anfrage startet die Validierung | Push oder Merge-Anfrage startet die Validierung |
| Erstellen | Bündele die App | Bündele die Web-code, dann hüll es in eine native Shell | Kompiliere Haupt- und Renderer-code, dann paketiere die Desktop-App |
| Testen | Einheiten-, Integrations- und Benutzeroberflächentests | Fügen Sie mobile-spezifische Überprüfungen für die Wrapper- und Laufzeitverhalten hinzu | Fügen Sie desktop-spezifische Überprüfungen für die Verpackung und den Startpfad der App hinzu |
| Veröffentlichen | Deployen Sie auf einen Host oder eine App-Laufzeitumgebung | Veröffentlichen Sie in Store-Kanäle oder Live-Update-Kanäle | Veröffentlichen Sie Installationsprogramme oder Live-Update-Kanäle |
| Zustimmung | Optionale menschliche Schleusen | Oft benötigt für den Speicher- und Rollback-Kontrol | Oft benötigt für die Signierung- und Verteilungskontrol |
Anatomie eines CI/CD Pipelines
Ein Pipeline ist einfach ein Graph von Aufgaben mit Eingängen und Ausgängen. Sobald ein Entwickler code pusht, wird ein Webhook oder ein Merge-Ereignis die erste Aufgabe auslöst, dann die nächste Aufgabe verbraucht das Artefakt aus dieser Phase und so weiter, bis das Release bereit ist. Deshalb ist die CI/CD-Integration eigentlich ein Vertragsverhältnis zwischen den Phasen, nicht ein mysteriöses Plattformmerkmal.
Was jede Phase tut
Der Quellcode-Trigger startet den Fluss. Build-Aufgaben kompilieren den code und lösen Abhängigkeiten, wobei sich viele versteckte Fehler zeigen. Test-Aufgaben führen dann Einheitstests, Integrations- und UI-Prüfungen durch, während Sicherheitsprüfungen nach verletzlichen Paketen oder unsicheren Konfigurationen suchen.
Eine gute Pipeline scheitert schnell und sagt dir genau, wo sie gescheitert ist.
Dann wird das Paketieren das überprüfte Ergebnis in etwas Bereitstellbares umwandelt, wie z.B. eine Container-Image, eine signierte APK oder IPA, ein Electron-Distributable oder ein JavaScript-Bundle. Der HCL-Zusammenfassung der CI/CD-Einführung und -Umsetzung ist hier nützlich, weil sie zeigt, wie Teams oft bei der halben Automatisierung aufhören. Viele Teams haben einen Pipeline, aber nicht jede Phase ist vollständig vernetzt.
Warum die Grenzen der Phasen wichtig sind
Wenn Sie die Artefakte bei jeder Übergabe nicht benennen können, wird das Debugging zum Raten. Wenn eine Veröffentlichung in der Staging-Umgebung fehlschlägt, müssen Sie wissen, ob das Problem aus der Abhängigkeitserfassung, einem flüchtigen Test, einer Sicherheitspolitik oder der Verpackung kam. Das ist auch der Grund, warum eine gute Pipeline-Design eine interne Spur von der Commit bis zum Artefakt bis zur Umgebung beinhaltet.
Für Teams, die eine praktische Sicht davon wollen, wie der Build-Teil in den größeren Fluss passt dieser build-fokussierte Leitfaden ist einen Blick wert. Er hilft dabei, zu trennen, was die Build-Phase besitzt, und was die Release-Orchestrierung besitzt.
Wie CI/CD sich für mobile und Desktop-Anwendungen unterscheidet
Web-Pipelines täuschen die Leute in die Irre, indem sie denken, dass CI/CD hauptsächlich darum geht, eine Bundle auf einen Server zu pushen. Die native Lieferung ändert die Regeln schnell. Mit CapacitorJSbauen Sie noch immer Web-code, aber Sie packen es auch in eine native Hülle ein, dann verwalten Sie das Signieren und die plattform-spezifischen Veröffentlichungspfade. Mit Electronkompilet die Anwendung für Desktop-Umgebungen, dann packen Sie Installationsprogramme oder Distributables für die unterstützten Betriebssysteme ein.
Was ändert sich, wenn die App auf Geräten ausgeliefert wird
Mobile-Teams müssen sich mit Signierungsschlüsseln, App-Store- und Play-Review und Runtime-Update-Kanälen beschäftigen. Desktop-Teams hingegen mit Installern, code-Signierung und Updateverhalten über Plattformen. Das gemeinsame Muster ist klar, die code-Möglichkeit, dass die Anwendung durch denselben Repository und Build-Trigger reisen kann, ist jedoch unterschiedlich.
Die GitHub-Richtlinien zur Verbesserung von CI/CD-Pipelines deuten auf eine schrittweise Prüfung, Feature-Flags und Rollback-Überprüfungen hin, was sich gut in diese Welt einfügt. Diese Praktiken sind in diesem Zusammenhang wichtiger, wenn eine Build innerhalb eines Wrapper oder Installers lebt, weil die Veröffentlichung nicht nur „kompiliert code“, sondern „verhält sich diese Pakete sicher auf echten Geräten“
Was mobile und desktop-Teams hinzufügen
Eine Web-Veröffentlichung kann oft bei Staging oder Produktions-Deployen aufhören. Eine mobile Veröffentlichung benötigt jedoch oft einen zusätzlichen Schritt für Kanäle, Genehmigungen und Rollback-Verhalten. Electron-Teams benötigen denselben Disziplin, aber mit Desktop-Paketierung und Update-Verteilung anstatt App-Store-Submission.
- CapacitorJS mobile: Web-Bundle, native Wrapper, Signierung, Store-Review und Live-Update-Kanäle
- Electron desktop: Main-Prozess-Build, Renderer-Build, verpackter Installer, Signierung und Update-Kanal-Steuerung
- Web-Anwendung: Erstellen, testen, paketieren, bereitstellen und überwachen
Dort ist der Punkt, an dem lebendige Aktualisierungssysteme Teil des CI/CD werden, anstatt ein Nebenprojekt zu sein. Wenn Ihr Build ein Bundle produzieren kann, muss Ihr Release-System immer noch entscheiden, wie es sicher an die Benutzer gelangt.
Kernkomponenten, die die Integration ermöglichen
Auslöser, Pipelines, Artefakte und Umgebungen sind die vier Teile, die Teams hart wiederholen müssen. Ein Auslöser ist das Ereignis, das den Job startet, meist ein Git-Push oder ein Merge-Request. Ein Pipeline ist die geordnete Menge von Jobs. Ein Artefakt ist die verifizierte Ausgabe. Eine Umgebung ist der Ort, an dem diese Ausgabe vorangebracht oder zurückgehalten wird.
Die vier Teile in einfachen Worten
Auslöser sind der Handshake zwischen Git und Automation. Pipelines definieren die Regeln der Bewegung, erstellen zuerst, dann testen, dann scannen, dann paketieren und dann bereitstellen. Artefakte tragen das Ergebnis dieser Arbeit weiter vor, daher sollte das gleiche Bundle getestet und bereitgestellt werden.
Umgebungen geben Ihnen einen sicheren Ort, um Absicht von Auswirkung zu trennen. Dev, Staging, Beta und Produktionsumgebungen tun hier echte Arbeit. Sie lassen das Team einen Änderung in einem Ort beweisen, bevor Benutzer von ihr in einem anderen Ort abhängig sind.
Regel des Daumens: Wenn eine Umgebung nicht auf einen Commit und ein Artefakt zurückverfolgt werden kann, ist sie ein Risiko, nicht ein Sicherheitsnetz.
Wo Capgo in einem lebendigen Aktualisierungsfluss passt
For CapacitorJS und Electron-Apps sitzt Capgo im Live-Update-Schicht, wo signierte Web-Bundles an Kanäle veröffentlicht werden können, Updates differential sein können und Rollbacks die Geräte auf den letzten bekannten guten Bundle zurücksetzen können. Das macht den Pipeline mehr als einen binären Release-Weg. Es wird ein Release-Control-Plane für Web-Assets innerhalb von native Apps.
Capgo’s Pipeline-Integrations für Systeme wie GitHub Actions, GitLab CI/CD, Azure DevOps und Bitbucket Pipelines sind in eigenen Materialien dokumentiert und werden verwendet, um Build- und Deploy-Flows von CI in channel-basierte Releases zu automatisieren. Wenn Sie Release-Tooling gegen Job-Aufgaben oder Plattform-Expectations vergleichen, werden Sie auch sehen, dass Senior-Teams oft Ingenieure wollen, die über End-to-End-Integrations nachdenken können, nicht nur Build-Skripte. Ein konkreter Beispiel ist die Coinbase-Software-Ingenieur-Integrationsrolle auf Blockchain Jobs , die zeigt, wie viel Release-Plumbing in realen Organisationen zählt.Fur Geheimnisse-Handling
__CAPGO_KEEP_0__’s Leitfaden zum Management von Geheimnissen in CI/CD Pipelines Capgo’s guidance on managing secrets in CI/CD pipelines Sicherheit und Compliance in der Pipeline
Sicherheit in CI/CD ist ein Kontrollproblem, nicht ein Checkbox. Die US-Verteidigungsrichtlinien für CI/CD-Umgebungen behandeln die Pipeline als geschützten Weg, der die Repository, das Build-System, die Anmeldeinformationen und den Artefakt-Route end-to-end sicherstellen muss.
__CAPGO_KEEP_1__ Actions Richtlinien zur Verteidigung von CI/CD-Umgebungen. Das ist auch für Produktteams nützlich, weil der schnellste Pipeline der ist, den man vertraut.
Steuerungen, die innerhalb des Flusses gehören
Kurzlebige Anmeldeinformationen reduzieren den Schaden, wenn ein Token austritt. Signierte Artefakte helfen dabei, zu beweisen, dass das Bundle oder die Binärdatei von der erwarteten Pipeline stammt. SBOM- und SCA-Überprüfungen offenbaren die Abhängigkeitsrisiken vor der Veröffentlichung, und Audit-Protokolle machen jede Aktion nachvollziehbar, wenn ein Rezensent fragt, was geändert wurde und wer es genehmigt hat.
Der Richtlinien von CISA und DHS zur Verteidigung von CI/CD-Pipelines unterstreichen, dass Sicherheitsüberprüfungen, Protokollierung, signierte Konfiguration und reduzierte Anmeldeinformationen in der Pipeline selbst gehören. Das ist der richtige mentale Ansatz für regulierte Teams in Fintech, Gesundheitswesen und E-Commerce. Die Einhaltung von Vorschriften ist nicht etwas, das man nachträglich hinzufügt, sondern Teil des Veröffentlichungswegs.
Eine Veröffentlichung sollte nach der Sicherheit noch schnell sein
Teams panikieren normalerweise und stellen sich vor, dass es eine Menge manueller Schranken gibt. Das ist nicht notwendig. Die Politik kann in der Pipeline leben, die Genehmigung kann auf die richtigen Umgebungen beschränkt werden und die Überprüfungen können automatisch durchgeführt werden, ohne dass jede Veröffentlichung zu einer Besprechung wird.
Einige Teams wählen auch Plattformen, die signierte Bundles als Teil des Lieferketten veröffentlichen, was die Integritätsprüfungen von der Erstellung bis zum Gerät erhalten bleibt. Für eine tiefergehende Betrachtung der praktischen Seite davon dieses CI/CD-Sicherheitsleitfaden ist ein nützlicher Referenzpunkt. Die Hauptidee bleibt gleich, die Sicherheit gehört in das Lieferungssystem, nicht drumherum.
Fehlerbehebung und Beobachtung nach der Live-Veröffentlichung
Ein unsichtbarer Pipeline ist ein unzuverlässiger Pipeline. Ein fehlgeschlagener Build stellt normalerweise eine einfache Frage, an welchem Punkt es gebrochen ist. Ein schlechter Release stellt eine schwierigere Frage, ob der Fehler aus der Verpackung, dem Umgebungsdrift oder der Aktualisierung selbst kam. Das bedeutet, dass die Beobachtung den Buildweg und den lebenden Veröffentlichungsweg abdecken muss, da beide Probleme einführen können, die ähnlich aussehen.
Die wichtigsten Signale
Build-Protokolle sagen Ihnen, welches Job fehlgeschlagen ist. Test-Flak-Patterns zeigen Ihnen, ob das Problem im code oder in der Infrastruktur um es herum liegt. Die Bereitstellungsgesundheit sagt Ihnen, ob eine Veröffentlichung sauber durch die Tore gegangen ist. Die DORA-Linsen aus dem CNCF-Bericht, die Bereitstellungshäufigkeit, der Zeitraum bis zum Wiederherstellen der Dienstleistung, die Fehlerquote bei Änderungen und die Zeit bis zum Wiederherstellen der Dienstleistung, geben den Teams immer noch einen praktischen Weg, um zu beurteilen, ob das System hilft. Zustand des CI/CD-Berichts.
Wenn Sie nicht in wenigen Minuten antworten können, was geändert wurde, wo und auf welchen Geräten, ist Ihre Beobachtung für ein Live-Update-Workflow zu flach.
Was zu überprüfen ist, wenn eine Veröffentlichung schief geht
Beginnen Sie damit, die fehlgeschlagene Veröffentlichung mit der Commit-Geschichte zu korrelieren. Dann überprüfen Sie die Test- und Bereitstellung-Protokolle für die Stufe, die den Fehler eingeführt hat. Bei lebenden Updates ist die Geräteebene wichtig, weil der gleiche Bundle unterschiedlich auf verschiedenen Gerätetypen, Betriebssystemversionen oder App-Zuständen verhält sich.
Capgo’s Geräteprotokolle, Akzeptanzmetriken, Versionsgeschichte und Kanalwächter sind für solche Zwischenfälle konzipiert. Für Warnungen zeigt Capgo’s Anleitung zur Hinzufügung von Warnungen in CI/CD-Pipelines, wie man diese Signale in Benachrichtigungen umwandeln kann, anstatt auf die Benutzer zu warten, die das Problem melden. Capgo’s guide on adding alerts to CI/CD pipelines Die CI/CD-Integration ist ein Reifegrad, nicht ein Kästchen. Die Teams, die sicher liefern, haben normalerweise die Grundlagen miteinander verbunden, dann Sicherheit, Release-Orchestrierung und Rollback-Discipline hinzugefügt. Die Teams, die nervös liefern, haben die Automatisierung in Teilen, aber nicht einen verbundenen Fluss.
Eine Diagramm, das die drei Reifegrade einer CI/CD-Reifegradreise von grundlegend bis fortgeschritten darstellt.
Ein schneller Selbsttest hilft. Sind Trigger automatisch? Sind Artefakte signiert? Kann man eine Bereitstellung zurückverfolgen bis zu einem Commit? Hat man eine Rollback-Politik, die jemand unter Druck ausführen kann? Wenn die Antwort auf eine dieser Fragen unscharf ist, ist die nächste Verbesserung offensichtlich.
__CAPGO_KEEP_0__ hilft den Teams, CI/CD in Echtzeit-Update-Lieferungen für CapacitorJS- und Electron-Anwendungen einzubinden, sodass signierte Pakete, gezielte Kanäle und Rollback-Schutz Teil des gleichen Release-Flusses werden. Wenn Ihr Team versucht, von manuellen Releases zu einem kontrollierten Update-System zu wechseln, besuchen Sie __CAPGO_KEEP_0__
__CAPGO_KEEP_0__’s Geräteprotokolle, Akzeptanzmetriken, Versionsgeschichte und Kanalwächter sind für solche Zwischenfälle konzipiert. Für Warnungen zeigt __CAPGO_KEEP_0__’s Anleitung zur Hinzufügung von Warnungen in CI/CD-Pipelines, wie man diese Signale in Benachrichtigungen umwandeln kann, anstatt auf die Benutzer zu warten, die das Problem melden.
Capgo helps teams wire CI/CD into live update delivery for CapacitorJS and Electron apps, so signed bundles, targeted channels, and rollback protection become part of the same release flow. If your team is trying to move from manual releases to a controlled update system, visit Die CI/CD-Integration ist ein Reifegrad, nicht ein Kästchen. Die Teams, die sicher liefern, haben normalerweise die Grundlagen miteinander verbunden, dann Sicherheit, Release-Orchestrierung und Rollback-Discipline hinzugefügt. Die Teams, die nervös liefern, haben die Automatisierung in Teilen, aber nicht einen verbundenen Fluss. Die drei Reifegrade einer CI/CD-Reifegradreise von grundlegend bis fortgeschritten. Ein schneller Selbsttest hilft. Sind Trigger automatisch? Sind Artefakte signiert? Kann man eine Bereitstellung zurückverfolgen bis zu einem Commit? Hat man eine Rollback-Politik, die jemand unter Druck ausführen kann? Wenn die Antwort auf eine dieser Fragen unscharf ist, ist die nächste Verbesserung offensichtlich. Behandeln Sie die Pipeline wie ein Produkt, nicht wie eine Sammlung von Skripten. Verengen Sie den Feedbackschleifen, fügen Sie Politik an den Orten hinzu, an denen Risiken leben, und erweitern Sie die Lieferung in Echtzeit-Update-Kanäle, wenn die Anwendungsarchitektur es benötigt. Capgo hilft den Teams, CI/CD in Echtzeit-Update-Lieferungen für CapacitorJS- und Electron-Anwendungen einzubinden, sodass signierte Pakete, gezielte Kanäle und Rollback-Schutz Teil des gleichen Release-Flusses werden. Wenn Ihr Team versucht, von manuellen Releases zu einem kontrollierten Update-System zu wechseln, besuchen Sie Capgo und sehen Sie, wie es in Ihr Pipeline passt.
