DEV Community: LeonardoMarques

[Java] Solucionando concorrência em schedules

LeonardoMarques — Fri, 13 Dec 2024 19:49:48 +0000

Vivi esse problema em ambiente de trabalho e precisei estudar um pouco mais a fundo para conseguir solucioná-lo. E claro, de forma colaborativa com meus colegas, principalmente o Rafa que foi essencial na solução que vou apresentar. Um salve pro Caio também que nos ajudou a seguir pelo caminho dos schedules, vocês já vão entender.

Tudo começou com um projeto de Jobs usando Spring Batch do Java. Todos os jobs eram iniciados por schedules. Inicialmente era um job apenas, então rodava sozinho de tempos em tempos, digamos assim. O problema é que a medida que foram surgindo mais jobs, começamos a perceber a degradação da execução. E aqui entra nossa maior dor: um desses jobs iniciava um fluxo de tarifação que concorria com outros produtos da empresa para tarifar. Se a gente demorasse muito, digamos que perdíamos nossa chance de tarifar o cliente. E adivinha o que estava acontecendo? Esses jobs estavam concorrendo e executando de forma síncrona travando a thread principal e impedindo outros jobs de executarem. Uma espécie de dança das cadeiras se for mais fácil de visualizar.

Inicialmente achávamos que o problema era com os jobs e focamos esforços em resolver isso, até encontramos formas de paralelizar o fluxo "do meio" de um job. A título de curiosidade: a estrutura básica de um job geralmente tem um reader, um processor e um writer. Dependendo do seu problema você consegue paralelizar o processor e/ou o writer usando Future do Java.
Se quiser aprofundar, dá uma olhada nesse vídeo:
https://www.youtube.com/watch?v=AbQcWO91Bx4

Mas como eu disse, nosso problema não era nos jobs em si e descobrimos isso adicionando logs assim que o schedule executava, antes de acionar o job. E nosso colega Caio fez muitos questionamentos sobre essa parte, dessa forma decidimos investigar e estudar mais sobre schedules para conseguir responder os seus questionamentos com confiança. A pista de que o problema estava ai foi que nosso log não estava acontecendo, ou seja, o schedule sequer estava sendo executado, mesmo com seu tempo bem baixo (5s).

O ChatGPT nos ajudou muito nesse aprofundamento e aos poucos, conseguimos entender exatamente o que estava acontecendo. E não só teoricamente, mas o Rafael fez uma PoC (Prova de Conceito) para validar nossa teoria que era: estávamos lidando com um problema de concorrência e a única forma de ter os schedules executando de forma independente era criando um ThreadPool dedicado para cada um deles.

Essa prova de conceito se tornou um case de projeto e pode ser encontrado nesse link: https://github.com/StringRafa/SchedulerThreadPool
Mas resumidamente, conforme a documentação do repositório:

A solução utiliza executores dedicados para cada scheduler, configurados por meio de:

@Async com Executors Dedicados: Cada agendador foi configurado para usar um executor específico, garantindo que as tarefas sejam processadas de forma independente.
Isolamento de Tarefas: Cada tarefa tem seu próprio executor, evitando interferências entre tarefas que possuem tempos de execução distintos.

Vejamos alguns trechos de códigos que refletem a solução:

Primeiro definimos um executor dedicado através de uma classe de configuração:

@Configuration
public class TaskExecutorConfig {

    @Bean(name = "threadPool-task1")
    public Executor task1() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(1);
        executor.setMaxPoolSize(1);
        executor.setQueueCapacity(5);
        executor.setThreadNamePrefix("threadPool-task1-");
        executor.initialize();
        return executor;
    }

}

Agora vincule esse taskExecutor dedicado ao seu método agendado:

@Component
public class ScheduledTasks {

    @Async("threadPool-task1")
    @Scheduled(fixedRate = 5000)
    public void executeTask1() {
        //Sua lógica de negócio
    }
}

Observações:

Se você define um @Scheduled sem definir nada, por default ele executará na thread principal da sua aplicação. Se existir outros schedules independente da configuração, eles ficarão aguardando a execução desse schedule, pois ele está ocupando a thread principal, então você tem um problema de concorrência.
Se você definir um @Scheduled com @Async sem definir um threadExecutor/threadPool específico, ele executará em um executor chamado SingleAsyncThreadPool, nesse caso ele executará uma tarefa por vez de forma sequêncial, mas ainda sofrerá bloqueio de algum scheduled que estiver usando a thread principal, como no primeiro caso. Esse tipo de configuração é ideal para tarefas sequenciais simples que não precisam de ajustes ou gerenciamento avançado.

