> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploy-Marker

export const Compatibility = ({versions = [], label = "Available in"}) => {
  if (!Array.isArray(versions) || versions.length === 0) {
    return null;
  }
  const defaultPillStyle = {
    borderColor: "#d4d4d8",
    background: "#f4f4f5",
    color: "#3f3f46"
  };
  const pillStyles = {
    "AppSignal for Elixir": {
      background: "#f3e8ff",
      borderColor: "#d8b4fe",
      color: "#6b21a8"
    },
    "AppSignal for Front-end": {
      background: "#fef9c3",
      borderColor: "#fde047",
      color: "#854d0e"
    },
    "AppSignal for Go": {
      background: "#ccfbf1",
      borderColor: "#5eead4",
      color: "#115e59"
    },
    "AppSignal for JavaScript": {
      background: "#fef9c3",
      borderColor: "#fde047",
      color: "#854d0e"
    },
    "AppSignal for Node.js": {
      background: "#dcfce7",
      borderColor: "#86efac",
      color: "#166534"
    },
    "AppSignal for Python": {
      background: "#dbeafe",
      borderColor: "#93c5fd",
      color: "#1e40af"
    },
    "AppSignal for Ruby": {
      background: "#fee2e2",
      borderColor: "#fca5a5",
      color: "#991b1b"
    },
    "AppSignal for Rust": {
      background: "#ffedd5",
      borderColor: "#fdba74",
      color: "#9a3412"
    }
  };
  const getPillStyle = name => ({
    ...defaultPillStyle,
    ...pillStyles[name] || ({})
  });
  return <div className="not-prose my-4 rounded-lg border border-zinc-200 bg-zinc-50 px-4 py-3 text-sm dark:border-white/10 dark:bg-white/5">
      <div className="flex flex-wrap items-center gap-x-2 gap-y-1">
        <span className="font-semibold text-zinc-700 dark:text-zinc-200">
          {label}:
        </span>
        {versions.map((v, i) => <span key={`${v.name}-${v.version}-${i}`} className="inline-flex items-center gap-1 rounded-full border px-2 py-0.5 text-xs font-medium" style={getPillStyle(v.name)}>
            <span>{v.name}</span>
            <span className="opacity-70">
              {v.version}
              {v.exact ? "" : "+"}
            </span>
          </span>)}
      </div>
    </div>;
};

