Continuando nossa série sobre a arquitetura de uma pipeline, caso você tenha perdido a primeira parte do artigo, clique aqui.

Autênticações

A camada de autenticação é uma das mais importantes. Ela se destaca na ponte de confiança entre sua automação e os serviços externos como Sonar, GoogleCloud e etc. Garantindo assim que o pipeline possa acessar recursos necessários sem expor credenciais de usuários. Quando chamamos algum serviço, seja por API ou usando templates prontos de pipeline, precisamos muita das vezes nos autenticar para usar o serviço. Normalmente essas chaves ou senhas de autenticação ficam salvas como sugerido no primeiro artigo.

Por que isso é tão importante?

Imagine uma empresa com 100 pipelines e sem uma camada de autenticação ? Naturalmente, cada projeto iria se autenticar de uma forma diferente, com possibilidades de senhas espalhadas por YAML, scripts e etc. Em alguns casos, como Azure DevOps ou a versão Enterprise de GitHub, você consegue manter toda camada de autenticação centralizada em um único.

Pipeline
  ↓
Identity
  ↓
Resource

Além de uma pipeline não deveria ter acesso de administrador, seguindo a lógica de centralizar credenciais, você consegue manter a boa prática de Least Privilege.

Nesse cenário, em caso de aumento de criação de pipelines, conseguimos também manter a escalabilidade com pouca configuração, mantendo assim um padrão sólido e consistente de controle de serviços e acessos.

Essa separação é o que transforma uma pipeline de um simples conjunto de scripts em uma plataforma segura, auditável e escalável, que é exatamente o objetivo da arquitetura em camadas proposta no artigo.

Isolar a autenticação de sua pipeline garante 4 grandes princípios de uma boa arquitetura: segurança, menor privilégio, auditoria e escalabilidade. Isso torna fácil a execução de um projeto que se escala conforme o crescimento da empresa.

Já conhece nosso canal no youtube?
E nosso canal público do Discord?🔗

Entre em contato também através do nosso email engenharia@tbxtech.com, até mais!

Ambientes de pipelines de CI/CD vão muito além de scripts e deployments. Naturalmente, qualquer projeto cresce e com isso surge a necessidade de uma arquitetura mais organizada e reutilizável ( caso você não queira sofrer gerenciando pipelines como unidade ) .

Neste artigo, irei apresentar de forma organizada uma arquitetura de CI/CD em camadas bem definidas, cada uma com responsabilidades específicas, promovendo:

• Reuso
• Padronização
• Segurança
• Escalabilidade
• Facilidade de manutenção

Templates — O que representa

A camada de Templates é o alicerce da arquitetura. Aqui é onde iremos reaproveitar trecho de códigos, containers, scripts. O principal objetivo desse princípio é você organizar suas ideias e entender como os procedimentos irão acontecer dentro da sua pipeline. Sem templates reaproveitáveis, cada nova pipeline começaria do zero, isso até que não é um problema, mas quando você está em um ambiente onde 100 repositórios usam a mesma pipeline, isso acaba se tornando um trabalho de grandeza exponencial e nada escalável. Melhor efetuar manutenção em um único lugar com grandes riscos do que em diversos lugares com risco menor.

Além do exemplo apresentado, você pode criar templates para deployments, integrações e outros processos.

Parameters — Configuração Dinâmica

Após criarmos os fundamentos da base da pipeline, o segundo passo é pensar em como deixar o comportamento desses templates flexíveis e dinamicos. Vamos imaginar que a pipeline é um liquidificador, esse liquidificador tem a capacidade de gerar um suco ou vitamina, certo? Agora, imagina que eu quero suco de laranja e você de limão. Para isso, você utilizaria o mesmo template com a função “fazer suco”, que seria o liquidificador, e os parâmetros seriam nossas diferentes escolhas, por exemplo:

• Qual versão do NodeJS que você quer utilizar ?
• Sua aplicação tem teste de contrato? Tem teste de integração?
• Vocês fazem delivery de arquivos? Ou deployment de um container?

Considerações finais, Templates = estrutura fixa e Parameters = variáveis de comportamento dentro dessa estrutura

Variables — Configurações e Contexto

Aprendemos a criar nossa arquitetura, depois entendemos como podemos generalizar a execução, tornando nossa pipeline mais reaproveitável possivel. Agora abordaremos as variáveis e o por que elas são úteis.

Variaveis representam valores que variam por ambiente ou contextos. Imagine que você tem uma ferramenta para fazer análise do seu código e descobrir se há erros ou falhas. Essa ferramenta se encontra na versão 1.0, porém, você percebe que a nova versão, a 2.0, contém novas funcionalidades, e agora? Como iremos atualizar todos os parametros ?