Não sei se existem outras formas de resolver esse problema, caso saibam podem deixar nos comentários sua contribuição. Mas na situação que vivi, a única forma que encontramos de isolar cada agendador de forma mutuamente exclusiva, ou seja, sem que a execução deles não impactassem uns aos outros e mesmo assim fossem altamente configurações e flexíveis, foi usando um ThreadPoolTaskExecutor como exemplificado anteriormente.

Bom, o artigo de hoje era esse, espero que essa solução possa ajudar você se um dia passar por esse mesmo problema de concorrência. Estamos há um tempo rodando com essa solução em produção e foi com certeza um sucesso: até os gráficos do NewRelic ficam melhores de ver cada pool de thread executando, sua porcentagem de processamento ao longo do tempo, e até os logs agora possuem a threadpool de execução, facilitando entender como a dinâmica dos agendadores está ocorrendo.

Obrigado e até a próxima!
Um salve e agradecimento a Caio Senna e @rafael_j_souza

5 coisas que aprendi na minha carreira de TI - Parte 1

LeonardoMarques — Mon, 25 Nov 2024 13:39:04 +0000

Faala pessoal, no momento que escrevo esse artigo, eu estou com aproximadamente 7 anos de carreira. Sinto que cada pequeno insight aqui poderia ser um artigo inteiro e quem sabe um dia seja, mas nesse momento queria apenas condensar de forma que isso possa ajudar muitos que estão em diversos momentos da carreira.

Sua carreira não é linear

Na minha história com TI tive momentos de muito aprendizado: geralmente quando você mergulha em um problema a fundo ou quando tudo que está aprendendo é novo. E também momentos de leve estagnação, onde você meio que já dominou o dia a dia, não tem nada muito novo pra mexer, ficamos dando manutenção no que existe (sustentação).
E aqui temos um ponto de atenção: esse período é normal em qualquer empresa e momento da sua carreira, mas na minha visão é perigoso se ele se estender demais. Digo isso se você é uma pessoa que quer estar em constante evolução e aprendizado, pois ou você encontra uma maneira de continuar evoluindo na empresa, por quaisquer motivos que seja ou talvez seja o momento de alçar novos horizontes. Precisa aprender a analisar isso. Mas caso esteja confortável com isso, continuo achando perigoso, mas é um direito seu, o importante é se sentir bem e feliz, mas esteja ciente das consequências. E uma delas é sua *empregabilidade ficar ameaçada. *

Síndrome do Impostor é normal em TI

Se você se deparar com algo chamado "síndrome do impostor" é normal. É um sentimento de que você não é bom o suficiente, não sabe o suficiente, não está pronto para entrevistas, não está pronto para oportunidades melhores. E tudo bem, pode ser que não esteja mesmo, mas muitas vezes você já está bem melhor do que realmente acha, por isso a tal da síndrome. É algo que precisa aprender a lidar, pois trabalhar com TI vai te desafiar diariamente de modo que você certamente terá dúvidas se é bom de verdade ou se a carreira é pra você mesmo. Acho que a dica aqui é se preocupar mais com a sua postura do que só com suas habilidades e conhecimentos. A sua postura diante de como lidar e de quais atitudes tomar pode contar muito para se sentir mais confiante. Eu deixo como dica conversar com outros devs, procurar conteúdos de carreira, assim você terá uma noção melhor de como está o "sentimento de mercado", das pessoas e assim vai conseguir entender se está se cobrando demais.
Esse assunto também nos leva ao terceiro ponto.

Caso você ache que está com esses sentimentos de forma muito recorrente, não deixe de procurar ajuda profissional, pois pode ser um caso de terapia.

Você nunca vai saber tudo, pare de se cobrar tanto (essa é especialmente pra mim)

Aprenda a selecionar o que deve aprender, o que vai te trazer mais resultado no momento. Conhece o princípio de pareto?
TI é gigante de uma forma que não dá pra explicar, mas nas poucos vezes que procurei um roadmap de backend eu me deparei com algo assim:

