Integrações: visão geral

As integrações são a fonte de dados da plataforma. Você conecta um provedor de código (e, opcionalmente, um rastreador de issues) e a plataforma sincroniza a atividade dos repositórios que você ativar, transformando-a em métricas.

Como as integrações se encaixam#

A plataforma trabalha com duas camadas que se complementam:

• Código: de onde vem a entrega (pull requests, reviews, commits, deployments e CI).
• Planejamento: de onde vem o contexto do trabalho (tickets, work items, sprints e épicos).

Quando as duas camadas estão conectadas, a plataforma liga PR ↔ ticket/work item, habilitando o value stream (lead time do planejamento à produção) e a distribuição de investimento. As integrações convivem: o Git traz a entrega, o tracker traz o planejamento.

Provedores#

Provedor	Tipo	Conexão	Status
GitHub	Código	GitHub App (somente leitura)	Disponível
GitLab	Código	OAuth (somente leitura)	Disponível
Bitbucket	Código	API token (somente leitura)	Disponível
Azure DevOps	Código + planejamento	PAT ou OAuth (Microsoft Entra ID)	Disponível
Jira	Planejamento	OAuth	Disponível
Linear	Planejamento	OAuth	Disponível
ClickUp	Planejamento	API token	Disponível
Redmine	Planejamento	API key	Disponível
Jenkins	CI/CD	Webhook (push)	Disponível
PagerDuty	Incidentes	Token de leitura	Disponível
Sentry	Erros / qualidade	Token de leitura	Disponível

Provedores de código#

• GitHub: conexão via GitHub App somente leitura (você instala o app e escolhe os repositórios). Traz PRs, reviews, commits, deployments, execuções de Actions, issues, milestones, Projects v2, alertas de segurança e CODEOWNERS. Veja Conectar o GitHub.
• GitLab: conexão via OAuth somente leitura (read_api). Traz MRs, aprovações, commits, pipelines (CI), deployments (DORA), issues e milestones, com webhooks opcionais de tempo real. Veja Conectar o GitLab.
• Bitbucket: conexão via API token somente leitura (e-mail da conta Atlassian + token com escopos). Traz PRs, aprovações, commits, Bitbucket Pipelines (CI) e deployments (DORA), com webhooks opcionais de tempo real. Issues ficam com o Jira (o tracker nativo do Bitbucket está sendo aposentado pela Atlassian). Veja Conectar o Bitbucket.
• Azure DevOps: conexão via PAT ou OAuth (Microsoft Entra ID). Numa só conexão cobre Repos/PRs, Pipelines (CI/DORA) e, opcionalmente, o Azure Boards para planejamento. Veja Conectar o Azure DevOps.

Rastreadores de issues (planejamento)#

• Jira: conexão via OAuth, com rastreabilidade ticket ↔ PR. Veja Conectar o Jira.
• Linear: conexão via OAuth somente leitura. Times viram projetos, cycles viram sprints, e o vínculo PR ↔ issue funciona com a própria convenção de branch do Linear (ana/eng-123-...). Veja Conectar o Linear.
• ClickUp: conexão via API token somente leitura. Spaces viram projetos; tarefas, status e pontos alimentam o fluxo, e o vínculo PR ↔ tarefa usa a convenção do ClickUp (CU-86b1abc). Veja Conectar o ClickUp.
• Azure Boards: habilitado junto da conexão do Azure DevOps, atuando como rastreador de issues.
• Redmine: conexão via API key, com a mesma rastreabilidade ticket ↔ PR (ids #123). Conecte pela tela de Integrações; os projetos aparecem para seleção como nos demais trackers.

CI/CD (build e deploy)#

• Jenkins: provedor de CI/CD que aumenta os repositórios do SCM (não adiciona repos próprios). O Jenkins envia os builds para uma URL secreta (push, funciona atrás de firewall); builds alimentam a aba CI e os jobs marcados como deploy alimentam o DORA. Veja Conectar o Jenkins.

Incidentes / Confiabilidade#

• PagerDuty: provedor de incidentes/on-call que aumenta os repos do SCM (mapeie serviço → repo). Puxamos os incidentes por API (token de leitura) e o MTTR e o CFR do DORA passam a vir de incidentes reais (some o proxy). Adiciona a aba Confiabilidade. Veja Conectar o PagerDuty.
• Sentry: provedor de erros que também aumenta os repos do SCM (mapeie projeto → repo). Alimenta a aba Qualidade em Deploys e serve de fonte para CFR/MTTR quando não há PagerDuty (a precedência é PagerDuty > Sentry > proxy por status de deploy).

Os insights gerados pela camada de planejamento ficam em Insights de planejamento.

O que cada integração traz#

Ao ativar um repositório, a plataforma importa e mantém atualizado:

• Pull requests: timestamps de ciclo (primeiro commit, criação, primeiro review, aprovação, merge), tamanho (linhas/arquivos) e flags.
• Reviews e comentários: quem revisou, quando, e comentários de linha/gerais.
• Commits: autoria e datas.
• Deployments: base para frequência de deploy e change failure rate (DORA).
• Execuções de CI (workflow runs / Actions): sucesso/falha, duração, fila e re-execuções (proxy de flaky).
• Issues e milestones: triagem, SLA e andamento.
• Projects v2: sprints, burndown e velocity.
• Alertas de segurança: Dependabot e code scanning.
• CODEOWNERS: para mapear donos por caminho.

Com um rastreador conectado, importa-se também a camada de planejamento (tickets / work items, story points, épicos), permitindo a ligação PR ↔ ticket que alimenta o value stream.

Como os dados ficam atualizados#

A carga inicial é um full sync que percorre o histórico do repositório. Você acompanha o progresso de cada repositório pelos estados PENDING → RUNNING → DONE → FAILED.

Depois da carga inicial, webhooks processam novos eventos de forma incremental, mantendo os dados atualizados quase em tempo real, sem reprocessar tudo. Tudo é escopado à sua organização e respeita os repositórios que você ativou. Mais detalhes em Como funciona.

Segurança dos tokens#

• O acesso é somente leitura.
• As credenciais de acesso (tokens OAuth, tokens de instalação ou PAT) são criptografadas em repouso com AES-256.
• A plataforma não armazena o conteúdo do código-fonte, apenas metadados de atividade.

Próximos passos#

• Conecte um provedor de código: Conectar o GitHub ou Conectar o Azure DevOps.
• Adicione planejamento: Conectar o Jira.
• Depois, selecione os repositórios que deseja acompanhar.