Neste momento é onde fazemos a separação de responsabilidades. O time de desenvolvimento deve apenas se responsabilizar por determinar o comportamento das pipelines através dos parametros, por exemplo, escolhendo qual é a stack que iremos buildar o código, versão, se há testes ou não. Quem determina o comportamento das pipelines é o time de DevOps, e a melhor forma de fazer isso é através de variaveis, exatamente pela facilidade que temos de centralizar todos esses dados apenas em um unico local e nossas pipeline absorverem essas informações.

Isso faz com que temos uma solução que armazenar configurações sensíveis ou configurações e evita hardcoding.

Para que o texto não fique extenso, vou encerrar as provocações por aqui e continuar em breve nas próximas publicações, fiquem atentos!

Veja outros temas da área em nosso canal do YouTube (link).

E participe também do nosso canal no Discord, com dicas e laboratórios (link do Discord).

Tem alguma dúvida ou sugestão? Mande para a gente pelo nosso e-mail: engenharia@tbxtech.com.

Arquitetura em Camadas para Pipelines CI/CD — Parte 1 was originally published in tbx-tech/editorial on Medium, where people are continuing the conversation by highlighting and responding to this story.

Vigiar sem estar presente, barrar sem ser chato. Pipelines são os melhores aliados para equipe de qualidade.

Nos dias de hoje, uma pipelien de entrega contínua (Continuous Integration/Continuous Deployment — CI/CD) é uma prática fundamental para empresas que desejam acelerar o desenvolvimento de software e garantir eficiência em colocar seus serviços em produção de forma rápida e eficiente. No entanto, para garantir que essa abordagem funcione corretamente e produza resultados de alta qualidade, os testes desempenham um papel crucial e neste artigo, vamos explorar como a área de testes podem usufruir de um ciclo de CI/CD de pipelines e como podemos barrar uma má implementação de ir para produção.

Para melhor aproveitamento desse artigo, considero um pré requisito a leitura sobre o que é uma pipeline de software e a criação de uma pipeline eficiente para sofware.

Momento de execução de cada tipo de teste

Testes de componentes

Os testes de componentes são ideais para validar a integração entre componentes do sistema. À medida que seu sistema cresce, naturalmente a quantidade de componentes também cresce e isso pode se tornar um problema, pois muitas das vezes a pipeline irá aguardar o fim do teste para prosseguir para a próxima fase.

Num cenário ideal, esses testes não devem passar de 20 minutos e devem ser programados para serem executados no ambiente de testes para não tornar o processo de CI/CD um pouco mais lento.

Ferramentas que podemos utilizar nesse processo são: JUnit, Jest, PyTest, Mocha, TestNG e Cypress.

Testes fim-a-fim ( End-to-end )

Aconselhável habilita-lo em qualquer ambiente com o intuito de garantir que as features básicas do sistema estejam minimamente operacionais. Como naturalmente são testes complexos que asseguram que cenários reais, seu tempo pode variar entre 10 minutos a 40 minutos.

Ferramentas que podemos utilizar nesse processo são: Puppeteer, Selenium, Robot Framework ou Cucumber.

Testes de contrato

O teste de contrato ideal é utilizado para garantir que o código desenvolvido em questão corresponde aos acordos escritos previamente em contrato/documentação. Podemos economizar tempo nos pipelines apenas testando no ambiente de pré-produção, pois, assim como testes de componentes, os testes de contrato aumentam seu tempo de execução a cada nova implementação e validação, principalmente se há uma grande quantidade de comunicação entre serviços.

Ferramentas que podemos utilizar nesse processo são: Swagger, Pact.io.

Teste de web-page-quality

Como esses testes fazem análise estática dos componentes web, podemos executá-los no ambiente de produção fora da janela de horário comercial. Não há teste de funcionalidades nem carga no sistema com esse teste. Esses testes são executados para entender o comportamento e performance dos componentes de front-end.

Ferramentas que podemos utilizar nesse processo são: Lighthouse.

Testes de performance

O ideal seria utilizar o máximo de recurso computacional das pipelines para simular a quantidade real de usuários ou cenários de picos de requisições de usuários. Outro conselho é executar os testes de performance em janelas fora do horário comercial devido ao excessivo uso da pipeline, que pode se tornar um gargalo durante o horário comercial.

Ferramentas que podemos utilizar nesse processo são: K6, Jmeter.

Testes de regressão