Muitos iniciantes vão achar que devem obrigatoriamente dominar isso tudo para ser um bom desenvolvedor, mas aprendi que isso tudo não passa de um Guia. São coisas que você vai encontrar e que vai aprender naturalmente. Outros você vai precisar buscar quando necessário. Não ache que isso é uma árvore de habilidades de um jogo que você gosta e quer completá-la.
Tá, sobre o Princípio de Pareto, também conhecido como princípio 80/20. Ele pode ser aplicado em diversos cenários da vida, mas nesse caso ele se aplica assim:

Quais são os 20% de conteúdo/conhecimento nessa árvore que eu preciso saber e que vão resolver 80% das minhas necessidades diárias como um desenvolvedor backend Java? Dessa forma você foca em 20% de tudo que está aí e terá 80% de resultado e o resto você vai aprendendo aos poucos, conforme os problemas aparecem, conforme seus estudos avançam, sem pressão.

Desenvolva habilidades não técnicas

Trabalhar com TI apesar de ser muito técnico, também é muito sobre o que chamam de softskils que são habilidades não técnicas, como saber se relacionar com outras pessoas harmonicamente, principalmente trabalhar em equipe. Saiba negociar não só salários melhores e condições melhores de trabalho, mas também escopo de entregas, prazos e soluções. Na sua carreira, muitas vezes você não vai conseguir executar tecnicamente da melhor forma. Muitas vezes o prazo é rei e precisamos entregar do jeito que der, senão podemos perder o "time" e consequentemente dinheiro para a empresa. Pensa ai na Black Friday. Então, aprenda a entender as nuances de negociar prazos e soluções, isso certamente te dará maturidade para crescer na carreira.

Saiba interpretar o contexto da sua empresa

Trabalhar em uma startup é diferente de uma empresa grande. Eu sinceramente recomendo que tenha as duas experiências na sua carreira, vai te fazer um profissional melhor. Empresa grande geralmente tem mais burocracia, tem mais legado do que coisa nova, porém, os problemas tendem a ser mais complexos, dado que uma empresa grande muitas vezes já tem um volume de negócio grande e qualquer movimento em falso pode gerar prejuízo. A burocracia geralmente protege a empresa e mitiga riscos, pois é muito maior do que numa startup que muitas vezes ou não tem um produto que lucra ou o lucro ainda é baixo então os impactos são menores. Porém, tendem a ter menos legado, ser mais inovadores e ágeis para entrega de software. Outra grande diferença são questões financeiras, pois uma empresa grande é mais difícil quebrar ou te demitir por questões de custos, já startups possuem mais incertezas nesse sentido.
Por fim, sugiro que tenha as duas vivências e decida onde gosta mais de estar, um ambiente não é melhor que o outro, depende do seu perfil também.

Uma breve história de infraestrutura - Parte 1: Mainframes.

LeonardoMarques — Tue, 25 Apr 2023 12:05:41 +0000

Disclaimer: _A intenção do artigo é expor meu entendimento do assunto, não sou especialista. Pelo contrário, estou em fase de estudo, então me avisem se eu me equivocar em alguma explicação.

Este artigo é um resumo do vídeo Entendendo "Devops" para Iniciantes em Programação (Parte 1) | Série "Começando aos 40" do Fabio Akita. (Link)

Meu objetivo é entender melhor o caminho que percorremos desde o mainframe até as infraestruturas modernas com Docker e Kubernetes. Nessa parte 1, buscarei traçar uma linha histórica em alto nível dos anos 60 até meados de 2010.

Mainframes

Essa história começa nos anos 60, onde os mainframes reinavam. Eles eram máquinas imensas numa época onde o hardware era muito caro. Não eram tão poderosas, então alguns processos demoravam para executar, como a escrita (output) por exemplo. Com diversas pesquisas e estudos aliado ao avanço do poder das máquinas, foi possível particionar o mainframe para rodar mais de uma kernel (componente central de um sistema operacional responsável por ser o elo entre hardware software) por vez, cada um com seu sistema operacional e acesso a uma parte real dos recursos de I/O. Dessa forma foi possível otimizar melhor os recursos e ganhar produtividade.

Primeiras gerações de websites

