O que é integração contínua (IC)?

A integração contínua é a próxima etapa lógica depois de ter um sistema de controle de versão como Git e um sistema de controle de versão remota como GitLab ou Github para empreendimentos colaborativos. O problema que os grandes projetos enfrentam é o seguinte - à medida que novos pedidos de tração chegam, eles precisam ser testados e depois integrados ao ramo mestre, e esse esforço pode levar facilmente de algumas horas a algumas semanas, dependendo do tamanho do projeto, a localização dos membros da equipe, etc.

Como qualquer problema, a etapa lógica é automatizar toda. Fazemos isso configurando um gatilho de modo que, sempre que os compromissos mais recentes são mesclados em um ramo de um agente (o GitLab Runner, por exemplo) cria automaticamente o ambiente e o código, executa todos os testes de unidade e integração contra ele contra ele contra ele. Se houver algum erro encontrado, ele fornecerá um aviso e um relatório de falha, caso contrário, você recebe um sinal verde dizendo que tudo funciona.

Obviamente, levado ao seu extremo lógico, você também pode automatizar a implantação, configurar o teste A/B automatizado e remover a intervenção humana do processo. Que é denominado como entrega contínua e/ou implantação contínua, dependendo do nível de automação. Mas nós apenas nos concentraríamos na integração contínua neste tutorial.

Pré -requisitos

Vamos nos concentrar na criação de um fluxo de IC simples no tutorial usando uma instância do GitLab sobre HTTPS que abordamos em uma postagem anterior.

Além disso, também assumimos que você configurou uma conta de usuário nesta instância do GitLab e tenha um repositório (clonado em sua máquina local) gerenciado em seu nome de usuário. É esse repositório que usaremos para demonstrar o fluxo de trabalho de IC. No tutorial, seu nome será meu projeto.

Para listar tudo:

1. Instância do Gitlab
2. Repositório em branco, chamado My-Project
3. Clone local deste repositório
4. Sua instância Git local configurada para empurrar mudanças para controlo remoto.

Criando um aplicativo simples

Neste repositório, vamos criar um nó simples.JS App. Este aplicativo é um expresso simples.O servidor JS, que deve ser implantado em um contêiner do Docker. O servidor fornece uma carga útil HTTP dizendo "Hello World" em seu navegador.

Na raiz do seu repositório local, crie um arquivo aplicativo.JS e adicione as seguintes linhas:

'Use rigoroso';
const express = requer ('express');
// Constantes
Porta const = 8080;
const host = '0.0.0.0 ';
// Aplicativo
const app = express ();
aplicativo.get ('/', (req, res) =>
res.send ('Olá, mundo \ n');
);
aplicativo.Ouça (Port, host);
console.log ('em execução em http: // $ host: $ porta');

Em seguida, crie outro arquivo pacote.JSON e adicione o seguinte:

"Nome": "Docker_web_app",
"versão 1.0.0 ",
"Descrição": "Nó.JS no Docker ",
"Autor": "John Doe",
"Principal": "servidor.js ",
"Scripts":
"Start": "Node Server.js "
,
"Dependências":
"Express": "^4.16.1 "

Por fim, crie um Dockerfile e adicione o seguinte conteúdo:

Do nó: 8
# Criar diretório de aplicativos
Workdir/usr/src/app
# Instale dependências de aplicativos
# Um curinga é usado para garantir que ambos.JSON e PACOKELLOCK.JSON são copiados
Pacote de cópias*.JSON ./
Execute a instalação do NPM
# Se você estiver construindo seu código para produção
# Execute o npm install --only = produção
# Fonte de aplicativo de pacote
CÓPIA DE…
Exponha 8080
CMD ["Node", "App"]

O processo de construção para este aplicativo envolveria a criação de um contêiner de nó e a instalação das dependências (como expressas.Módulo JS). Este processo deve acontecer sem erros. Por uma questão de simplicidade, não vamos discutir nenhum teste neste tutorial.

Oleoduto Gitlab Runner

Agora adicionaríamos outro arquivo ao nosso repositório que seria chamado .Gitlab-Ci.yml . Este arquivo conteria as instruções para construir nosso projeto. Agora, toda vez que nos comprometemos com a instância do nosso Gitlab, o Gitlab invocava um corredor para construir e testar o projeto.

Atribuímos a este pipeline vários empregos que podem executar tudo de forma independente, tornando o processo de construção mais flexível. Para o repo acima, este é um válido .Gitlab-Ci.yml Crie este arquivo na raiz do seu repositório:

Imagem: Nó: mais recente
estágios:
- construir
cache:
Caminhos:
- node_modules/
Install_dependências:
estágio: construir
roteiro:
- NPM Instale

Temos apenas um estágio construir E tem apenas NPM Instale como um script. Este é um comando que você teria que correr manualmente toda vez que uma mudança chega ao seu projeto. O corredor do Gitlab faria isso por você. O corredor pode ser instalado em um cluster Kubernetes, um VPS na nuvem ou na estação de trabalho local e, se estiver ativo, estará esperando as instruções do servidor GitLab para executar uma compilação.