Os testes que tem a maior carga e se não um dos mais importantes para qualquer release. Esse tipo de execução acaba exigindo muitas horas de execução, pois tem a necessidade de realizar testes em versões anteriores do sistema para garantir que a sua evolução não cause nenhuma surpresa. Normalmente esses tipos de testes acabam levando horas para serem executados tornando inviável a execução de forma diária ou durante qualquer chamada no fluxo de CI/CD. O mais ideal para esse tipo de teste seria que todo recurso computacional obsoleto ( provavelmente de madrugada ) possa ser utilizado para validar todas as evoluções do sistema. Alguns serviços de pipelines como Bitbucket e Azure DevOps permitem que algumas pipelines possam ser executadas através de um gatilho ou até mesmo através de tarefas agendadas, o que seria o mais ideal para esse tipo de testes, fazendo com que todo recurso computacional obsoleto ( provavelmente de madrugada ) possa ser utilizado para validar todas as evoluções do sistema.

Ferramentas que podem auxiliar no processo

Uma das maravilhas do processo de CI/CD é a capacidade de criar checks para serem validados sem ter que alocar uma pessoa ou uma equipe para fazer gestão de coisas repetitivas, algumas ferramentas podem permitir que você controle a qualidade do código que foi implementado, como:

Jira: Como o JIRA hoje possibilita o uso de API, você pode usar o modelo de integração entre o Git e o Jira, para que o desenvolvedor sempre commit o ticket que ele está trabalhando como “JIRA-123 — Implementando conexão com Redis” e então, durante a pipeline resgatar esse ticket para validar via API se o ticket se encontra em um status desejado para ir para produção, caso não esteja, a pipeline proibe a mudança no ambiente.

K6 ou JMeter: Com uma das ferramentas, você pode efetuar excessivas chamadas para seu serviço via CLI simulando testes de carga.

Sonar: Com o recurso de Quality Gate, o Sonar consegue analisar a qualidade do código desenvolvido e a quantidade de testes proporcional ao que foi desenvolvido e caso não atenda os requisitos desejados, ela pode forçar a pipeline de não prosseguir com o próximo passo.

Pact: Permite testar contratos entre serviços independentemente da tecnologia usada para implementar esses serviços, em caso de falha, podemos bloquear os próximos passos também.

Eai, como estão os seus testes nas pipelines?

Nos próximos artigos, trarei alguns exemplos práticos de como utilizar as ferramentas dentro de um fluxo de CICD.

Veja outros temas da área em nosso canal do YouTube (link).

E participe também do nosso canal no Discord, com dicas e laboratórios (link do Discord).

Tem alguma dúvida ou sugestão? Mande para a gente pelo nosso e-mail: engenharia@tbxtech.com.

DevOps — Como um tester pode se beneficiar de uma pipeline? was originally published in tbx-tech/editorial on Medium, where people are continuing the conversation by highlighting and responding to this story.

Durante a fase inicial de validação do ciclo de desenvolvimento de software, por meio da integração contínua e entrega contínua (CI/CD), é fundamental utilizarmos ferramentas que nos proporcionem métricas e relatórios sobre as vulnerabilidades existentes em nosso código. Esse conjunto de práticas e abordagens é amplamente conhecido como DevSecOps, que enfatiza a integração da segurança desde o início do processo de desenvolvimento. Neste artigo, apresentarei algumas sugestões e estratégias que podemos incorporar em nossos pipelines de desenvolvimento, visando o fortalecimento do pilar de segurança em nosso projeto.

Para melhor aproveitamento desse artigo, considero um pré requisito a leitura sobre a criação de uma pipeline eficiente para sofware.

Se você utiliza o GitHub como fonte para administrar seu código, você não precisa se preocupar quanto a implementação, muito das validações que comentarei já são nativas.

Quando Analisar

No âmbito da segurança de software, duas formas cruciais de análise ganham destaque: a Análise Estática e a Análise Dinâmica de código. Cada uma delas desempenha um papel vital na detecção e mitigação de vulnerabilidades, contribuindo para a criação de aplicações mais seguras e confiáveis.

A Análise Estática de Código é uma técnica fundamental que visa encontrar vulnerabilidades no código-fonte de uma aplicação sem a necessidade de executá-la. Esta abordagem é altamente eficaz e se encaixa perfeitamente no contexto de integração contínua e entrega contínua (CI/CD).
Sugestão: Um momento crucial para aplicar a Análise Estática de Código é quando um Pull Request (PR) é aberto. Nesse ponto, é possível ter um controle preciso sobre quaisquer novas vulnerabilidades que possam estar sendo introduzidas no código-fonte.