Avançamos até os anos 90, com o hardware se tornando mais acessível a pequenas empresas, as máquinas se tornando mais poderosas e novas pesquisas e tecnologias surgindo. Nessa época a experiência do Unix foi trazida para o Linux permitindo multiusuário e multitarefa. Foi um cenário favorável para o surgimento de um novo modelo de negócios: empresas começaram a prover sites ao preço de uma assinatura mensal. Esses serviços de hospedagem conseguiam prover dezenas de sites numa mesma máquina, dividindo os recursos e o acesso utilizando o recurso de Virtual Host dos servidores web (mapeando urls para pastas de estáticos ou ativando programas cgi). Assim surgiram as primeiras gerações de websites usando a famosa stack LAMP (Linux, Apache, MySQL e PHP). Mas como é de se esperar, aqui começamos a ter muitos problemas de segurança. (se quiser aprofundar, veja o vídeo completo)

Container vs Virtualização

No início dos anos 2000, algumas pesquisas começaram a dar frutos. Nessa época tivemos tentativas de limitar o que um processo poderia fazer isolando recursos de uma mesma máquina com as tecnologias Jail(FreeBSD), LinuxVServer e containers de Solaris. Na prática essas soluções são baseadas em mentiras que o kernel conta para os processos fazendo-os acreditarem que possuem mais recursos e acessos do que realmente têm. A esse conceito damos o nome de containers.

Em contrapartida, a virtualização apesar de também querer otimizar recursos de uma mesma máquina, possui duas abordagens diferentes:

Bare Metal: Gerencia e compartilha recursos reais da máquina. Por isso os mainframes eram muito eficientes, cada máquina virtual tinha acesso a recursos reais de I/O.
Hosted: Um programa especial chamado Hypervisor que executa em um sistema operacional(SO) hospedeiro simula uma máquina virtual (recursos) executando um SO convidado. Consequentemente gera um peso grande de execução. Exemplo: VirtualBox

Com essa definição podemos entender a grande diferença entre virtualização e containers. Containers faziam processos executarem de forma restrita num mesmo sistema operacional. Já a virtualização, permite que um processo rode como se fosse numa máquina real ao virtualizar uma máquina inteira com um SO até mesmo diferente do SO original da máquina real. Essa virtualização é chamada de completa.

Apesar da vantagem da virtualização de conseguir executar um Linux numa máquina Windows por exemplo, isso era um processo muito lento e pesado pois o Hypervisor precisava "mentir sozinho" quando os processos precisavam fazer system calls. (Chamadas a instruções do kernel) Como evolução, surgiu a paravirtualização onde agora o SO também consegue mentir para os processos, tornando o desempenho do SO convidado melhor diminuindo a dependência do Hypervisor.

Visando ainda mais performance, a AMD e Intel começaram a trazer instruções de máquina específicas para virtualizações, tornando o desempenho quase de uma máquina real.

O início da infraestrutura como código

Esses avanços na virtualização se tornaram muito importantes para empresas que tinham que gerir datacenters. Pois poderiam de forma performática dividir os recursos das máquinas para diversos clientes diferentes. Mas configurar diversos servidores, com máquinas virtuais, redes e aplicações era uma tarefa bem trabalhosa. A tecnologia VPS(Virtual Private Server) da Microsoft aliviou esse problema. Ela conseguia automatizar a criação de máquinas virtuais usando imagens de SO (snapshots) tornando possível subir uma máquina nova em minutos. Mas isso ainda não resolvia o problema das empresas que precisavam gerir uma infraestrutura bem mais complexa.

Diante do quão trabalhoso era prover uma infraestrutura do zero "na mão", em 1993 já começavam a surgir ferramentas para automatização desse processo como a CFEngine (em 1998 a CFEngine3). Com essa ferramenta era possível escrever "receitas" de configuração (linguagem declarativa) que instalava várias máquinas da mesma forma com apenas um comando. Em 2005, tivemos o Puppet escrito em Ruby e em 2009 o Chef também escrito em Ruby. Essas ferramentas deram início a infraestrutura como código, sendo possível criar e compartilhar receitas em repositórios bem semelhante ao Git/Github usufruindo assim da colaboração da comunidade OpenSource.
Essas ferramentas funcionavam em uma arquitetura cliente e servidor. Onde cada cliente possui um processo agente que fica escutando um servidor para instalar e configurar o que for requisitado. Consequentemente era preciso configurar o agente e o servidor, o que poderia ser trabalhoso demais para uma única máquina.

