Conector do GitHub: o pipeline que você não precisa manter
Conector gerenciado para sincronizar repositories, members, issues, pull_requests e commits do GitHub para o seu warehouse. Crie sua conta e teste agora.
Traga repositories, members, issues, pull_requests e commits para o seu warehouse, sem cuidar de paginação, rate limit, alertas e schema evolution.
O problema com pipelines de GitHub feitos na mão
Toda área de dados, em algum momento, recebe a mesma pergunta: como a gente está medindo produtividade de engenharia? A resposta passa, quase sempre, pelos dados que já vivem no GitHub: pull requests, commits, issues, membros do org. O que parece um caso de uso simples de ELT esconde, na prática, um problema clássico de ingestão de SaaS API. O pipeline funciona até o dia em que para de funcionar, e ninguém percebe.
Construir do zero é tentador. A API do GitHub é pública, bem documentada, e qualquer engineer consegue puxar uma listagem de PRs em poucas linhas. O custo aparece depois, e ele não está no código que você escreve no primeiro sprint. Está em tudo que você passa a manter para sempre.
Cada endpoint relevante para analytics pagina de uma forma diferente, e a lógica que você escreveu uma vez precisa ser revisitada quando o GitHub muda algum default. O rate limit é compartilhado entre operações e cai sem aviso quando você escala para um org grande, então você acaba implementando backoff exponencial, cache de ETag e algum mecanismo para distribuir a janela de extração. Schemas mudam: campos novos aparecem, outros viram nullable. O seu DAG no Airflow continua reportando sucesso enquanto entrega menos dado do que deveria.
E tem a parte que ninguém lembra na hora de estimar: alertas. Quando uma execução falha, alguém precisa saber. Quando a taxa de registros cai 80% em relação à semana anterior, alguém precisa saber. Quando a contagem de PRs zerou para um repositório ativo, alguém precisa saber. Construir e manter essa lógica de observabilidade (não a do produto, a do próprio pipeline) é um projeto de plataforma por si só.
O pior cenário não é o pipeline que quebra. É o pipeline que silenciosamente degrada, e a métrica que vai pro dashboard do CTO já chega errada.
O que dá para fazer com os dados do GitHub no seu warehouse
Antes de falar do conector, vale registrar o que se ganha quando esses dados chegam modelados ao lado do resto do seu stack analítico.
Engineering analytics e DORA metrics. Lead time de pull request (do opened_at ao merged_at), throughput por repositório, tempo médio de review, distribuição de mudanças entre autores. Combinando com dados de deploy do CI/CD, você fecha as quatro métricas DORA (deployment frequency, lead time for changes, change failure rate e MTTR) sem depender de uma ferramenta externa que cobra por licença.
Detecção de gargalos de revisão. Cruzando pull_requests com members, você vê rapidamente quem está sustentando a fila de review e onde as mudanças param por mais tempo. Esse é um insumo de gestão que time de dados nunca conseguiu entregar quando o dado morava só no SaaS.
Hotspots de bug e qualidade. Combinando issues com commits por repositório, você identifica onde o churn é maior e onde o tempo de resolução de issue é mais alto. O tipo de análise que, antes, exigia um analista revirando relatórios manuais.
Auditoria, compliance e onboarding. Saber quem entrou e saiu do org, quem tem acesso a quais repositórios e cruzar isso com o sistema de RH no warehouse. Útil para times que precisam evidenciar controles para SOC 2 ou ISO 27001.
Combinação com o resto do stack. O ganho real aparece quando os dados de GitHub estão ao lado de Linear ou Jira, do CRM, do produto. É aí que perguntas como "quanto tempo da engenharia foi para clientes do enterprise no último trimestre?" deixam de ser planilha e viram um modelo dbt mantido pelo time.
Por que terceirizar a ingestão para a Erathos
A premissa do conector é simples: a engenharia de manutenção da ingestão não deveria ser responsabilidade do seu time de dados. Paginação, rate limit, retry, schema evolution, alerta de falha, alerta de degradação, backfill. Tudo isso é problema de quem opera a plataforma de ingestão, não uma decisão técnica do seu analytics engineer.
É exatamente isso que o conector entrega. Você gera o token, conecta o org, e a partir desse ponto:
Visibilidade ponta a ponta de cada execução. Quanto demorou cada extração, quantos registros vieram por endpoint, quais janelas foram processadas, onde houve retentativa. Isso vale tanto para encontrar a causa raiz de uma métrica errada quanto para responder o time de produto que quer saber por que o número mudou.
Alertas configurados de fábrica. Falha, queda de volume e atraso de janela são detectados e enviados pelas integrações de alerta que o time já usa. Você não precisa escrever esse código.
Reprocessamento como operação suportada. Quando você precisa reprocessar uma janela específica, seja porque mudou a modelagem ou porque recebeu uma correção de dado da fonte, isso é um botão e não um exercício de SQL improvisado.
Em cima disso, paginação correta, gestão de rate limit, evolução de schema e backfill ficam por conta da plataforma. O time foca no modelo de dados, não no encanamento.
O que está disponível no conector
O conector entrega cinco endpoints prontos para serem materializados no seu warehouse de destino:
repositories: catálogo de repositórios do orgmembers: membros do orgissues: issues abertas e fechadaspull_requests: pull requests com metadados de review e mergecommits: commits dos repositórios sincronizados
Os destinos suportados hoje são BigQuery, Redshift, PostgreSQL, SQL Server, Databricks e Amazon S3.
A autenticação é feita com um Personal Access Token (classic) do GitHub. O token precisa de dois escopos: repo (para ler dados de repositório) e read:org (para ler membros do org). O processo passo a passo está descrito na documentação do conector.
Comece agora
Crie sua conta na Erathos e teste o conector com os seus repositórios. Em poucos minutos, com o token e o nome do org, você vê os primeiros dados aterrissando no warehouse, sem código de pipeline para escrever, manter ou monitorar.
Engenharia gera dados todo dia. Faz pouco sentido esses dados continuarem trancados em um SaaS, fora do seu modelo, ou pior, em um pipeline caseiro que vai te custar atenção todo mês para sempre.
Traga repositories, members, issues, pull_requests e commits para o seu warehouse, sem cuidar de paginação, rate limit, alertas e schema evolution.
O problema com pipelines de GitHub feitos na mão
Toda área de dados, em algum momento, recebe a mesma pergunta: como a gente está medindo produtividade de engenharia? A resposta passa, quase sempre, pelos dados que já vivem no GitHub: pull requests, commits, issues, membros do org. O que parece um caso de uso simples de ELT esconde, na prática, um problema clássico de ingestão de SaaS API. O pipeline funciona até o dia em que para de funcionar, e ninguém percebe.
Construir do zero é tentador. A API do GitHub é pública, bem documentada, e qualquer engineer consegue puxar uma listagem de PRs em poucas linhas. O custo aparece depois, e ele não está no código que você escreve no primeiro sprint. Está em tudo que você passa a manter para sempre.
Cada endpoint relevante para analytics pagina de uma forma diferente, e a lógica que você escreveu uma vez precisa ser revisitada quando o GitHub muda algum default. O rate limit é compartilhado entre operações e cai sem aviso quando você escala para um org grande, então você acaba implementando backoff exponencial, cache de ETag e algum mecanismo para distribuir a janela de extração. Schemas mudam: campos novos aparecem, outros viram nullable. O seu DAG no Airflow continua reportando sucesso enquanto entrega menos dado do que deveria.
E tem a parte que ninguém lembra na hora de estimar: alertas. Quando uma execução falha, alguém precisa saber. Quando a taxa de registros cai 80% em relação à semana anterior, alguém precisa saber. Quando a contagem de PRs zerou para um repositório ativo, alguém precisa saber. Construir e manter essa lógica de observabilidade (não a do produto, a do próprio pipeline) é um projeto de plataforma por si só.
O pior cenário não é o pipeline que quebra. É o pipeline que silenciosamente degrada, e a métrica que vai pro dashboard do CTO já chega errada.
O que dá para fazer com os dados do GitHub no seu warehouse
Antes de falar do conector, vale registrar o que se ganha quando esses dados chegam modelados ao lado do resto do seu stack analítico.
Engineering analytics e DORA metrics. Lead time de pull request (do opened_at ao merged_at), throughput por repositório, tempo médio de review, distribuição de mudanças entre autores. Combinando com dados de deploy do CI/CD, você fecha as quatro métricas DORA (deployment frequency, lead time for changes, change failure rate e MTTR) sem depender de uma ferramenta externa que cobra por licença.
Detecção de gargalos de revisão. Cruzando pull_requests com members, você vê rapidamente quem está sustentando a fila de review e onde as mudanças param por mais tempo. Esse é um insumo de gestão que time de dados nunca conseguiu entregar quando o dado morava só no SaaS.
Hotspots de bug e qualidade. Combinando issues com commits por repositório, você identifica onde o churn é maior e onde o tempo de resolução de issue é mais alto. O tipo de análise que, antes, exigia um analista revirando relatórios manuais.
Auditoria, compliance e onboarding. Saber quem entrou e saiu do org, quem tem acesso a quais repositórios e cruzar isso com o sistema de RH no warehouse. Útil para times que precisam evidenciar controles para SOC 2 ou ISO 27001.
Combinação com o resto do stack. O ganho real aparece quando os dados de GitHub estão ao lado de Linear ou Jira, do CRM, do produto. É aí que perguntas como "quanto tempo da engenharia foi para clientes do enterprise no último trimestre?" deixam de ser planilha e viram um modelo dbt mantido pelo time.
Por que terceirizar a ingestão para a Erathos
A premissa do conector é simples: a engenharia de manutenção da ingestão não deveria ser responsabilidade do seu time de dados. Paginação, rate limit, retry, schema evolution, alerta de falha, alerta de degradação, backfill. Tudo isso é problema de quem opera a plataforma de ingestão, não uma decisão técnica do seu analytics engineer.
É exatamente isso que o conector entrega. Você gera o token, conecta o org, e a partir desse ponto:
Visibilidade ponta a ponta de cada execução. Quanto demorou cada extração, quantos registros vieram por endpoint, quais janelas foram processadas, onde houve retentativa. Isso vale tanto para encontrar a causa raiz de uma métrica errada quanto para responder o time de produto que quer saber por que o número mudou.
Alertas configurados de fábrica. Falha, queda de volume e atraso de janela são detectados e enviados pelas integrações de alerta que o time já usa. Você não precisa escrever esse código.
Reprocessamento como operação suportada. Quando você precisa reprocessar uma janela específica, seja porque mudou a modelagem ou porque recebeu uma correção de dado da fonte, isso é um botão e não um exercício de SQL improvisado.
Em cima disso, paginação correta, gestão de rate limit, evolução de schema e backfill ficam por conta da plataforma. O time foca no modelo de dados, não no encanamento.
O que está disponível no conector
O conector entrega cinco endpoints prontos para serem materializados no seu warehouse de destino:
repositories: catálogo de repositórios do orgmembers: membros do orgissues: issues abertas e fechadaspull_requests: pull requests com metadados de review e mergecommits: commits dos repositórios sincronizados
Os destinos suportados hoje são BigQuery, Redshift, PostgreSQL, SQL Server, Databricks e Amazon S3.
A autenticação é feita com um Personal Access Token (classic) do GitHub. O token precisa de dois escopos: repo (para ler dados de repositório) e read:org (para ler membros do org). O processo passo a passo está descrito na documentação do conector.
Comece agora
Crie sua conta na Erathos e teste o conector com os seus repositórios. Em poucos minutos, com o token e o nome do org, você vê os primeiros dados aterrissando no warehouse, sem código de pipeline para escrever, manter ou monitorar.
Engenharia gera dados todo dia. Faz pouco sentido esses dados continuarem trancados em um SaaS, fora do seu modelo, ou pior, em um pipeline caseiro que vai te custar atenção todo mês para sempre.