> ## 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 markers

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>;
};

Markers zijn kleine pictogrammen die in grafieken op AppSignal.com worden gebruikt om een verandering aan te geven. Dit kan een code-deploy zijn met een "Deploy marker" of een speciale gebeurtenis met een ["Custom marker"](/application/markers/custom-markers). Deploy markers vindt u ook in de [sectie "Deploys"](https://appsignal.com/redirect-to/app?to=markers) in de app-navigatie, die een performance-overzicht per deploy biedt.

Een deploy marker geeft een wijziging in de gedeployde versie van een applicatie aan. Dit kan worden gebruikt om voorvallen van fouten en prestatieproblemen binnen een bepaald tijdsbestek te groeperen. Vanaf het moment dat de versie werd gedeployd totdat een nieuwere versie werd gedeployd. Deploy markers zijn ook vereist om [backtrace links](/application/backtrace-links) voor een app in te schakelen.

Wanneer een nieuwe deploy wordt gedetecteerd, is de lijst met incidenten leeg voor de nieuwste deploymentversie. Wanneer een fout, of een ander probleem, door AppSignal in uw applicatie wordt gerapporteerd, wordt deze ook bij de nieuwste deploy vermeld. Op de sample-pagina van een incident kunt u zien in welke deploys een incident is opgetreden, met behulp van het raket-pictogram (🚀) als scheidingsteken.

<Note>
  📖 Lees ook onze gids over [hoe u deploy markers
  instelt](/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 markers in samples list" width="480" height="376" data-path="assets/images/screenshots/app_incident_samples_list.png" />

## Deploy-methoden

Er zijn twee methoden om AppSignal op de hoogte te stellen van een nieuwe deploy. Deze twee methoden kunnen niet samen worden gebruikt.

1. Met de configuratieoptie `revision`, en;
2. Door handmatig een deploymelding aan te maken met de AppSignal Push API.

De eerste methode (`revision`-configuratieoptie) is onze aanbevolen aanpak, omdat dit de meest betrouwbare methode is en beter werkt voor applicaties met meerdere hosts. We detecteren de revisie vanuit de applicatie zelf, zodat we weten welke instance welke versie draait.

De tweede aanpak (handmatig een deploy marker aanmaken) is alleen echt nuttig voor kleine applicaties die één host gebruiken. Hij maakt op een specifiek tijdstip een nieuwe deploy marker aan, ongeacht de versie die de applicatie daadwerkelijk draait. Dit betekent ook dat deze methode foutgevoeliger is.

## De configuratieoptie revision

De aanbevolen manier om AppSignal te laten weten dat er een nieuwe versie van uw applicatie is gedeployed, is door de configuratieoptie `revision` of de omgevingsvariabele `APP_REVISION` te gebruiken (zie de [configuratiegids voor deploy markers](/guides/deploy-markers#configurations-per-language) voor meer informatie). Dit wordt automatisch gedetecteerd voor [Heroku-apps](#heroku-support) met de dyno-metadata-labfunctie.

Deze configuratieoptie wordt per instance van een applicatie ingesteld, wat het voordeel heeft dat elke versie van een applicatie die tegelijk draait de fouten onder de juiste deploy rapporteert, in plaats van onder de laatste deploy die [is gerapporteerd](#manually-create-a-deploy-marker) aan AppSignal.

Bijvoorbeeld: als één machine nog een oudere versie van de applicatie draait, worden alle fouten van die instance gerapporteerd onder de vorige deploy marker, in plaats van onder de laatst bekende deploy marker.

AppSignal maakt een nieuwe deploy marker aan wanneer het [transactiedata](/appsignal/terminology#transactions) ontvangt. Wanneer de revision-configuratieoptie voor uw app is ingesteld, wordt de revisie opgeslagen op een transactie die een webrequest / background job volgt. Wanneer onze processor op de AppSignal-servers een nieuwe revisie detecteert, maakt deze een nieuwe deploy marker aan voor de bovenliggende app met de revisie uit de transactie.

### Configuratieoptie

De configuratieoptie `revision` kan in elke integratie worden gebruikt om de huidige deploy van de app te rapporteren. Zie de [gids voor deploy markers](/guides/deploy-markers) voor meer informatie.

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

Als u een versie draait waarin deze configuratieoptie niet beschikbaar is, raden we aan om in plaats daarvan de [omgevingsvariabele `APP_REVISION`](#system-environment-variable) te gebruiken.

### Systeem-omgevingsvariabele

De waarde van `APP_REVISION` kan elke waarde zijn die u gebruikt om een versie/revisie aan te duiden. Bijvoorbeeld: een versienummer `1.4.2` of een git-SHA `cf8bc42`.

De revision-waarde moet worden ingesteld in de systeemomgeving van de applicatie en bijgewerkt worden tijdens een deploy van de applicatie.

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

### Heroku-ondersteuning

Wanneer u Heroku gebruikt met de [Heroku Labs: Dyno Metadata](https://devcenter.heroku.com/articles/dyno-metadata) ingeschakeld, vult Heroku de omgevingsvariabele `HEROKU_SLUG_COMMIT` met de SHA van de git-commit die wordt gedeployd.

AppSignal stelt de configuratieoptie `revision` automatisch in op de waarde van de systeem-omgevingsvariabele `HEROKU_SLUG_COMMIT`. Hierdoor worden nieuwe deploys automatisch gerapporteerd wanneer de Heroku-app wordt gedeployd.

### Render-ondersteuning

<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" },
]}
/>

Wanneer u een applicatie deployt met Render, vult deze de omgevingsvariabele `RENDER_GIT_COMMIT` met de SHA van de git-commit die wordt gedeployd.

AppSignal stelt de configuratieoptie `revision` automatisch in op de waarde van de systeem-omgevingsvariabele `RENDER_GIT_COMMIT`. Hierdoor worden nieuwe deploys automatisch gerapporteerd wanneer de Render-app wordt gedeployd.

### Hatchbox-ondersteuning

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

Om deploy markers met Hatchbox te gebruiken, koppelt u eerst uw Hatchbox-account aan AppSignal:

1. Ga in Hatchbox naar uw profielinstellingen en navigeer naar [**Connected accounts**](https://app.hatchbox.io/user/connected_accounts).
2. Selecteer op de pagina "Connected accounts" **Sign in with AppSignal**.
3. Autoriseer Hatchbox in het AppSignal-venster dat wordt geopend om toegang te krijgen tot uw AppSignal-organisatie door **Allow access** te selecteren.

Wanneer u een applicatie deployt met Hatchbox, wordt er een `REVISION`-bestand toegevoegd in de release-map met de SHA van de Git-commit die wordt gedeployd.

AppSignal stelt de configuratieoptie `revision` automatisch in op de waarde van het `REVISION`-bestand. Hierdoor worden nieuwe deploys automatisch gerapporteerd wanneer de Hatchbox-app wordt gedeployd.

### Kamal-ondersteuning

<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" },
]}
/>

Wanneer u een applicatie deployt met Kamal, vult deze de omgevingsvariabele `KAMAL_VERSION` binnen de container met de SHA van de git-commit die wordt gedeployd.

AppSignal stelt de configuratieoptie `revision` automatisch in op de waarde van de systeem-omgevingsvariabele `KAMAL_VERSION`. Hierdoor worden nieuwe deploys automatisch gerapporteerd wanneer de app met Kamal wordt gedeployd.

### Docker-ondersteuning

Als uw applicatie in een Docker-container draait, volg dan de onderstaande instructies om de revisie van uw applicatie in te stellen en een deploy marker aan te maken.

Voeg eerst de volgende instructies toe aan uw Dockerfile, direct na de laatste `FROM`-instructie:

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

Zodra deze zijn toegevoegd, moet u de revisie van uw applicatie meegeven bij het bouwen van uw Docker-image:

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

<Tip>
  Wanneer u Fly.io gebruikt om uw applicatie te deployen, wordt het `COMMIT`
  build-argument automatisch tijdens de build meegegeven.
</Tip>

Hiermee wordt de omgevingsvariabele `APP_REVISION` voor uw applicatie ingesteld, zodat de AppSignal-integratie de revisie als deploy marker kan gebruiken.

### GitLab-ondersteuning

Wanneer u deployt vanuit een GitLab CI/CD-pipeline, stel dan de omgevingsvariabele `APP_REVISION` in uw deploy-job in op de commit-SHA, zodat AppSignal deze oppikt wanneer de app start:

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

`CI_COMMIT_SHA` is een van GitLabs [vooraf gedefinieerde CI/CD-variabelen](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) en verwijst naar de commit die wordt gedeployd.

Als uw stack geen AppSignal-integratie bevat, raadpleeg dan het [GitLab CI/CD-voorbeeld](#gitlab-cicd-example).

## Handmatig een deploy marker aanmaken

<Warning>
  Deze methode om deploy markers te rapporteren is **verouderd** en kan op elk moment in de toekomst worden verwijderd.
  Het rapporteren van deploy markers via deze methode is alleen nuttig voor kleine applicaties met één applicatie-instantie. Hiermee wordt op een specifiek tijdstip een nieuwe deploy marker aangemaakt, ongeacht de versie die de applicatie daadwerkelijk uitvoert. Dit betekent ook dat het foutgevoeliger is om gegevens onder de deploy te groeperen die er niet bij thuishoren. We detecteren deployment automatisch door het `REVISION`-bestand te lezen dat Capistrano sinds Ruby gem 4.5.18 aan de release-map toevoegt.
</Warning>

Bij deze methode om nieuwe deploys aan AppSignal te rapporteren, stuurt u een POST-request naar de markers-endpoint van de AppSignal Push API. Dit kan voor andere talen gedaan worden met een handmatige HTTP POST-request.

Wanneer het create/notify-request voor de deploy marker wordt ontvangen door de AppSignal-servers, wordt alle data die na dat moment door onze servers wordt verwerkt, bijgehouden onder de nieuw aangemaakte deploy.

Om een deploy marker aan te maken met een HTTP POST-request kunt u curl of een vergelijkbare tool gebruiken. De payload van de request is een JSON-object met data over de marker, zoals de revisie, de gebruiker die deze heeft gedeployed en de repository van de applicatie.

Lees meer over hoe u deploy markers met onze API kunt aanmaken in onze [API-endpoint](/api/markers)-documentatie.

### Voorbeeld voor GitLab CI/CD

Als u de [`revision`-configuratieoptie](#revision-config-option) niet kunt gebruiken — bijvoorbeeld omdat uw stack geen AppSignal-integratie bevat — kunt u de Markers API aanroepen vanuit een aparte GitLab CI/CD-job nadat uw deploy is geslaagd.

Sla eerst uw AppSignal-credentials op als gemaskeerde CI/CD-variabelen in **Settings → CI/CD → Variables** van uw GitLab-project:

* `APPSIGNAL_API_TOKEN` — uw persoonlijke API-token (Profile → Account settings → Personal → API).
* `APPSIGNAL_APP_ID` — de AppSignal-app-id voor de omgeving die u deployt. Te vinden in de AppSignal-URL: `https://appsignal.com/<org-slug>/sites/<APPSIGNAL_APP_ID>/...`.

Voeg vervolgens een deploy-marker-job toe aan uw `.gitlab-ci.yml`:

<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 kunnen niet worden gebruikt om de Markers API rechtstreeks aan te roepen — payloads
  van GitLab-webhooks hebben een vast formaat dat niet overeenkomt met de body van de Markers
  API-request, en GitLab biedt geen mogelijkheid om de payload aan te passen voordat deze wordt
  verzonden.
</Tip>

#### Probleemoplossing

Als de marker-job mislukt met `401 Unauthorized`, controleer dan `APPSIGNAL_API_TOKEN`. Het moet een persoonlijke API-token zijn uit **Profile → Account settings → Personal → API**, niet de Push API key. Controleer of de variabele niet via Environment scope beperkt is tot een andere omgeving dan waarin de job draait.

Als de marker-job mislukt met `404 Not Found`, dan klopt de `APPSIGNAL_APP_ID` niet of behoort deze tot een andere organisatie. Kopieer deze uit de URL van de AppSignal-app (`https://appsignal.com/<org>/sites/<APPSIGNAL_APP_ID>/...`).

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