Anos depois tivemos ferramentas agentless como Capistrano e Ansible que são mais simples de configurar para uma única máquina, em relação as outras ferramentas citadas anteriormente. O que torna mais simples é ter apenas o servidor usando conexão ssh como túnel para executar arquivos em máquinas remotas.
Cada ferramenta tem seu propósito, a grosso modo, sendo as agentless mais voltadas para casos de uso mais simples (desenvolvedores) e as baseadas em agent mais voltadas a infraestruturas mais complexas.

Mas será que essas ferramentas só servem para automatizar? Pelo contrário, além de agilizar a criação e configuração, essas ferramentas são essenciais para manter uma infraestrutura atualizada e segura. Também ajudam a destruir e reconstruir rapidamente máquinas que foram atacadas por exemplo. Tentar fazer essas tarefas "na mão", comando a comando torna o processo além de trabalhoso e improdutivo, também muito passível de erro por esquecimento de algum comando, além de difícil replicação.

Surgimento e expansão das Big Techs

Do meio para o final dos anos 2000, temos o surgimento e a expansão de grandes Tech Startups trazendo serviços e produtos que faziam as pessoas ficarem mais tempos conectadas na internet de um jeito nunca visto antes. Muitas tecnologias surgiram e evoluíram para conseguirem apoiar a escala dessas empresas. Na parte 2 do vídeo vamos entender como a evolução dessas tecnologias culminaram no Docker e Kubernetes que temos hoje.

Continua...

Uma introdução conceitual em IaaC com Terraform

LeonardoMarques — Mon, 06 Mar 2023 10:38:08 +0000

Disclaimer: _A intenção do artigo é expor meu entendimento do assunto, não sou especialista. Pelo contrário, estou em fase de estudo, então me avisem se eu me equivocar em alguma explicação.

Introdução

Na minha jornada de desenvolvedor, infra nunca foi um assunto que eu curti. Sempre achei chato esses detalhes de "baixo nível". Mas num cenário de mercado de trabalho cada vez mais acelerado e competitivo, as empresas estão buscando e exigindo que saibamos sobre todo o processo de desenvolvimento de software (talvez eu escreva sobre code ownership). Então vamos lá, entender de vez, esse tal de Terraform.

Por que usar Terraform?

Para disponibilizar e manter um produto, site ou plataforma digital, é necessária toda uma infraestrutura de máquinas virtuais, banco de dados, rede, entre outros recursos. Existem profissionais dedicados a cuidar de toda essa parte, que antigamente era toda feita manualmente.

Mas isso certamente não era algo muito prático de se fazer e gerenciar. Não é de hoje que a infraestrutura começou a ser pensada como código. O que faz todo sentido, pois é algo que nós profissionais de TI já estamos acostumados. Hoje existem diversas ferramentas para prover infraestrutura através de código, sendo o Terraform uma das mais usadas .

IaaC - Infrastructure as a Code

Vamos olhar o seguinte projeto de infraestrutura para um website e entender onde o Terraform entra:

Caso queira se aprofundar praticando a criação dessa infra com Terraform, vou deixar a referência no final do artigo.
Mas aqui eu não quero focar na sintaxe ou em detalhes de implementação do Terraform, eu quero conectar o código do Terraform com a arquitetura de uma infraestrutura.

Explicando o projeto:

A infraestrutura foi projetada dentro da cloud da Amazon: AWS.
O código encontra-se versionado no Github e de lá ele passa pelo pipeline de CI/CD que utiliza 2 serviços também da Amazon (CodePipeline e CodeBuild). Mas aqui poderia ser também um GitLab ou CircleCI por exemplo.
Como estamos falando de um site estático, no final do pipeline teremos um build com os arquivos do site que serão disponibilizados num bucket do S3 (serviço de armazenamento simples da Amazon).
Para disponibilizar esse site de forma rápida e com baixa latência, foi utilizado o serviço CloudFront da AWS junto de algumas configurações de certificados e políticas de acesso.
Por fim, foi utilizado o Route 53 como serviço de DNS que é a camada mais próxima do acesso externo ao site pelo browser.

Ok, mas onde entra o Terraform?

