{"meta":{"title":"Durchführung von Bereitstellungen","intro":"Mithilfe der REST-API für Bereitstellungen kannst du benutzerdefinierte Tools erstellen, die mit deinem Server und einer Drittanbieter-App interagieren.","product":"REST-API","breadcrumbs":[{"href":"/de/rest","title":"REST-API"},{"href":"/de/rest/guides","title":"Anleitungen"},{"href":"/de/rest/guides/delivering-deployments","title":"Durchführung von Bereitstellungen"}],"documentType":"article"},"body":"# Durchführung von Bereitstellungen\n\nMithilfe der REST-API für Bereitstellungen kannst du benutzerdefinierte Tools erstellen, die mit deinem Server und einer Drittanbieter-App interagieren.\n\nSie können die REST-API verwenden, um Ihre Projekte bereitzustellen, die auf GitHub einem Server gehostet werden, den Sie besitzen. Weitere Informationen zu den Endpunkten zum Verwalten von Bereitstellungen und Statusinformationen findest du unter [REST-API-Endpunkte für Bereitstellungen](/de/rest/deployments). Du kannst auch die REST-API verwenden, um deine Bereitstellungen in dem Moment zu koordinieren, in dem dein Code im Standardzweig eintrifft. Weitere Informationen finden Sie unter [Erstellen eines CI-Servers](/de/rest/guides/building-a-ci-server).\n\nIn diesem Leitfaden wird die REST-API verwendet, um ein Setup zu veranschaulichen, das du verwenden kannst.\nIn unserem Szenario werden wir Folgendes tun:\n\n* Einen Pull Request zusammenführen.\n* Wenn die CI abgeschlossen ist, legen wir den Status des Pull Requests entsprechend fest.\n* Wenn der „Pull Request“ zusammengeführt wurde, starten wir die Bereitstellung auf unserem Server.\n\nUnser CI-System und der Hostserver sind Produkte unserer Vorstellungskraft. Dabei könnte es sich um Heroku, Amazon oder etwas ganz anderes handeln. Im Mittelpunkt dieses Leitfadens steht die Einrichtung und Konfiguration des Servers, der die Kommunikation verwaltet.\n\nWenn du den [Download von `ngrok`](https://ngrok.com/) noch nicht durchgeführt hast, solltest du dies tun und den [Umgang damit lernen](https://ngrok.com/docs/getting-started/). Dieses Tool ist sehr nützlich, um lokale Anwendungen im Internet zugänglich zu machen.\n\n> \\[!NOTE]\n> Alternativ kannst du die Webhookweiterleitung verwenden, um deine lokale Umgebung für den Empfang von Webhooks einzurichten. Weitere Informationen finden Sie unter [Verwenden der GitHub CLI zum Weiterleiten von Webhooks für Tests](/de/webhooks/testing-and-troubleshooting-webhooks/using-the-github-cli-to-forward-webhooks-for-testing).\n\nHinweis: Du kannst den vollständigen Quellcode für dieses Projekt [aus dem Repository mit den Plattformbeispielen](https://github.com/github/platform-samples/tree/master/api/ruby/delivering-deployments) herunterladen.\n\n## Schreiben des Servers\n\nWir schreiben eine einfache Sinatra-App, um zu zeigen, dass unsere lokalen Verbindungen funktionieren.\nBeginnen wir hiermit:\n\n```ruby\nrequire 'sinatra'\nrequire 'json'\n\npost '/event_handler' do\n  payload = JSON.parse(params[:payload])\n  \"Well, it worked!\"\nend\n```\n\n(Wenn du nicht mit der Funktionsweise von Sinatra vertraut bist, solltest du den [Sinatra-Leitfaden](http://www.sinatrarb.com/) lesen.)\n\nStarte diesen Server. Sinatra wird standardmäßig auf Port `4567` gestartet. Daher solltest du `ngrok` so konfigurieren, dass es ebenfalls auf diesen Port lauscht.\n\nDamit dieser Server funktioniert, müssen wir ein Repository mit einem Webhook einrichten. Dieser Webhook sollte so konfiguriert werden, dass er ausgelöst wird, wenn ein Pull Request erstellt oder zusammengeführt wird.\n\nErstelle nun ein Repository, mit dem du experimentieren kannst. Dürfen wir Ihnen das von [@octocat vorgeschlagene Spoon/Knife-Repository](https://github.com/octocat/Spoon-Knife) präsentieren?\n\nDanach erstellst du einen neuen Webhook in deinem Repository, fügst die von `ngrok` bereitgestellte URL hinzu und wählst `application/x-www-form-urlencoded` als Inhaltstyp aus.\n\nKlicke auf **Webhook aktualisieren**. Der Antworttext `Well, it worked!` sollte angezeigt werden.\nSehr gut! Klicke auf **Individuelle Ereignisse auswählen**, und wähle Folgendes aus:\n\n* Bereitstellung\n* Bereitstellungsstatus\n* Pull-Anforderung\n\nDies sind die Ereignisse GitHub , die an unseren Server gesendet werden, wenn die entsprechende Aktion auftritt. Wir konfigurieren unseren Server so, dass er *nur* Verarbeitungen durchführt, wenn Pull Requests sofort zusammengeführt werden:\n\n```ruby\npost '/event_handler' do\n  @payload = JSON.parse(params[:payload])\n\n  case request.env['HTTP_X_GITHUB_EVENT']\n  when \"pull_request\"\n    if @payload[\"action\"] == \"closed\" && @payload[\"pull_request\"][\"merged\"]\n      puts \"A pull request was merged! A deployment should start now...\"\n    end\n  end\nend\n```\n\nWoran liegt das? Jedes von GitHub gesendete Ereignis enthält den HTTP-Header `X-GitHub-Event`. Wir kümmern uns jetzt nur um die PR-Veranstaltungen. Wenn ein Pull Request zusammengeführt wird (der Status lautet `closed`, und `merged` ist `true`), starten wir eine Bereitstellung.\n\nNimm einige Änderungen in einem Branch deines Testrepositorys vor, öffne einen Pull Request, und merge sie, um diesen Proof of Concept zu testen. Dein Server sollte entsprechend reagieren.\n\n## Arbeiten mit Bereitstellungen\n\nSobald unser Server eingerichtet ist, der Code überprüft und unser Pull Request zusammengeführt wurde, möchten wir unser Projekt bereitstellen.\n\nZunächst ändern wir unseren Ereignislistener so, dass er Pull Requests verarbeitet, wenn sie zusammengeführt werden, und beginnen, auf Bereitstellungen zu reagieren:\n\n```ruby\nwhen \"pull_request\"\n  if @payload[\"action\"] == \"closed\" && @payload[\"pull_request\"][\"merged\"]\n    start_deployment(@payload[\"pull_request\"])\n  end\nwhen \"deployment\"\n  process_deployment(@payload)\nwhen \"deployment_status\"\n  update_deployment_status\nend\n```\n\nAnhand der Informationen aus dem Pull Request beginnen wir mit dem Ausfüllen der `start_deployment`-Methode:\n\n```ruby\ndef start_deployment(pull_request)\n  user = pull_request['user']['login']\n  payload = JSON.generate(:environment => 'production', :deploy_user => user)\n  @client.create_deployment(pull_request['head']['repo']['full_name'], pull_request['head']['sha'], {:payload => payload, :description => \"Deploying my sweet branch\"})\nend\n```\n\nBereitstellungen können mit Metadaten in Form von `payload` und `description` versehen sein. Auch wenn diese Werte optional sind, ist es hilfreich, sie zum Protokollieren und Darstellen von Informationen zu verwenden.\n\nWenn eine neue Bereitstellung erstellt wird, wird ein völlig separates Ereignis ausgelöst. Daher haben wir einen neuen `switch`-Fall im Ereignishandler für `deployment`. Du kannst diese Informationen verwenden, um benachrichtigt zu werden, wenn eine Bereitstellung ausgelöst wurde.\n\nBereitstellungen können eine lange Zeit dauern. Daher sollten wir auf verschiedene Ereignisse lauschen, z. B. wann die Bereitstellung erstellt wurde und in welchem Zustand sie sich befindet.\n\nLass uns eine Bereitstellung simulieren, die einige Aufgaben ausführt, und beobachten, wie sich dies auf die Ausgabe auswirkt. Zunächst sollten wir unsere `process_deployment`-Methode abschließen:\n\n```ruby\ndef process_deployment\n  payload = JSON.parse(@payload['payload'])\n  # you can send this information to your chat room, monitor, pager, etc.\n  puts \"Processing '#{@payload['description']}' for #{payload['deploy_user']} to #{payload['environment']}\"\n  sleep 2 # simulate work\n  @client.create_deployment_status(\"repos/#{@payload['repository']['full_name']}/deployments/#{@payload['id']}\", 'pending')\n  sleep 2 # simulate work\n  @client.create_deployment_status(\"repos/#{@payload['repository']['full_name']}/deployments/#{@payload['id']}\", 'success')\nend\n```\n\nSchließlich simulieren wir das Speichern der Statusinformationen als Konsolenausgabe:\n\n```ruby\ndef update_deployment_status\n  puts \"Deployment status for #{@payload['id']} is #{@payload['state']}\"\nend\n```\n\nLass uns aufschlüsseln, was gerade passiert. Eine neue Bereitstellung wird von `start_deployment` erstellt, wodurch das `deployment`-Ereignis ausgelöst wird. Anschließend rufen wir `process_deployment` auf, um andauernde Prozesse zu simulieren. Während dieser Verarbeitung rufen wir ebenfalls `create_deployment_status` auf, wodurch wir einen Empfänger über den Stand der Dinge informieren, während wir den Status auf `pending` festlegen.\n\nNach Abschluss der Bereitstellung legen wir den Status auf `success` fest.\n\n## Schlussbemerkung\n\nSeit Jahren verwenden wir bei GitHub eine Version von `Heaven`, um unsere Bereitstellungen zu verwalten. Der allgemeine Ablauf ist im Wesentlichen derselbe wie bei dem Server, den wir oben erstellt haben:\n\n* Warte auf eine Antwort auf den Status der CI-Überprüfungen (Erfolg oder Fehler).\n* Wenn die erforderlichen Überprüfungen erfolgreich waren, führe den Pull Request zusammen.\n* `Heaven` verwendet den zusammengeführten Code und stellt ihn auf Staging- und Produktionsservern bereit.\n* In der Zwischenzeit benachrichtigt `Heaven` auch alle über den Build, mittels [Hubot](https://github.com/github/hubot), der in unseren Chat-Räumen sitzt.\n\nDas ist alles! Um dieses Beispiel zu verwenden, musst du kein eigenes Bereitstellungssetup kompilieren.\nSie können sich jederzeit auf [GitHub Integrationen](https://github.com/integrations) verlassen."}