Na Análise Dinâmica de Código, a abordagem muda consideravelmente em comparação com a Análise Estática. Aqui, a ênfase está na interação com a aplicação em tempo real, simulando ataques e, o mais importante, identificando todas as vulnerabilidades e brechas disponíveis no sistema, muitas vezes em tempo real.

Sugestão: Normalmente, algumas ferramentas oferecem a possibilidade para executar essa análise em paralelo, o que seria muito ideal, pois dependendo do tamnho da aplicação, esse tipo de validação pode levar até horas e isso pode acarretar em um fluxo de CI/CD lento ( totalmente oposto do que ele propõe, entrega rápida, feedback rápido ).

Como Analisar

No código

Gravar senhas diretamente no código ou em arquivos .env, contendo dados sensíveis como tokens, é um erro comum, mas perigoso, que pode representar um grande risco, especialmente para especialistas em segurança de aplicações. Ferramentas como GitLeaks e TruffleHog podem identificar e reportar essas vulnerabilidades, enquanto ferramentas intermediadoras podem proteger suas informações de exposição na internet.

Dependências

Há também vunerabilidades que também são encontradas em frameworks de mercado, no qual, sempre devemos nos manter atualizados para que nenhuma falha possibilite alguma brecha ( há muitos casos reportados via OWASP ). Para isso, há ferramentas que são capazes de analisar todas as dependências do seu código ou seu container. O melhor momento para se executar isso, é exatamente no mesmo momento que você valida a estrutura básica do seu código. Para esse tipo de operação, ferramentas como Trivy, Snyk e Black Duck são referências.

Nos próximos artigos, trarei alguns exemplos práticos de como utilizar as ferramentas dentro de um fluxo de CICD.

Veja outros temas da área em nosso canal do YouTube (link).

E participe também do nosso canal no Discord, com dicas e laboratórios (link do Discord).

Tem alguma dúvida ou sugestão? Mande para a gente pelo nosso e-mail: engenharia@tbxtech.com.

DevOps — Como aumentar a segurança de seu software usando pipelines was originally published in tbx-tech/editorial on Medium, where people are continuing the conversation by highlighting and responding to this story.

Uma das maneiras mais eficazes de localizar algo é organizando-se. Isso pode ser feito através de lógicas pessoais ou utilizando algoritmos, como BubbleSort e QuickSort, que facilitam a ordenação. Na indústria de software, a organização de códigos, WIKIs, documentações e contratos de API requer esforço. Estabelecer e manter essa cultura organizacional é um desafio, mas, sem dúvida, é essencial e impacta positivamente na produtividade dos desenvolvedores. Uma das ferramentas que pode beneficiar uma equipe de desenvolvimento é o OpenGrok, pelos seguintes motivos:

• Indexação: O OpenGrok utiliza um sistema de indexação de palavras, tornando as pesquisas por termos, expressões, trechos de código ou históricos de commits mais eficientes.
• Pesquisa: A ferramenta permite pesquisar por definições, nomes de arquivos, trechos de texto, expressões regulares, padrões, entre outros.
• Interface Web: A interface web do OpenGrok facilita o acesso rápido à estrutura de diretórios, permitindo uma navegação ágil por projetos e pastas.

Como instalar OpenGrok

Uma abordagem prática e direta é utilizar um container Docker que já possui todo o ambiente necessário para o funcionamento da ferramenta. É fundamental mapear, como volume, a pasta que contém todos os diretórios de seus repositórios. Quanto mais documentos o OpenGrok processar, mais otimizada será a sua experiência de uso.

docker run -d --name opengrok -v /path/to/your/source:/src -p 8080:8080 opengrok/docker

Note que o primeiro index de arquivos pode levar alguns minutos, mas caso você queira forçar o sync você pode executar o comando:

opengrok-indexer -a opengrok/lib/opengrok.jar -- -s /src -d opengrok/data -H -P -S -G -W opengrok/etc/configuration.xml -U http://localhost:8080

Como usar o OpenGrok

Agora posso acessar meu navegador no endereço http://localhost:8080/ e usar a ferramenta para encontrar as refências que você precisa encontrar.

Dicas importantes

• Crie uma pipeline para sempre para sempre executar git pull dos repositórios, assim você garante que a aplicação estará sempre exibindo o conteúdo mais recentemte.
• Antes de usar o OpenGrok, você precisa indexar o seu código-fonte isso garante que os resultados da pesquisa estejam sempre atualizados. Para isso utilize a variável de ambiente SYNC_PERIOD_MINUTES
• Caso a indexação de arquivos não acontecessa, execute o container no modo iterativo e execute

opengrok-indexer -a opengrok/lib/opengrok.jar -- -s /src -d opengrok/data -H -P -S -G -W opengrok/etc/configuration.xml -U http://localhost:8080

