Pular para o conteúdo
EnglishFale com a genteEntrar

Documentos Prontos para usar

CI/CD distribuído

Cada mudança no repositório vira build, testes e um link funcionando, nas máquinas que estavam paradas.

Cada mudança enviada ao repositório vira build, testes e um link funcionando, sem servidor de build dedicado.

Vocês continuam com o que já têm

  • O repositório continua no GitHub.
  • Os Dockerfiles continuam como estão. Cada etapa monta e roda a partir das imagens que vocês já descrevem.
  • Um arquivo de configuração no repositório (um .toml) diz quais etapas existem e qual espera qual. É tudo o que o Claro Compute precisa para reconhecer o pipeline.

Como funciona

  1. Você liga o repositório do GitHub à plataforma.

    A página do GitHub no ambiente: a conta ligada e os repositórios que alimentam cada pipeline.

  2. A cada mudança enviada, as etapas começam nos aparelhos da empresa. As que não dependem umas das outras rodam ao mesmo tempo, em aparelhos diferentes: o backend num, o frontend em outro, os testes espalhados.

    Uma rodada em andamento: cada máquina com a sua linha no tempo, as etapas em fases, e o registro ao vivo da etapa que está montando.

  3. Você acompanha cada aparelho ao vivo, com o registro do que ele está fazendo.

  4. No fim, uma etapa de publicação espera todas as outras e entrega o link da aplicação.

  5. Cada pull request ganha a própria prévia, para ver a mudança rodando antes de juntar.

Por que nos aparelhos da empresa

O build pesado roda na capacidade que já estava parada, perto do código e dos dados, sem fila em servidor alugado, e sem máquina de build paga para ficar parada entre um envio e outro. Os segredos de que as etapas precisam vêm do cofre, nunca do código.