Teilen über

Bereitstellungstechnologien in Azure Functions

  • Artikel

Ihnen stehen verschiedene Technologien zur Verfügung, um Code aus Azure Functions-Projekten in Azure bereitzustellen. Dieser Artikel bietet eine Übersicht über die für Sie verfügbaren Bereitstellungsmethoden sowie Empfehlungen für in den jeweiligen verschiedenen Szenarien zu verwendende beste Methode. Außerdem finden Sie hier eine vollständige Liste der zugrunde liegenden Bereitstellungstechnologien und ihrer wichtigsten Details.

Bereitstellungsmethoden

Welche Bereitstellungstechnologie Sie zum Veröffentlichen von Code in Ihrer Funktions-App in Azure verwenden, hängt von Ihren spezifischen Anforderungen und dem Zeitpunkt im Entwicklungszyklus ab. Beispielsweise können Sie während der Entwicklung und während Tests direkt aus Ihrem Entwicklungstool bereitstellen, z. B. Visual Studio Code. Wenn sich Ihre App in der Produktionsphase befindet, verwenden Sie zur kontinuierlichen Veröffentlichung wahrscheinlich eher die Quellcodeverwaltung oder eine automatisierte Veröffentlichungspipeline, die zusätzliche Validierungs- und Testvorgänge umfassen kann.

In der folgenden Tabelle werden die verfügbaren Bereitstellungsmethoden für Ihr Codeprojekt beschrieben.

Bereitstellungstyp Methoden Am besten geeignet für:
Toolsbasiert • Veröffentlichung in Visual Studio Code
• Veröffentlichung in Visual Studio publish
• Veröffentlichung in Core Tools		 Bereitstellungen während der Entwicklung und andere improvisierte Bereitstellungen. Zur Bereitstellung Ihres Codes verwenden Sie bei Bedarf lokale Entwicklungstools.
Von App Service verwaltet • Bereitstellungscenter (CI/CD)
• Containerbereitstellungen		 Continuous Deployment (CI/CD) aus der Quellcodeverwaltung oder aus einer Containerregistrierung. Bereitstellungen werden von der App Service-Plattform (Kudu) verwaltet.
Externe Pipelines • Azure Pipelines
• GitHub Actions		 Produktionspipelines, die Validierungs- und Testvorgänge sowie weitere Aktionen umfassen, die im Rahmen einer automatisierten Bereitstellung ausgeführt werden müssen. Bereitstellungen werden von der Pipeline verwaltet.

Bestimmte Bereitstellungen sollten für jedes Szenario die jeweils beste Technologie nutzen. Viele Bereitstellungsmethoden basieren auf der ZIP-Bereitstellung, die für die Bereitstellung empfohlen wird.

Bereitstellungstechnologie: Verfügbarkeit

Die Bereitstellungsmethode hängt auch von Ihrem Hostingplan sowie von dem Betriebssystem ab, unter dem Sie Ihre Funktions-App ausführen.

Derzeit bietet Functions fünf Optionen zum Hosten Ihrer Funktions-Apps:

Jeder Plan weist ein anderes Verhalten auf. Nicht alle Bereitstellungstechnologien sind für jeden Hostingplan und jedes Betriebssystem verfügbar. Im folgenden Diagramm finden Sie Informationen zu den unterstützten Bereitstellungstechnologien:

Bereitstellungstechnologie Flex-Verbrauch Verbrauch Elastic Premium Dediziert Container-Apps
OneDeploy ✔
ZIP-Bereitstellung ✔ ✔ ✔
Externe Paket-URL1 ✔ ✔ ✔
Docker-Container Nur Linux Nur Linux Nur Linux ✔
Quellcodeverwaltung Nur Windows ✔ ✔
Lokales Git1 Nur Windows ✔ ✔
FTPS1 Nur Windows ✔ ✔
Bearbeitung im Portal2 ✔ ✔ ✔

1 Bereitstellungstechnologien, die eine manuelle Synchronisierung von Triggern erfordern, werden nicht empfohlen.
2 Die Bearbeitung im Portal ist deaktiviert, wenn Code von außerhalb des Portals in Ihrer Funktions-App bereitgestellt wird. Weitere Informationen, einschließlich Details zur Sprachunterstützung für die Bearbeitung im Portal, finden Sie unter Sprachunterstützungsdetails.

Wichtige Begriffe