O Terraform vai nos ajudar a provisionar infraestrutura, isto é, na parte de recursos e configurações necessárias para disponibilizar esse site na internet. E aqui começa o paralelo entre o Terraform e uma infraestrutura física: vamos mapear e configurar resources.
Por exemplo:

O bucket do S3 é um recurso que precisamos configurar, pois vamos guardar os arquivos de build do site dentro dele.
o cloudfront é um recurso que vamos configurar, pois através dele vamos disponibilizar o acesso aos estáticos no bucket com a maior rapidez possível. Também não queremos ninguém acessando o bucket diretamente, por questões de segurança.
O Route 53 é um recurso que vamos utilizar para configurar DNS do site apontando para zonas e domínios seguros.

Principais blocos e comandos

Quando falamos de Terraform, estamos falando de código, então é esperado que tenhamos automatização e reutilização. Dessa forma, além do bloco resource, o terraform também possui outros blocos importantes como:

variable- uso padrão de sempre.
output- usado para obter informações pós criação de recursos e assim construir infraestrutura de forma dinâmica.
data- usado para obter informações de recursos externos.
modules- um dos blocos mais importantes do Terraform. Basicamente segue a mesma ideia geral em termos de programação: evitar replicação de código através do reuso. Com ele é possível tanto reutilizar módulos locais quanto módulos publicados externamente, trazendo mais facilidade, rapidez e flexibilidade na montagem da sua infraestrutura.

Por fim, o Terraform trabalha com poucos comandos, mas com muitas opções de customização. A ideia geral dos comandos é bem intuitiva: primeiro vamos inicializar o que for necessário, planejar o que vamos construir e aplicar de fato. Os respectivos comandos:

terraform init (inicializa os arquivos do terraform e baixa módulos, caso especificados)
terraform plan (mostra um resumo do que será executado, ótimo para validar suas mudanças antes de executar)
terraform apply (executa o plano e cria a infraestrutura real)
terraform destroy (bastante usada para estudo)

E outros comandos que gosto de usar são:

terraform validate (para validar seu código antes do plan)
terraform fmt (para formatação no padrão do Terraform)

Terraform State

Outro conceito incrível e importante do Terraform é o state. O arquivo terraform.tfstate mapeia e armazena o estado da sua infra de forma que seja possível recriá-la inteira, caso precise. Também é usado para melhorar a performance de escalabilidade, além de ser possível versioná-lo para manter um histórico de mudanças.

Conclusão

Bom, pra quem chegou até aqui eu gostaria de agradecer e espero que tenham conseguido pelo menos criar uma imagem mental de como saímos de uma infraestrutura física (em nuvem na verdade) para entendê-la como código através do Terraform. Para mim foi meio abstrato no início, mas é só questão de exposição e um pouco de prática para ficar mais claro. Como desenvolvedor, acho importante sabermos entender o suficiente para dar manutenção num código Terraform. Acho que entender os conceitos e o paralelo com uma arquitetura de um projeto é um bom começo.

Abaixo vou deixar alguns conteúdos para se aprofundarem, caso se interessem.

Referências

Documentação oficial Terraform: https://developer.hashicorp.com/terraform

Curso fiz na Udemy e recomendo:
DevOps: AWS com Terraform Automatizando sua infraestrutura - Cleber Gasparoto

Artigo da arquitetura usada no exemplo:
https://medium.com/@zakariakhalaf/automate-your-static-website-deployment-on-aws-with-terraform-2419d91102cc

O que é uma infraestrutura como código?
https://www.redhat.com/pt-br/topics/automation/what-is-infrastructure-as-code-iac

Uma introdução ao GitLab CI/CD

LeonardoMarques — Mon, 06 Feb 2023 20:42:36 +0000

Conceitos básicos sobre CI/CD

Integração Contínua
Resumidamente, é uma prática de desenvolvimento de software em que os desenvolvedores, de forma regular e confiável, juntam suas alterações de código em um repositório central. Depois disso, builds e testes são executados.

Este processo pode ser muito trabalhoso se feito de forma manual. Por isso, hoje utilizamos diversas ferramentas para automatizar esse processo, sendo o Gitlab uma delas. Dessa forma, é possível criarmos scripts que vão “buildar” e “testar” nossa aplicação automaticamente sempre que um desenvolvedor fizer um “push” no repositório que especificarmos.