Conclusão

OpenGrok é ferramenta open-source que pode ser muito útil para auxilair desenvolvedores, analistas de requisitos e desenvolvedores em tarefas para reaproveitar trecho de códigos ou auxiliar na descoberta de códigos ou históricos de uma forma bem fácil e amigável

Veja outros temas da área em nosso canal do YouTube (link).

E participe também do nosso canal no Discord, com dicas e laboratórios (link do Discord).

Tem alguma dúvida ou sugestão? Mande para a gente pelo nosso e-mail: engenharia@tbxtech.com.

Aumentando a produtividade de um time de desenvolvimento com OpenGrok was originally published in tbx-tech/editorial on Medium, where people are continuing the conversation by highlighting and responding to this story.

An Elegant Puzzle: Systems of Engineering Management

Simplesmente um livro incrível onde Will Larson descreve sobre os desafios que ele encontrou ao longo do tempo em gerenciar uma equipe técnica. O livro exige bastante maturidade de quem lê, por que constantemente Will apresenta situações que podem dar errado e depois ele cria um capítulo inteiro explicando como também deu certo com ele e para mim isso é o maior sinal de que não bala de prata e receita de bolo, cada empresa.

Start With Why

Nesse livro se discute muito sobre o que e como você planeja levar sua ideia, convencer investidores e agradar clientes. Esse livro traz muito exemplo do por que grandes ideias morrem e do por que muito das vezes uma boa cultura objetivos bem alinhados e bom cuidado podem fazer sua empresa disputar espaço com grandes empresas milionárias. Quando li esse livro comecei a enxergar além do óbvio e como podemos vender e organizar o pit-elevator da nossa área/empresa.

Comunicação Não-Violenta

Comunicar sem impor seus valores, Observar sem avaliar, Identificar suas fraquezas, Escutar sem opinar, Responsabilizar-se quando necessário, Pedir sem mandar, entender que a Raiva sempre tem um motivo e ele pode ser mais pessoal do que você imagina, são os principais pilares sobre os quais esse livro tenta apresentar novas formas de olhar a comunicação de forma geral. Além de ser bom para leitura, é bom para dividir com seus funcionários, se você aprender a entende-los e eles aprenderem a absorve-lo, irá facilitar muito o dia-a-dia de vocês. Surpreendente mente de 20 pessoas que me responsabilizo, 5 leram esse livro seguindo minhas orientações nos feedbacks 1:1, advinha com quems meu relacionamento tem melhorado dia após dia?

Atomic Habits

Conheci esse livro por causa desse artigo do autor. Se você pensa em criar uma equipe de alta performance, ler esse livro é o dar seus passos. James Clear traz dados, fatos, formas e ideias de como podemos melhorar a performance do indivíduo ou até mesmo de uma organização e sistema.

Lá vem todo mundo

O melhor termômetro para você medir a eficiência de qualquer projeto é a aceitação publica ou dos seus clientes. O interessante é que nós como sociedades já trabalhamos inconscientemente como um coletivo, só não sabemos. Esse livro apresenta estudos e situações intrigantes, onde conjunto de pessoas de forma consciente ou não ajudaram a resolver problemas, organizarem coisas e etc, o segredo é você descobrir como usar isso de forma positiva te beneficiando.

Plataforma a revolução da estratégia

Criar boas soluções não significa que elas serão bem aceitas pelo cliente final, esse livro trás reflexões interessantes sobre o desenvolvimento de uma plataforma de serviços. iideias arquiteturais e riscos de implementação e falhas no processo de gerar a relação simbiótica entre cliente e fornecedor, esse livro pode ser um guia básico para qualquer implementação de serviço que foque em publicos de forma genéricas.

The Manager’s Path

Por mais que esse livro se chama A Arte da Gestão, esse livro ensina muito sobre como pessoas podem gerenciar seus líderes e seus gerentes. Camile foca muito em criar processos e cultura clara para seus liderados, processo de feedback, analise de capacidade de recursos e pode servir muito como os primeiros passos para seus primeiros passos para gestão. Se você precisa de um guia prático e simples para seu primeiro ano de gestor, definitivamente esse seria seu primeiro passo!

Veja outros temas da área em nosso canal do YouTube (link).

E participe também do nosso canal no Discord, com dicas e laboratórios (link do Discord).

Tem alguma dúvida ou sugestão? Mande para a gente pelo nosso e-mail: engenharia@tbxtech.com.

Livros que todo gerente técnico deveria estudar was originally published in tbx-tech/editorial on Medium, where people are continuing the conversation by highlighting and responding to this story.