Einige Schlüsselkonzepte sind wichtig, um zu verstehen, wie Bereitstellungen in Azure Functions funktionieren.

Triggersynchronisierung

Wenn Sie einen Trigger ändern, muss die Infrastruktur von Functions über die vorgenommenen Änderungen informiert werden. Die Synchronisierung erfolgt bei vielen Bereitstellungstechnologien automatisch. Manchmal müssen die Trigger jedoch manuell synchronisiert werden.

Sie müssen Trigger manuell synchronisieren, wenn Sie diese Bereitstellungsoptionen verwenden:

Trigger können auf die folgenden Arten synchronisiert werden:

  • Neustarten der Funktions-App über das Azure-Portal.

  • Verwenden Sie den Befehl az rest, um eine HTTP POST-Anforderung zu senden, die die syncfunctiontriggers-API aufruft, wie im folgenden Beispiel gezeigt:

    az rest --method post --url https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<APP_NAME>/syncfunctiontriggers?api-version=2016-08-01

Wenn Sie eine aktualisierte Version des Bereitstellungspakets bereitstellen und dieselbe URL des externen Pakets verwalten, müssen Sie die Funktions-App manuell neu starten. Dies gibt an, dass der Host Ihre Updates über dieselbe Paket-URL synchronisieren und erneut bereitstellen soll. Der Funktionshost führt auch eine Hintergrundtriggersynchronisierung aus, nachdem die Anwendung gestartet wurde. Für die Hostingpläne „Verbrauch“ und „Elastic Premium“ sollten Sie jedoch auch in diesen Szenarios manuell Trigger synchronisieren:

  • Bereitstellungen mit einer URL des externen Pakets entweder mit ARM-Vorlagen oder Terraform
  • Beim Aktualisieren des Bereitstellungspakets mit derselben URL des externen Pakets

Remotebuild

Sie können Azure Functions anweisen, während der Bereitstellung einen Remotebuild Ihres Codeprojekts auszuführen. In diesen Szenarien sollten Sie einen Remotebuild anfordern, anstatt lokal zu erstellen:

  • Sie stellen eine App in einer Linux-basierten Funktions-App bereit, die auf einem Windows-Computer entwickelt wurde. Dies ist bei der Entwicklung von Python-Apps gängige Praxis. Beim lokalen Erstellen des Bereitstellungspakets unter Windows können die falschen Bibliotheken verwendet werden.
  • Ihr Projekt verfügt über Abhängigkeiten zu einem benutzerdefinierten Paketindex.
  • Sie möchten die Größe Ihres Bereitstellungspakets verringern.

Wie Sie einen Remotebuild anfordern, hängt davon ab, ob Ihre App in Azure unter Windows oder Linux ausgeführt wird.

Alle Funktions-Apps, die unter Windows ausgeführt werden, enthalten eine kleine Verwaltungs-App, die von Kudu bereitgestellte scm Website. Auf dieser Website wird ein Großteil der Bereitstellungs- und Buildlogik für Azure Functions verarbeitet.