Entrega Contínua

Segundo a documentação do Gitlab, é um passo além da integração contínua. Onde sua aplicação não é somente “buildada” e testada, mas também “deployada” continuamente. Mas você ainda realiza o deploy manualmente.

Implantação Contínua

Segundo documentação do Gitlab, é outro passo além da Integração Contínua onde o deploy ocorre de forma automática sem intervenção humana.

Por fim, Segundo Lucas Gertel:

Juntas, essas práticas conectadas costumam ser chamadas de “𝗖𝗜/𝗖𝗗 𝗣𝗶𝗽𝗲𝗹𝗶𝗻𝗲”. Eles geralmente são mantidos usando a abordagem DevOps ou SRE. Existem vários benefícios de ter pipelines de CI/CD, como melhor colaboração e qualidade de código, bem como sistemas mais ágeis e confiáveis.

Agora vamos entender na prática como construir um simples pipeline com Gitlab.

Gitlab

O que é o Gitlab?
Segundo meu entendimento: é uma plataforma com ferramentas e soluções de DevSecOps que busca ajudar as empresas a entregar software de maneira mais rápida através da automatização de processos.
Para mais informações, sugiro visitar o site oficial: https://about.gitlab.com/

Conceitos de CI/CD no Gitlab

pipeline: É um fluxo de etapas chamadas de stages que executam um ou mais jobs. A ideia é que quando realizamos um ‘push’ para alguma branch mapeada, esse pipeline vai ser disparado pelo Gitlab e vai realizar todas as etapas necessárias para entregar essas alterações no ambiente em questão, tudo de forma automática.
stage: é uma agregação lógica de jobs. Exemplos de stages: build, test.
job: É um dos elementos fundamentais do pipeline. Sua principal função é executar scripts que contém comandos de Linux, Node, Maven, depende do objetivo do job.

Construindo um pipeline com Gitlab

Para começar, precisamos criar um arquivo específico na raiz do seu repositório, chamado: .gitlab-ci.yml

O Gitlab reconhece esse arquivo e executa automaticamente qualquer pipeline configurado nele assim que uma ação específica acontece, como por exemplo um merge na branch master.

É neste arquivo que vamos descrever todo nosso pipeline e diferentes estratégias para diferentes branches, dependendo do seu contexto. É complicado mostrar um exemplo real, pois o pipeline é construído de forma particular ao seu código, projeto, estratégias, etc… então vou mostrar um exemplo simples da Digital Ocean (veja referências).

Arquivo .gitlab-ci.yml:

image: node:latest

stages:
  - build
  - test

cache:
  paths:
    - node_modules/

install_dependencies:
  stage: build
  script:
    - npm install
  artifacts:
    paths:
      - node_modules/

test_with_lab:
  stage: test
  script: npm test

Neste simples pipeline temos:

A definição global de uma image do tipo “node:latest” que será usado por todos os jobs que não especificarem uma imagem.
Dois estágios, sendo eles “build” e “test”
Realizaremos cache do diretório node_modules, porque pode ser necessário em outro job
Temos o job install_dependencies que vai executar no stage de build. Seu script possui um único comando “npm install” que gera o artefato node_modules
Temos um segundo job test_with_lab que vai executar no stage de “test” cujo script possui apenas o comando “npm test”
Como neste exemplo não foi especificado onde esses jobs vão executar, por exemplo “only: master”, então basta realizar um commit de teste e o pipeline começa a executar conforme imagem abaixo:

Conclusão

Chegamos ao final deste overview de Gitlab, a ideia realmente não era aprofundar, mas introduzir conceitos de CI/CD, exemplificar com o Gitlab e mostrar as vantagens de utilizar essas práticas que hoje já são bem difundidas e utilizadas no mercado.
Espero ter contribuído e qualquer dúvida, crítica ou sugestão, fiquem a vontade para deixar nos comentários.

Referências

https://www.redhat.com/pt-br/topics/devops/what-is-ci-cd
https://www.linkedin.com/feed/update/urn:li:activity:7026552798615941120/
https://docs.gitlab.com/ee/ci/introduction/
https://www.digitalocean.com/community/tutorials/como-configurar-pipelines-de-integracao-continua-com-o-gitlab-ci-no-ubuntu-16-04-pt