Observação: Executores hospedados em GitHub não são atualmente compatíveis com GitHub Enterprise Server. Você pode ver mais informações sobre suporte futuro planejado no Itinerário público do GitHub.
Sobre integração contínua
A integração contínua (CI, Continuous Integration) é uma prática de software que exige commits frequentes de códigos para um repositório compartilhado. Fazer commits de códigos com frequência detecta erros com mais antecedência e reduz a quantidade de código necessária para depuração quando os desenvolvedores chegam � origem de um erro. As atualizações frequentes de código também facilitam o merge de alterações dos integrantes de uma equipe de desenvolvimento de software. Assim, os desenvolvedores podem se dedicar mais � gravação de códigos e se preocupar menos com erros de depuração ou conflitos de merge.
Ao fazer commit do seu repositório, você pode continuamente compilar e testar o código para garantir que o commit não insira erros. Seus testes podem incluir linters de código (que verificam formatação de estilo), verificações de segurança, cobertura de código, testes funcionais e outras verificações personalizadas.
Para compilar e testar seu código, é necessário usar um servidor. Você pode criar e testar atualizações no local antes de fazer push do código para um repositório, ou pode usar um servidor de CI que verifica os novos commits de código em um repositório.
Sobre integração contínua usando GitHub Actions
CI que usa GitHub Actions oferece fluxos de trabalho que podem criar o código no seu repositório e executar seus testes. Fluxos de trabalho podem ser executados em máquinas virtuais hospedadas em GitHub ou em máquinas que você mesmo hospeda. Para obter mais informações, consulte "Ambientes virtuais para executores hospedados em GitHub" e "Sobre executores auto-hospedados".
Você pode configurar a execução do seu fluxo de trabalho de CI para ocorrer diante de um evento do GitHub (por exemplo, quando houver push de um novo código para o seu repositório), com base em uma programação definida ou quando houver um evento externo usando o webhook de despacho do repositório.
GitHub Enterprise Server executa seus testes de CI e fornece os resultados de cada teste no pull request para que você possa ver se a mudança no seu branch introduz um erro. Quando todos os testes de CI em um fluxo de trabalho forem aprovados, as alterações que passaram por push estarão prontas para a revisão de um integrante da equipe ou para o merge. Se algum teste falhar, uma de suas alterações pode ter causado a falha.
Ao configurar o CI no seu repositório, GitHub Enterprise Server analisa o código no seu repositório e recomenda fluxos de trabalho CI baseados no idioma e na estrutura do seu repositório. Por exemplo, se você usar Node.js, GitHub Enterprise Server irá sugerir um fluxo de trabalho inicial que instala seus pacotes Node.js e executa seus testes. Você pode usar o fluxo de trabalho inicial de CI sugerido por GitHub Enterprise Server, personalizar o fluxo de trabalho inicial sugerido ou criar o seu próprio arquivo de fluxo de trabalho personalizado para executar seus testes de CI.
Além de ajudá-lo a configurar fluxos de trabalho de CI para seu projeto, você pode usar GitHub Actions para criar fluxos de trabalho ao longo de todo o ciclo de vida de desenvolvimento do software. Por exemplo, você pode usar ações para implantar, criar pacotes ou lançar uma versão do seu projeto. Para obter mais informações, consulte "Sobre GitHub Actions".
Para obter uma definição de termos comuns, consulte "Conceitos básicos de GitHub Actions".
Fluxo de trabalho inicial
GitHub Enterprise Server oferece fluxo de trabalho inicial de CI para uma série de linguagens e estruturas.
Navegue pela lista completa do fluxo de trabalho inicial da CI oferecido por GitHub no repositório de actions/starter-workflows em your GitHub Enterprise Server instance.