Bei der Bereitstellung einer App unter Windows werden sprachspezifische Befehle, z. B. dotnet restore (C#) oder npm install (JavaScript) ausgeführt.

Die folgenden Überlegungen gelten für die Verwendung von Remotebuilds während der Bereitstellung:

  • Remotebuilds werden für Funktions-Apps unterstützt, die unter Linux im Verbrauchsplan ausgeführt werden. Die Bereitstellungsoptionen sind jedoch für diese Apps eingeschränkt, da sie keine (Kudu)-Website haben scm.
  • Funktions-Apps, die unter Linux mit einem Premium-Plan oder einen Dedicated-Plan (App Service) ausgeführt werden, verfügen über eine scm-Website (Kudu), sind aber im Vergleich zu Windows eingeschränkt.
  • Remotebuilds werden nicht ausgeführt, wenn eine App run-from-package verwendet. Wie Sie in diesen Fällen Remotebuilds verwenden können, erfahren Sie unter Zip-Bereitstellung.
  • Bei der Verwendung eines Remotebuilds können Probleme auftreten, wenn Ihre App erstellt wurde, bevor die Funktion verfügbar gemacht wurde (1. August 2019). Erstellen Sie für ältere Apps entweder eine neue Funktions-App, oder führen Sie az functionapp update --resource-group <RESOURCE_GROUP_NAME> --name <APP_NAME> aus, um Ihre Funktions-App zu aktualisieren. Dieser Befehl kann zwei Versuche in Anspruch nehmen, bis er erfolgreich ist.

App-Inhaltsspeicher

Bei paketbasierten Bereitstellungsmethoden wird das Paket in dem Speicherkonto gespeichert, das der Funktions-App zugeordnet ist. Dies wird in der Einstellung AzureWebJobsStorage definiert. Sofern verfügbar, versuchen Apps mit einem Verbrauchs- und Elastic Premium-Plan, die Inhaltsfreigabe von Azure Files von diesem Konto zu verwenden. Sie können das Paket aber auch an einem anderen Speicherort verwalten. Apps mit Flex-Verbrauchs-Plan verwenden stattdessen einen Speichercontainer im Standardspeicherkonto, sofern Sie nicht ein anderes Speicherkonto für die Bereitstellung konfigurieren. Weitere Informationen finden Sie unter Speicherort von App-Inhalten zu den einzelnen Bereitstellungstechnologien, die im nächsten Abschnitt behandelt werden.

Wichtig

Das Speicherkonto wird verwendet, um wichtige App-Daten zu speichern, manchmal einschließlich des Anwendungscodes. Sie sollten den Zugriff von anderen Anwendungen und Benutzer*innen auf das Speicherkonto beschränken.

Bereitstellungstechnologie: Details

Die folgenden Bereitstellungsmethoden sind in Azure Functions verfügbar.

OneDeploy

OneDeploy (eine Bereitstellung) ist die einzige Bereitstellungstechnologie, die für Apps mit Flex-Verbrauchs-Plan unterstützt wird. Das Endergebnis ist ein ausführungsbereites ZIP-Paket, in dem Ihre Funktions-App ausgeführt wird.

Verwendung: Verwenden Sie für die Bereitstellung das Veröffentlichungsfeature von Visual Studio Code oder an der Befehlszeile die Azure Functions Core Tools bzw. die Azure-Befehlszeilenschnittstelle. Die Azure DevOps-Aufgabe und GitHub Actions nutzen OneDeploy auf ähnliche Weise, wenn sie erkennen, dass eine Flex-Verbrauchs-App bereitgestellt wird.

Wenn Sie eine Flex-Verbrauchs-App erstellen, müssen Sie einen Speichercontainer (Blob) für die Bereitstellung sowie eine Authentifizierungsmethode angeben. Standardmäßig wird dasselbe Speicherkonto wie für die AzureWebJobsStorage-Verbindung verwendet, wobei als Authentifizierungsmethode eine Verbindungszeichenfolge verwendet wird. Daher werden Ihre Bereitstellungseinstellungen während der App-Erstellung konfiguriert, ohne dass Anwendungseinstellungen erforderlich sind.

Anwendungsfälle: OneDeploy ist die einzige Bereitstellungstechnologie, die für Funktions-Apps verfügbar ist, die mit Flex-Verbrauchs-Plan ausgeführt werden.

Speicherort von App-Inhalten: Wenn Sie eine Funktions-App mit Flex-Verbrauchs-Plan erstellen, geben Sie einen Speichercontainer für die Bereitstellung an. Dies ist ein Blobcontainer, in dem die Plattform die bereitgestellten App-Inhalte hochlädt. Um den Speicherort zu ändern, verwenden Sie das Blatt „Bereitstellungseinstellungen“ im Azure-Portal oder die Azure-Befehlszeilenschnittstelle.

ZIP-Bereitstellung

Die ZIP-Bereitstellung ist die empfohlene Bereitstellungstechnologie und die Standardtechnologie für Funktions-Apps mit Verbrauchs-, Elastic Premium- und App Service-Plan (Dedicated). Das Endergebnis ist ein ausführungsbereites ZIP-Paket, in dem Ihre Funktions-App ausgeführt wird. Es unterscheidet sich von der URL des externen Pakets darin, dass die Plattform für die Remoteerstellung und das Speichern Ihrer App-Inhalte verantwortlich ist.

Verwendung: Führen Sie die Bereitstellung mithilfe Ihres bevorzugten Clienttools aus: Visual Studio Code, Visual Studio oder über die Befehlszeile mithilfe der Azure Functions Core Tools oder der Azure-Befehlszeilenschnittstelle. Die Azure DevOps-Aufgabe und GitHub Actions nutzen die ZIP-Bereitstellung auf ähnliche Weise.

Wenn die Bereitstellung mithilfe der ZIP-Bereitstellung erfolgt, können Sie die App auf Run from Package (Aus Paket ausführen) festlegen. Zur Ausführung über ein Paket legen Sie den Wert der Anwendungseinstellung WEBSITE_RUN_FROM_PACKAGE auf 1 fest. Wir empfehlen die ZIP-Bereitstellung. Sie führt zu schnelleren Ladezeiten für Ihre Anwendungen und ist die Standardeinstellung für VS Code, Visual Studio und die Azure CLI.

Anwendungsfälle: Die ZIP-Bereitstellung ist die empfohlene Bereitstellungstechnologie und die Standardtechnologie für Funktions-Apps mit Verbrauchs-Plan (unter Windows) bzw. mit Elastic Premium- und App Service-Plan (Dedicated) unter Windows und Linux.

Speicherort von App-Inhalten: App-Inhalte aus einer ZIP-Bereitstellung werden standardmäßig im Dateisystem gespeichert, das ggf. von Azure Files aus dem Speicherkonto unterstützt wird, das beim Erstellen der Funktions-App angegeben wurde. Bei Linux-Verbrauch werden die App-Inhalte stattdessen in einem Blob in dem Speicherkonto gespeichert, das in der App-Einstellung AzureWebJobsStorage angegeben ist. Die App-Einstellung WEBSITE_RUN_FROM_PACKAGE erhält den Wert der Blob-URL.

Externe Paket-URL

Die URL des externen Pakets ist eine Option, wenn Sie manuell steuern möchten, wie Bereitstellungen ausgeführt werden. Sie sind verantwortlich für das Hochladen eines ausführungsbereiten ZIP-Pakets mit Ihren erstellten App-Inhalten in Blob Storage und müssen auf diese externe URL in einer Anwendungseinstellung Ihrer Funktions-App verweisen. Wenn Ihre App neu gestartet wird, ruft sie jedes Mal das Paket ab, bindet es ein und führt es im Modus Aus Paket ausführen aus.

Verwendung: Fügen Sie Ihren Anwendungseinstellungen WEBSITE_RUN_FROM_PACKAGE hinzu. Der Wert dieser Einstellung sollte eine Blob-URL sein, die auf den Speicherort des spezifischen Pakets zeigt, das Ihre App ausführen soll. Einstellungen können entweder über das Portal oder mithilfe der Azure-Befehlszeilenschnittstelle hinzugefügt werden.

Wenn Sie Azure Blob Storage verwenden, kann Ihre Funktions-App entweder mithilfe einer Verbindung mit einer verwalteten Identität oder mit einer Shared Access Signature (SAS) auf den Container zugreifen. Die von Ihnen ausgewählte Option wirkt sich auf den Typ der URL aus, die Sie als Wert für WEBSITE_RUN_FROM_PACKAGE verwenden. Verwaltete Identitäten werden für die allgemeine Sicherheit empfohlen. Außerdem müssen SAS-Token, da sie ablaufen, manuell verwaltet werden.

Wenn Sie die Paketdatei bereitstellen, auf die eine Funktions-App verweist, müssen Sie Auslöser manuell synchronisieren, einschließlich der ersten Bereitstellung. Wenn Sie den Inhalt der Paketdatei ändern und nicht die URL selbst, müssen Sie auch Ihre Funktions-App neu starten, um die Auslöser zu synchronisieren. Weitere Informationen zum Konfigurieren dieser Bereitstellungstechnologie finden Sie in der Schrittanleitung.

Anwendungsfälle: Die URL des externen Pakets ist die einzige unterstützte Bereitstellungsmethode für Apps, die unter Linux mit Verbrauchs-Plan ausgeführt werden, wenn kein Remotebuild ausgeführt werden soll. Diese Methode ist auch die empfohlene Bereitstellungstechnologie, wenn Sie Ihre App ohne Azure Files erstellen. Für skalierbare Apps, die unter Linux ausgeführt werden, sollten Sie stattdessen für das Hosting den Flex-Verbrauchs-Plans in Betracht ziehen.

Speicherort von App-Inhalten: Sie sind für das Hochladen von App-Inhalten in Blob Storage verantwortlich. Sie können ein beliebiges Blob Storage-Konto verwenden, Azure Blob Storage wird jedoch empfohlen.

Docker-Container

Sie können eine Funktions-App bereitstellen, die in einem Linux-Container ausgeführt wird.

Verwendung: Erstellen Sie Ihre Funktionen in einem Linux-Container, und stellen Sie den Container dann in einem Premium- oder Dedicated-Plan in Azure Functions oder einem anderen Containerhost bereit. Mit den Azure Functions Core Tools können Sie eine angepasste Dockerfile-Datei für Ihr Projekt erstellen, mit der Sie wiederum eine containerisierte Funktions-App erstellen können. Sie können den Container in den folgenden Bereitstellungen verwenden:

Einsatzgebiete: Verwenden Sie die Option „Docker-Container“, wenn Sie mehr Kontrolle über die Linux-Umgebung benötigen, in der Ihre Funktions-App ausgeführt wird und in der der Container gehostet ist. Dieser Bereitstellungsmechanismus steht nur für Funktionen unter Linux zur Verfügung.

Speicherort von App-Inhalten: App-Inhalte werden in der angegebenen Containerregistrierung als Teil des Images gespeichert.

Quellcodeverwaltung

Sie können die kontinuierliche Integration zwischen Ihrer Funktions-App und einem Quellcode-Repository aktivieren. Mit aktivierter Quellcodeverwaltung löst eine Aktualisierung des Codes im verbundenen Quell-Repository die Bereitstellung des neuesten Codes aus dem Repository aus. Weitere Informationen finden Sie unter Continuous Deployment für Azure Functions.

Verwendung : Die einfachste Möglichkeit zum Einrichten der Veröffentlichung aus der Quellcodeverwaltung stammt aus dem Bereitstellungscenter im Bereich "Funktionen" des Portals. Weitere Informationen finden Sie unter Continuous Deployment für Azure Functions.

Einsatzgebiete: Die Verwendung von Quellcodeverwaltung ist die bewährte Methode für Teams, die an ihren Funktions-Apps zusammenarbeiten. Quellcodeverwaltung ist eine gute Bereitstellungsoption, die anspruchsvollere Bereitstellungspipelines ermöglicht. Die Quellcodeverwaltung ist in der Regel auf einem Stagingslot aktiviert, der nach der Überprüfung von Updates aus dem Repository in die Produktion getauscht werden kann. Weitere Informationen finden Sie unter Azure Functions-Bereitstellungsslots.

Speicherort von App-Inhalten: Der App-Inhalt befindet sich im Quellcodeverwaltungssystem, aber lokal geklonter und erstellter App-Inhalt wird im App-Dateisystem gespeichert, das ggf. von Azure Files aus dem Speicherkonto unterstützt wird, das beim Erstellen der Funktions-App angegeben wurde.

Lokales Git

Bei dieser Methode können Sie Code unter Verwendung von lokalem Git von Ihrem lokalen Computer aus in Azure Functions pushen.

Verwendung: Eine entsprechende Anleitung finden Sie unter Lokale Git-Bereitstellung in Azure App Service.

Verwendung: Um die Fehlerwahrscheinlichkeit zu verringern, sollten Sie die Verwendung von Bereitstellungsmethoden vermeiden, die den zusätzlichen Schritt der manuellen Synchronisierung von Triggern erfordern. Verwenden Sie nach Möglichkeit die ZIP-Bereitstellung.

Speicherort von App-Inhalten: App-Inhalte werden im Dateisystem gespeichert, das ggf. durch Azure Files aus dem Speicherkonto unterstützt wird, das beim Erstellen der Funktions-App angegeben wurde.

FTP/S

Sie können FTP/S verwenden, um Dateien direkt nach Azure Functions zu übertragen. Diese Bereitstellungsmethode wird allerdings nicht empfohlen. Wenn Sie nicht vorhaben, FTP zu nutzen, sollten Sie es deaktivieren. Wenn Sie FTP nutzen möchten, sollten Sie FTPS erzwingen. Informationen zur Vorgehensweise im Azure-Portal finden Sie unter Erzwingen von FTPS.

Verwendung: Befolgen Sie die Anweisungen unter FTPS-Bereitstellungseinstellungen, um die URL und die Anmeldeinformationen abzurufen, die Sie für die Bereitstellung in Ihrer Funktions-App über FTPS verwenden können.

Verwendung: Um die Fehlerwahrscheinlichkeit zu verringern, sollten Sie die Verwendung von Bereitstellungsmethoden vermeiden, die den zusätzlichen Schritt der manuellen Synchronisierung von Triggern erfordern. Verwenden Sie nach Möglichkeit die ZIP-Bereitstellung.

Speicherort von App-Inhalten: App-Inhalte werden im Dateisystem gespeichert, das ggf. durch Azure Files aus dem Speicherkonto unterstützt wird, das beim Erstellen der Funktions-App angegeben wurde.

Portalbearbeitung

Im portalbasierten Editor können Sie die Dateien, die sich in ihrer Funktions-App befinden, direkt bearbeiten (im Wesentlichen erfolgt die Bereitstellung bei jedem Speichern der Änderungen).

Verwendung: Wenn Sie Ihre Funktionen im Azure-Portal bearbeiten möchten, müssen Ihre Funktionen im Portal erstellt worden sein. Bei Verwendung einer anderen Bereitstellungsmethode wird Ihre Funktion schreibgeschützt und kann nicht mehr über das Portal bearbeitet werden, um eine zentrale zuverlässige Datenquelle (Single Source Of Truth, SSOT) zu gewährleisten. Sie können den Bearbeitungsmodus manuell erneut auf Read/Write festlegen und alle bereitstellungsbezogenen Anwendungseinstellungen (etwa WEBSITE_RUN_FROM_PACKAGE) entfernen, um wieder zu einem Zustand zurückzukehren, in dem Sie Ihre Dateien über das Portal bearbeiten können.

Einsatzgebiete: Das Portal ist eine gute Möglichkeit, um erste Schritte mit Azure Functions auszuführen. Bei komplexeren Entwicklungsarbeiten empfiehlt sich die Verwendung eines der folgenden Clienttools:

Speicherort von App-Inhalten: App-Inhalte werden im Dateisystem gespeichert, das ggf. durch Azure Files aus dem Speicherkonto unterstützt wird, das beim Erstellen der Funktions-App angegeben wurde.

Die folgende Tabelle gibt Aufschluss über die Betriebssysteme und Programmiersprachen, die Bearbeitung im Portal unterstützen:

Sprache Windows: Verbrauch Windows Premium Windows: Dediziert Linux: Verbrauch Linux Premium Linux: Dediziert
C#1
Java
JavaScript (Node.js) ✔ ✔ ✔ ✔ ✔
Python2 ✔ ✔ ✔
PowerShell ✔ ✔ ✔
TypeScript (Node.js)

1 In-Portal-Bearbeitung wird nur für C#-Skriptdateien unterstützt, die im Prozess mit dem Host ausgeführt werden. Weitere Informationen finden Sie in der C#-Skriptentwicklerreferenz (C#-Skript, CSX) zu Azure Functions.
2 Die Bearbeitung im Portal wird nur für das Python-Programmiermodell v1 unterstützt.

Bereitstellungsverhalten

Wenn Sie Updates für den Funktions-App-Code bereitstellen, werden aktuell ausgeführte Funktionen beendet. Nach Abschluss der Bereitstellung wird der neue Code geladen, um mit der Verarbeitung von Anforderungen zu beginnen. Lesen Sie Verbessern der Leistung und Zuverlässigkeit von Azure Functions, um zu erfahren, wie zustandslose und defensive Funktionen geschrieben werden.

Wenn Sie mehr Kontrolle über diesen Übergang benötigen, sollten Sie Bereitstellungsslots verwenden.

Bereitstellungsslots

Wenn Sie Ihre Funktions-App in Azure bereitstellen, können Sie als Bereitstellungsziel einen separaten Bereitstellungsslot verwenden, anstatt die Bereitstellung direkt in der Produktionsumgebung vorzunehmen. Die Bereitstellung auf einem Bereitstellungsplatz und das anschließende Austauschen in die Produktion nach der Überprüfung ist die empfohlene Methode zum Konfigurieren der kontinuierlichen Bereitstellung.

Die Art und Weise, wie Sie auf einem Slot bereitstellen, hängt von dem jeweiligen Bereitstellungstool ab, das Sie verwenden. Wenn Sie beispielsweise Azure Functions Core Tools verwenden, fügen Sie die--slot Option ein, um den Namen eines bestimmten Steckplatzes für den func azure functionapp publish Befehl anzugeben.

Weitere Informationen zu Bereitstellungsslots finden Sie in der Dokumentation zu Azure Functions-Bereitstellungsslots.

Nächste Schritte

Weitere Informationen zum Bereitstellen von Funktions-Apps finden Sie in den folgenden Artikeln: