> ## 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 são pequenos ícones usados em gráficos no AppSignal.com para indicar uma mudança. Isso pode ser um deploy de código usando um "Deploy marker" ou um evento especial com um ["Custom marker"](/application/markers/custom-markers). Os deploy markers também podem ser encontrados na [seção "Deploys"](https://appsignal.com/redirect-to/app?to=markers) na navegação do app, que fornece uma visão geral de desempenho por deploy.

Um marcador de deploy indica uma mudança na versão implantada de uma aplicação. Isso pode ser usado para agrupar ocorrências de erros e problemas de performance dentro de um determinado intervalo de tempo. Do momento em que a versão foi implantada até quando uma versão mais nova foi implantada. Marcadores de deploy também são necessários para habilitar [links de backtrace](/application/backtrace-links) para uma aplicação.

Quando um novo deploy é detectado, a lista de incidentes fica vazia para a versão de deploy mais recente. Quando um erro, ou qualquer outro problema, é reportado pelo AppSignal na sua aplicação, ele também é listado para o deploy mais recente. Na página de samples de um incidente, você pode ver em quais deploys um incidente ocorreu com a ajuda do ícone separador de foguete (🚀).

<Note>
  📖 Leia também nosso guia sobre [como configurar deploy
  markers](/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 na lista de samples" width="480" height="376" data-path="assets/images/screenshots/app_incident_samples_list.png" />

## Métodos de deploy

Existem dois métodos para notificar o AppSignal sobre um novo deploy. Esses dois métodos não podem ser usados juntos.

1. Usando a opção de configuração `revision` e;
2. Criando manualmente uma notificação de deploy com a Push API do AppSignal.

O primeiro método (opção de configuração `revision`) é a nossa abordagem recomendada, porque é o método mais confiável e funciona melhor para aplicações com mais de um host. Detectamos a revisão a partir da própria aplicação, então sabemos qual instância está rodando qual versão.

A segunda abordagem (criar um deploy marker manualmente) é um método realmente útil apenas para aplicações pequenas que usam um host. Ela cria um novo deploy marker em um horário específico, independentemente da versão que a aplicação realmente está rodando. Isso também significa que ela é mais suscetível a erros.

## Opção de configuração revision

A abordagem recomendada para informar ao AppSignal que uma nova versão da sua aplicação foi implantada é usando a opção de configuração `revision` ou a variável de ambiente `APP_REVISION` (veja o [guia de configuração de deploy markers](/guides/deploy-markers#configurations-per-language) para mais informações). Isso é detectado automaticamente para [apps no Heroku](#heroku-support) usando o recurso lab de dyno metadata.

Essa opção de configuração é definida por instância de uma aplicação, o que tem a vantagem de cada versão de uma aplicação em execução ao mesmo tempo reportar os erros sob o deploy correto, em vez do último deploy que [foi reportado](#manually-create-a-deploy-marker) ao AppSignal.

Por exemplo: se uma máquina ainda estiver rodando uma versão mais antiga da aplicação, todos os erros dessa instância são reportados sob o deploy marker anterior, em vez do último deploy marker conhecido.

O AppSignal criará um novo deploy marker ao receber [dados de transação](/appsignal/terminology#transactions). Quando a opção de configuração revision está definida para o seu app, a revisão é armazenada em uma transação que rastreia uma requisição web / background job. Quando nosso processador nos servidores do AppSignal detecta uma nova revisão, ele cria um novo deploy marker para o app pai com a revisão da transação.

### Opção de configuração

A opção de configuração `revision` pode ser usada em qualquer integração para reportar o deploy atual do app. Veja o [guia de deploy markers](/guides/deploy-markers) para mais informações.

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

Se você estiver rodando uma versão na qual essa opção de configuração não está disponível, recomendamos usar a [variável de ambiente `APP_REVISION`](#system-environment-variable) em vez disso.

### Variável de ambiente do sistema

O valor de `APP_REVISION` pode ser qualquer valor que você use para indicar uma versão/revisão. Por exemplo: um número de versão `1.4.2` ou um SHA do git `cf8bc42`.

O valor de revisão deve ser definido no ambiente do sistema da aplicação e atualizado durante o deploy da aplicação.

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

### Suporte ao Heroku

Ao usar Heroku com o [Heroku Labs: Dyno Metadata](https://devcenter.heroku.com/articles/dyno-metadata) habilitado, o Heroku preencherá a variável de ambiente `HEROKU_SLUG_COMMIT` com o SHA do commit Git que está sendo implantado.

A AppSignal definirá automaticamente a opção de configuração `revision` com o valor da variável de ambiente de sistema `HEROKU_SLUG_COMMIT`. Isso reportará automaticamente novos deploys quando a aplicação Heroku for implantada.

### Suporte ao Render

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

Ao fazer deploy de uma aplicação usando Render, ele preencherá a variável de ambiente `RENDER_GIT_COMMIT` com o SHA do commit Git que está sendo implantado.

A AppSignal definirá automaticamente a opção de configuração `revision` com o valor da variável de ambiente de sistema `RENDER_GIT_COMMIT`. Isso reportará automaticamente novos deploys quando a aplicação Render for implantada.

### Suporte ao Hatchbox

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

Para usar marcadores de deploy com o Hatchbox, primeiro conecte sua conta Hatchbox à AppSignal:

1. No Hatchbox, vá até as configurações do seu perfil e navegue até [**Connected accounts**](https://app.hatchbox.io/user/connected_accounts).
2. Na página "Connected accounts", selecione **Sign in with AppSignal**.
3. Na janela da AppSignal que abrir, autorize o Hatchbox a acessar sua organização AppSignal selecionando **Allow access**.

Ao fazer deploy de uma aplicação usando o Hatchbox, ele adicionará um arquivo `REVISION` na pasta de release com o SHA do commit Git que está sendo implantado.

A AppSignal definirá automaticamente a opção de configuração `revision` com o valor do arquivo `REVISION`. Isso reportará automaticamente novos deploys quando a aplicação Hatchbox for implantada.

### Suporte ao Kamal

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

Ao fazer deploy de uma aplicação usando Kamal, ele preencherá a variável de ambiente `KAMAL_VERSION` dentro do contêiner com o SHA do commit Git que está sendo implantado.

A AppSignal definirá automaticamente a opção de configuração `revision` com o valor da variável de ambiente de sistema `KAMAL_VERSION`. Isso reportará automaticamente novos deploys quando a aplicação for implantada usando Kamal.

### Suporte ao Docker

Se sua aplicação roda em um contêiner Docker, siga as instruções abaixo para definir a revisão da sua aplicação e criar um marcador de deploy.

Primeiro, adicione as instruções a seguir ao seu Dockerfile, logo após a última instrução `FROM`:

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

Uma vez adicionado, você precisa incluir a revisão da sua aplicação ao construir sua imagem Docker:

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

<Tip>
  Ao usar Fly.io para fazer o deploy da sua aplicação, o argumento de build `COMMIT` é
  fornecido automaticamente durante o build.
</Tip>

Isso definirá a variável de ambiente `APP_REVISION` para sua aplicação e permitirá que a integração da AppSignal use a revisão como um marcador de deploy.

### Suporte ao GitLab

Ao fazer deploy a partir de um pipeline GitLab CI/CD, defina a variável de ambiente `APP_REVISION` no seu job de deploy com o SHA do commit, para que a AppSignal a capture quando a aplicação iniciar:

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

`CI_COMMIT_SHA` é uma das [variáveis CI/CD predefinidas](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) do GitLab e resolve para o commit que está sendo implantado.

Se sua stack não inclui uma integração da AppSignal, veja o [exemplo de GitLab CI/CD](#gitlab-cicd-example) como alternativa.

## Criar manualmente um deploy marker

<Warning>
  Esse método de reportar marcadores de deploy está **obsoleto** e pode ser removido a qualquer momento no futuro.
  Reportar marcadores de deploy usando esse método só é útil para aplicações pequenas que usam uma única instância da aplicação. Ele cria um novo marcador de deploy em um momento específico, independentemente da versão que a aplicação está realmente executando. Isso também significa que é mais propenso a erros, agrupando dados que não deveriam pertencer ao deploy. Detectamos a implantação automaticamente lendo o arquivo `REVISION` que o Capistrano adiciona ao diretório de release desde a versão 4.5.18 da gem Ruby.
</Warning>

Esse método de reportar novos deploys ao AppSignal exige que você envie uma requisição POST para o endpoint markers da Push API do AppSignal. Isso pode ser feito com uma requisição HTTP POST manual para outras linguagens.

Quando a requisição de criação/notificação de deploy marker é recebida pelos servidores do AppSignal, todos os dados processados pelos nossos servidores a partir desse momento são rastreados sob o deploy recém-criado.

Para criar um Deploy marker com uma requisição HTTP POST, você pode usar curl ou alguma outra ferramenta semelhante. O payload da requisição é um objeto JSON com dados sobre o marker, como a revisão, o usuário que fez o deploy e o repositório da aplicação.

Leia mais sobre como criar Deploy markers com a nossa API na nossa documentação de [endpoint da API](/api/markers).

### Exemplo de GitLab CI/CD

Se você não puder usar a [opção de configuração `revision`](#revision-config-option) — por exemplo, porque sua stack não inclui uma integração do AppSignal — você pode chamar a Markers API a partir de um job separado de GitLab CI/CD após o deploy ser bem-sucedido.

Primeiro, armazene suas credenciais do AppSignal como variáveis mascaradas de CI/CD nas configurações do seu projeto no GitLab em **Settings → CI/CD → Variables**:

* `APPSIGNAL_API_TOKEN` — seu token de API pessoal (Profile → Account settings → Personal → API).
* `APPSIGNAL_APP_ID` — o ID do app no AppSignal para o ambiente em que você está fazendo deploy. Encontre-o na URL do AppSignal: `https://appsignal.com/<org-slug>/sites/<APPSIGNAL_APP_ID>/...`.

Em seguida, adicione um job de deploy-marker ao seu `.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>
  Webhooks do GitLab não podem ser usados para chamar a Markers API diretamente — os payloads
  dos webhooks do GitLab têm um formato fixo que não corresponde ao corpo de requisição da
  Markers API, e o GitLab não permite transformar o payload antes de
  enviá-lo.
</Tip>

#### Solução de problemas

Se o job do marker falhar com `401 Unauthorized`, verifique novamente o `APPSIGNAL_API_TOKEN`. Ele deve ser um token de API pessoal de **Profile → Account settings → Personal → API**, não a Push API key. Confirme que a variável não está restrita por escopo de Environment a um ambiente diferente daquele em que o job é executado.

Se o job do marker falhar com `404 Not Found`, o `APPSIGNAL_APP_ID` está incorreto ou pertence a uma organização diferente. Copie-o da URL do app no AppSignal (`https://appsignal.com/<org>/sites/<APPSIGNAL_APP_ID>/...`).

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