Instalávamos e configuraríamos um corredor localmente para automatizá -lo.

Obtendo o token do corredor

Abra seu repositório no Gitlab e visite suas configurações de CD/CI. Isso é Configurações → CD/CI Dentro do seu repositório de teste.

Deixe a configuração do Auto DevOps para o seu padrão e clique em EXPANDIR Para expandir as configurações gerais de pipeline e você receberá um token de corredor. Copie seu valor e, é claro, mantenha -o privado se você valoriza seu projeto.

Usando esse token, o executável local do GitLab Runner poderá se registrar com segurança na sua instância do Gitlab.

Instalando o GitLab Runner

Gitlab-Runner é um pequeno programa leve escrito em Go que é relacionado ao IC empregos em sua máquina local e envia os resultados para o GitLab para que ele considere as mudanças. É um único binário executável que pode ser instalado em qualquer sistema operacional principal. Siga as instruções aqui, para o seu sistema operacional específico. Essas instalações variam muito, de modo que listar todas elas é inviável.

Como alternativa, você pode usar o Runner como um serviço do Docker, mas vamos nos manter na instalação tradicional, pois os comandos são mais simples de ler e entender para o leitor. Depois de instalá -lo em sua estação de trabalho local, você precisa executar o comando:

$ Gitlab-Runner Register

Isso fará várias perguntas começando com seu coordenador Gitlab-Ci, que seria sua instância do GitLab:

$ Gitlab-Runner Register
Por favor, insira o URL do coordenador GitLab-Ci (e.g. https: // gitlab.com/):
https: // gitlab.exemplo.com

Em seguida, pediria o seu token do corredor, que obtivemos na seção anterior:

Por favor, insira o token Gitlab-CI para este corredor:

Your_secret_token

Então, para uma descrição de identificação e você pode pular adicionar tags pressionando:

Por favor, insira a descrição do GitLab-Ci para este corredor:

[HostName]: Demo para configurar CI usando o Runner

Por favor, insira as tags GitLab-Ci para este corredor (vírgula separada):

Registrando corredor ... conseguiu

Mais importante ainda, ele pedirá um executor (mais sobre isso em um momento), escolheremos o Docker por causa do nosso exemplo.

Por favor, insira o executor: Docker-SSH+Machine, Kubernetes, Paralelos, Shell, SSH, VirtualBox, Docker+Machine, Docker, Docker-SSH:

Docker

A imagem base do docker na qual a construção ocorreria e depois precisa ser especificada, nosso aplicativo de amostra usa o nó para que especifique uma imagem do nó:

Por favor, insira a imagem padrão do docker (e.g. Ruby: 2.1):

Nó: mais recente

Corredor registrado com sucesso. Sinta -se à vontade para iniciá -lo, mas se já estiver executando a configuração, deve ser automaticamente recarregado!

Agora algo que precisa de um pouco de explicação aqui está o que exatamente são executores? A maneira como o IC trabalha flui é que a construção de módulos, seus testes etc. são todos conhecidos como empregos e os executores executam esses empregos. Se você escolheu o VirtualBox como executor, o GitLab Runner se integraria ao VirtualBox instalado localmente e executaria os trabalhos de CI em uma VM, se você selecionar Kubernetes, isso aconteceria em seu cluster de Kubernetes, na nuvem, se você selecionar SSH, poderá delegar as tarefas de IC em um servidor remoto.

Nosso projeto de amostra é baseado no Docker, por isso faz sentido usar o Docker como nosso executor. Você precisa ter Docker instalado localmente por esta.

Ter várias opções para os executores torna o corredor mais flexível. Você pode querer construir localmente porque os arquivos do projeto são muito grandes ou você pode executar em um servidor remoto com 20 núcleos e meio terabyte de RAM porque o processo de construção é computacionalmente intensivo, especificando uma opção de executor fornece essa flexibilidade.

Por fim, em sua concha, você gostaria de iniciar o serviço Runner:

$ gitlab-runner Start

Vendo .Gitlab-Ci.YML em ação

Agora fizemos todas essas mudanças em nosso repo local criou todo o aplicativo.js, pacote.JSON, Dockerfile e .Gitlab-Ci.Arquivos YML. Presumivelmente, você cometeu as mudanças no seu repositório local em execução:

$ git estágio file_name
$ git Commit -m “Committ Message”

Vamos pressionar as mudanças para o nosso Remote Gitlab.

$ git push -u origem

Você pode então abrir seu projeto no Gitlab, ir para My-Project → Pipeline E você verá isso uma etiqueta dizendo "Passou" ao lado do Commit que você fez. Comprometimentos subsequentes, também terão tags.

Então esse é o básico do IC usando o Gitlab e o corredor. Espero que tenha gostado do post e tenha aprendido algo novo com ele.