Marker sind kleine Symbole, die in Diagrammen auf AppSignal.com verwendet werden, um eine Änderung anzuzeigen. Dies kann ein Code-Deploy mit einem "Deploy-Marker" oder ein besonderes Ereignis mit einem ["Custom-Marker"](/application/markers/custom-markers) sein. Deploy-Marker finden Sie auch im Abschnitt ["Deploys"](https://appsignal.com/redirect-to/app?to=markers) in der App-Navigation, der eine Performance-Übersicht pro Deploy bietet.

Ein Deploy-Marker kennzeichnet eine Änderung der bereitgestellten Version einer Anwendung. Damit lassen sich Fehlervorkommen und Performance-Probleme innerhalb eines bestimmten Zeitraums gruppieren – vom Zeitpunkt der Bereitstellung der Version bis zur Bereitstellung einer neueren Version. Deploy-Marker sind außerdem erforderlich, um [Backtrace-Links](/application/backtrace-links) für eine Anwendung zu aktivieren.

Wenn ein neuer Deploy erkannt wird, ist die Liste der Incidents für die neueste Deploy-Version leer. Wenn ein Fehler oder ein anderes Problem von AppSignal in Ihrer Anwendung gemeldet wird, wird er ebenfalls für den neuesten Deploy gelistet. Auf der Sample-Seite eines Incidents können Sie mithilfe des Raketen-Trennsymbols (🚀) erkennen, in welchen Deploys ein Incident aufgetreten ist.

<Note>
  📖 Lesen Sie auch unseren Leitfaden zur [Einrichtung von
  Deploy-Markern](/guides/deploy-markers).
</Note>

<img src="https://mintcdn.com/appsignal-715f5a51/nF8c1Rwq1cS7b5hg/assets/images/screenshots/app_incident_samples_list.png?fit=max&auto=format&n=nF8c1Rwq1cS7b5hg&q=85&s=31ed7e05907d0d6ce1102810a22993a5" alt="Deploy-Marker in der Samples-Liste" width="480" height="376" data-path="assets/images/screenshots/app_incident_samples_list.png" />

## Deploy-Methoden

Es gibt zwei Methoden, um AppSignal über einen neuen Deploy zu informieren. Diese beiden Methoden können nicht zusammen verwendet werden.

1. Verwendung der Konfigurationsoption `revision` und
2. manuelles Erstellen einer Deploy-Benachrichtigung mit der AppSignal Push API.

Die erste Methode (`revision`-Konfigurationsoption) ist unser empfohlener Ansatz, da sie die zuverlässigste Methode ist und besser für Anwendungen mit mehr als einem Host funktioniert. Wir erkennen die Revision aus der Anwendung selbst, sodass wir wissen, welche Instanz welche Version ausführt.

Der zweite Ansatz (manuelles Erstellen eines Deploy-Markers) ist eine Methode, die nur für kleine Anwendungen mit einem einzigen Host wirklich nützlich ist. Sie erstellt zu einem bestimmten Zeitpunkt einen neuen Deploy-Marker, unabhängig von der tatsächlich ausgeführten Version der Anwendung. Das bedeutet auch, dass sie fehleranfälliger ist.

## Revision-Konfigurationsoption

Der empfohlene Ansatz, um AppSignal mitzuteilen, dass eine neue Version Ihrer Anwendung deployed ist, besteht in der Verwendung der Konfigurationsoption `revision` oder der Umgebungsvariablen `APP_REVISION` (siehe [Konfigurationsleitfaden für Deploy-Marker](/guides/deploy-markers#configurations-per-language) für weitere Informationen). Dies wird für [Heroku-Apps](#heroku-support) mithilfe der Dyno-Metadata-Lab-Funktion automatisch erkannt.

Diese Konfigurationsoption wird pro Instanz einer Anwendung gesetzt, was den Vorteil hat, dass jede gleichzeitig laufende Version einer Anwendung die Fehler unter dem richtigen Deploy meldet, anstatt unter dem letzten Deploy, der [an AppSignal gemeldet wurde](#manually-create-a-deploy-marker).

Beispiel: Wenn auf einem Rechner noch eine ältere Version der Anwendung läuft, werden alle Fehler dieser Instanz unter dem vorherigen Deploy-Marker statt unter dem zuletzt bekannten Deploy-Marker gemeldet.

AppSignal erstellt einen neuen Deploy-Marker, wenn es [Transaktionsdaten](/appsignal/terminology#transactions) empfängt. Wenn die `revision`-Konfigurationsoption für Ihre App gesetzt ist, wird die Revision in einer Transaktion gespeichert, die einen Webrequest oder Background-Job verfolgt. Wenn unser Processor auf den AppSignal-Servern eine neue Revision erkennt, erstellt er einen neuen Deploy-Marker für die zugehörige App mit der Revision aus der Transaktion.

### Konfigurationsoption

Die `revision`-Konfigurationsoption kann in jeder Integration verwendet werden, um den aktuellen Deploy der App zu melden. Weitere Informationen finden Sie im [Deploy-Marker-Leitfaden](/guides/deploy-markers).

<CodeGroup>
  ```ruby Ruby theme={null}
  AppSignal.configure do |config|
    config.revision = "abcdef12"
  end
  ```
</CodeGroup>

Wenn Sie eine Version verwenden, in der diese Konfigurationsoption nicht verfügbar ist, empfehlen wir stattdessen die Verwendung der [Umgebungsvariablen `APP_REVISION`](#system-environment-variable).

### Systemumgebungsvariable

Der Wert von `APP_REVISION` kann jeder Wert sein, den Sie zur Angabe einer Version/Revision verwenden. Beispielsweise eine Versionsnummer `1.4.2` oder ein Git-SHA `cf8bc42`.

Der Revisionswert sollte in der Systemumgebung der Anwendung gesetzt und während eines Deploys der Anwendung aktualisiert werden.

<CodeGroup>
  ```bash Bash theme={null}
  export APP_REVISION="cf8bc42"
  # Start your application
  # bundle exec rackup app.rb
  ```
</CodeGroup>

### Heroku-Unterstützung

Wenn Sie Heroku mit aktivierten [Heroku Labs: Dyno Metadata](https://devcenter.heroku.com/articles/dyno-metadata) verwenden, befüllt Heroku die Umgebungsvariable `HEROKU_SLUG_COMMIT` mit dem SHA des bereitgestellten Git-Commits.

AppSignal setzt die Konfigurationsoption `revision` automatisch auf den Wert der System-Umgebungsvariable `HEROKU_SLUG_COMMIT`. Dadurch werden neue Deployments automatisch gemeldet, wenn die Heroku-Anwendung bereitgestellt wird.

### Render-Unterstützung

<Compatibility
  versions={[
{ name: "AppSignal for Ruby", version: "3.4.7" },
{ name: "AppSignal for Elixir", version: "2.7.6" },
{ name: "AppSignal for Node.js", version: "3.0.16" },
{ name: "AppSignal for Python", version: "0.2.0" },
]}
/>

Beim Bereitstellen einer Anwendung mit Render wird die Umgebungsvariable `RENDER_GIT_COMMIT` mit dem SHA des bereitgestellten Git-Commits befüllt.

AppSignal setzt die Konfigurationsoption `revision` automatisch auf den Wert der System-Umgebungsvariable `RENDER_GIT_COMMIT`. Dadurch werden neue Deployments automatisch gemeldet, wenn die Render-Anwendung bereitgestellt wird.

### Hatchbox-Unterstützung

<Compatibility versions={[{ name: "AppSignal for Ruby", version: "4.5.18" }]} />

Um Deploy-Marker mit Hatchbox zu verwenden, verbinden Sie zunächst Ihr Hatchbox-Konto mit AppSignal:

1. Gehen Sie in Hatchbox zu Ihren Profileinstellungen und navigieren Sie zu [**Connected accounts**](https://app.hatchbox.io/user/connected_accounts).
2. Wählen Sie auf der Seite "Connected accounts" **Sign in with AppSignal**.
3. Autorisieren Sie im sich öffnenden AppSignal-Fenster Hatchbox, auf Ihre AppSignal-Organisation zuzugreifen, indem Sie **Allow access** auswählen.

Beim Bereitstellen einer Anwendung mit Hatchbox wird eine `REVISION`-Datei im Release-Ordner mit dem SHA des bereitgestellten Git-Commits hinzugefügt.

AppSignal setzt die Konfigurationsoption `revision` automatisch auf den Wert der `REVISION`-Datei. Dadurch werden neue Deployments automatisch gemeldet, wenn die Hatchbox-Anwendung bereitgestellt wird.

### Kamal-Unterstützung

<Compatibility
  versions={[
{ name: "AppSignal for Ruby", version: "3.7.5" },
{ name: "AppSignal for Elixir", version: "3.4.7" },
{ name: "AppSignal for Node.js", version: "3.4.4" },
{ name: "AppSignal for Python", version: "1.3.3" },
]}
/>

Beim Bereitstellen einer Anwendung mit Kamal wird die Umgebungsvariable `KAMAL_VERSION` innerhalb des Containers mit dem SHA des bereitgestellten Git-Commits befüllt.

AppSignal setzt die Konfigurationsoption `revision` automatisch auf den Wert der System-Umgebungsvariable `KAMAL_VERSION`. Dadurch werden neue Deployments automatisch gemeldet, wenn die Anwendung mit Kamal bereitgestellt wird.

### Docker-Unterstützung

Wenn Ihre Anwendung in einem Docker-Container läuft, folgen Sie den nachstehenden Anweisungen, um die Revision Ihrer Anwendung festzulegen und einen Deploy-Marker zu erstellen.

Fügen Sie zunächst die folgenden Anweisungen in Ihr Dockerfile ein, direkt nach der letzten `FROM`-Anweisung:

<CodeGroup>
  ```bash Bash theme={null}
  ARG COMMIT
  ENV APP_REVISION=$COMMIT
  ```
</CodeGroup>

Sobald dies hinzugefügt wurde, müssen Sie die Revision Ihrer Anwendung beim Erstellen Ihres Docker-Images angeben:

```bash Bash theme={null}
docker build --build-arg COMMIT=$(git rev-parse HEAD) -t image:latest
```

<Tip>
  Wenn Sie Fly.io zum Bereitstellen Ihrer Anwendung verwenden, wird das Build-Argument `COMMIT`
  während des Builds automatisch bereitgestellt.
</Tip>

Dadurch wird die Umgebungsvariable `APP_REVISION` für Ihre Anwendung festgelegt, sodass die AppSignal-Integration die Revision als Deploy-Marker verwenden kann.

### GitLab-Unterstützung

Setzen Sie beim Deployment aus einer GitLab-CI/CD-Pipeline die Umgebungsvariable `APP_REVISION` in Ihrem Deploy-Job auf den Commit-SHA, damit AppSignal sie beim Start der Anwendung übernimmt:

<CodeGroup>
  ```yaml YAML theme={null}
  deploy:production:
    stage: deploy
    variables:
      APP_REVISION: $CI_COMMIT_SHA
    script:
      - ./bin/deploy.sh
  ```
</CodeGroup>

`CI_COMMIT_SHA` ist eine der [vordefinierten CI/CD-Variablen](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) von GitLab und entspricht dem Commit, der bereitgestellt wird.

Wenn Ihr Stack keine AppSignal-Integration enthält, sehen Sie sich stattdessen das [GitLab-CI/CD-Beispiel](#gitlab-cicd-example) an.

## Einen Deploy-Marker manuell erstellen

<Warning>
  Diese Methode zum Melden von Deploy-Markern ist **veraltet** und kann in Zukunft jederzeit entfernt werden.
  Das Melden von Deploy-Markern mit dieser Methode ist nur für kleine Anwendungen sinnvoll, die eine einzige Anwendungsinstanz verwenden. Sie erstellt zu einem bestimmten Zeitpunkt einen neuen Deploy-Marker, unabhängig davon, welche Version die Anwendung tatsächlich ausführt. Das bedeutet auch, dass es fehleranfälliger ist, da Daten, die nicht zum Deployment gehören sollten, diesem zugeordnet werden können. Wir erkennen Deployments automatisch, indem wir die `REVISION`-Datei lesen, die Capistrano seit Ruby-Gem 4.5.18 zum Release-Verzeichnis hinzufügt.
</Warning>

Diese Methode zum Melden neuer Deploys an AppSignal erfordert, dass Sie eine POST-Anfrage an den Markers-Endpunkt der AppSignal Push API senden. Dies kann für andere Sprachen mit einer manuellen HTTP-POST-Anfrage erfolgen.

Wenn die Anfrage zum Erstellen/Benachrichtigen über den Deploy-Marker von den AppSignal-Servern empfangen wird, werden alle Daten, die nach diesem Zeitpunkt von unseren Servern verarbeitet werden, unter dem neu erstellten Deploy erfasst.

Um einen Deploy-Marker mit einer HTTP-POST-Anfrage zu erstellen, können Sie curl oder ein ähnliches Tool verwenden. Die Payload der Anfrage ist ein JSON-Objekt mit Daten zum Marker, wie der Revision, dem Benutzer, der ihn deployed hat, und dem Repository der Anwendung.

Lesen Sie in unserer Dokumentation zum [API-Endpunkt](/api/markers) mehr darüber, wie Sie Deploy-Marker mit unserer API erstellen.

### GitLab-CI/CD-Beispiel

Wenn Sie die [Konfigurationsoption `revision`](#revision-config-option) nicht verwenden können — beispielsweise, weil Ihr Stack keine AppSignal-Integration enthält — können Sie die Markers-API in einem separaten GitLab-CI/CD-Job aufrufen, nachdem Ihr Deploy erfolgreich war.

Speichern Sie zunächst Ihre AppSignal-Anmeldedaten als maskierte CI/CD-Variablen in den **Settings → CI/CD → Variables** Ihres GitLab-Projekts:

* `APPSIGNAL_API_TOKEN` — Ihr persönlicher API-Token (Profile → Account settings → Personal → API).
* `APPSIGNAL_APP_ID` — die AppSignal-App-ID für die Umgebung, die Sie deployen. Sie finden sie in der AppSignal-URL: `https://appsignal.com/<org-slug>/sites/<APPSIGNAL_APP_ID>/...`.

Fügen Sie dann einen Deploy-Marker-Job zu Ihrer `.gitlab-ci.yml` hinzu:

<CodeGroup>
  ```yaml YAML theme={null}
  stages:
    - deploy
    - notify

  deploy:production:
    stage: deploy
    script:
      - ./bin/deploy.sh
    rules:
      - if: '$CI_COMMIT_BRANCH == "main"'

  appsignal:deploy_marker:
    stage: notify
    image: curlimages/curl:latest
    needs: ["deploy:production"]
    rules:
      - if: '$CI_COMMIT_BRANCH == "main"'
    script:
      - |
        curl --fail --silent --show-error \
          -H "Content-Type: application/json" \
          -X POST "https://appsignal.com/api/${APPSIGNAL_APP_ID}/markers.json?token=${APPSIGNAL_API_TOKEN}" \
          -d "{
                \"marker\": {
                  \"kind\": \"deploy\",
                  \"repository\": \"${CI_PROJECT_URL}.git\",
                  \"revision\": \"${CI_COMMIT_SHA}\",
                  \"user\": \"${GITLAB_USER_LOGIN}\"
                }
              }"
  ```
</CodeGroup>

<Tip>
  GitLab-Webhooks können nicht verwendet werden, um die Markers-API direkt aufzurufen — GitLab-
  Webhook-Payloads haben ein festes Format, das nicht zum Request-Body der Markers-API passt,
  und GitLab lässt Sie die Payload vor dem
  Versenden nicht transformieren.
</Tip>

#### Fehlerbehebung

Wenn der Marker-Job mit `401 Unauthorized` fehlschlägt, überprüfen Sie `APPSIGNAL_API_TOKEN` erneut. Es muss ein persönlicher API-Token aus **Profile → Account settings → Personal → API** sein, nicht der Push-API-Key. Stellen Sie sicher, dass die Variable nicht durch den Environment-Scope auf eine andere Umgebung beschränkt ist als die, in der der Job ausgeführt wird.

Wenn der Marker-Job mit `404 Not Found` fehlschlägt, ist `APPSIGNAL_APP_ID` falsch oder gehört zu einer anderen Organisation. Kopieren Sie sie aus der URL der AppSignal-App (`https://appsignal.com/<org>/sites/<APPSIGNAL_APP_ID>/...`).

[backtrace links]: /application/backtrace-links.html