Primeiros passos com integração contínua e canais de implantação do GitLab (CI / CD)

Integração e implantação contínuas, ou CI / CD, é o processo de simplificar e acelerar o desenvolvimento, criando e testando automaticamente cada compromisso do seu projeto. O GitLab integra CI / CD em sua solução git extremamente bem e mostraremos como configurá-lo e trabalhar com ele.

Configurando um servidor de compilação (executor GitLab)

Freqüentemente, compilar código pode ser uma operação extremamente intensa. Nem todas as linguagens têm esse problema, mas algumas, como C ++, podem levar mais de meia hora para concluir uma compilação complicada. O Chromium, por exemplo, pode levar mais de uma hora, mesmo em sistemas de 12 núcleos, conforme mostrado aqui neste gráfico da GamersNexus.

GamersNexus

Tempo é dinheiro, então muitas empresas optarão por ter servidores de construção dedicados, geralmente um enxame de servidores, e executar seus pipelines de CI / CD em hardware poderoso.

Se você não estiver hospedando sozinho e, em vez disso, estiver usando a solução SaaS on-line do GitLab (gitlab. com), você precisará pagar pelos minutos de CI / CD. A camada gratuita inclui 400 minutos de CI / CD, o que deve ser suficiente para projetos simples, especialmente linguagens como JS, onde tudo o que pode ser necessário é uma compilação npm básica. As camadas mais altas, que cobram por usuário, oferecem muito mais tempo de construção. Você pode ver os totais atualizados na página de informações de preços do GitLab &’

No nosso caso, estamos hospedando-nos sozinhos, então precisaremos configurar um GitLab Runner, que é instalado em um servidor e o configura como um agente de compilação. Ele está disponível como binário, bem como uma implantação do Kubernetes, que pode ser ideal para implantações de vários servidores com escalonamento automático.

Felizmente, o processo de instalação é simples. Você precisará descobrir qual binário precisará para o seu host e fazer o download. Para sistemas baseados em Debian como o Ubuntu, esse seria o pacote deb:

 curl -LJO "https://gitlab-runner-downloads.s3. amazonaws. com/latest/deb/gitlab-runner_amd64. deb"

E instale-o com dpkg:

 sudo dpkg -i gitlab-runner_amd64. deb 

Em seguida, você precisará configurá-lo com o URL e o token encontrados em / admin / runners.

 registro sudo gitlab-runner 

Você será solicitado a especificar qual executor este executor deve usar. Na maioria dos casos, você pode simplesmente usar “ docker, ” com uma imagem padrão como ubuntu.

Depois de configurado, você pode iniciar o corredor:

 registro sudo gitlab-runner 

Então você deve vê-lo na lista.

Em nosso caso, havia um bug estranho em que o runner não iniciava porque a pasta / var / lib / gitlab-runner não estava presente. Criá-lo manualmente resolveu o problema imediatamente:

 sudo mkdir / var / lib / gitlab-runner 

Você precisará abrir as configurações do executor e definir as tags adequadas para ele, que serão selecionadas pelos arquivos de configuração gitlab-ci. yml correspondentes. Se, em vez disso, você não se incomodou com as tags, pode marcar esta caixa aqui para escolher os trabalhos não marcados:

A seguir, você &’ precisará configurar seus projetos para usar este runner.

Configurando CI / CD para seu projeto

A configuração do GitLab CI é feita com um arquivo na raiz do seu projeto, chamado . gitlab-ci. yml. Isso é usado automaticamente para executar.

Claro, a configuração exata disso dependerá muito de você e de suas necessidades. Um bom lugar para começar seria ver como outras pessoas fizeram isso para sua linguagem e tempo de execução.

Por exemplo, uma construção . NET simples pode ser executada usando uma configuração como a seguinte:

 imagem: microsoft / dotnet: últimos estágios: - build before_script: - 'dotnet restore' build: stage: build script: - 'dotnet build' 

Primeiro, precisamos definir a imagem Docker que o GitLab usará para construir seu aplicativo. Isso é importante porque, caso contrário, o ambiente não terá o tempo de execução . NET. Antes de qualquer coisa, ele executa o dotnet restore e, em seguida, o dotnet build para realmente construir o aplicativo.

Para saber mais sobre a estrutura deste arquivo, você pode consultar a documentação do GitLab &’ s.

Uma vez comprometido com seu repo, esse commit acionará o primeiro pipeline. Você pode visualizar os resultados do pipeline em CI / CD > Pipelines, onde você verá cada execução junto com seu status.

Se você clicar nos detalhes, poderá depurar o que deu errado com a falha na execução, pois isso mantém um registro do console.