AWS: Introdução à plataforma de cloud computing
Neste artigo iremos descrever o Amazon Web Services. Embora seja um artigo introdutório, é ideal que você que esteja lendo tenha breve conhecimento sobre a temática de Cloud Computing. O que é AWS? AWS é uma plataforma de serviços para computação em nuvem, com diversos produtos para diversas áreas, como aplicações, armazenamento, redes, inteligência artificial, segurança, entre outros. Assim como a grande maioria dos serviços para computação em nuvem, o AWS oferece, dentro dos serviços oferecidos, benefícios como: Custo-benefício: ao invés de você investir em servidores físicos e equipe de manutenção, podemos optar por vários modelos de contrato, desde pagamento por uso até comprometimento de anos de uso para receber descontos de até 60%. Segurança: com diversos produtos e serviços para segurança de dados e aplicações, inclui criptografia de dados, firewalls e conformidades com padrões de segurança Escalabilidade: com a facilidade para ajustar recursos conforme ele é demandado, podemos aumentar a sua capacidade em minutos e reduzir sempre que necessário. Quais serviços são oferecidos? De forma geral e holística, o AWS oferece serviços para soluções em containers, aplicações web, computação em nuvem, banco de dados, armazenamento, tecnologia sem servidores, machine learning, IA e muito mais! Vamos entender como cada serviço pode auxiliar no seu dia a dia. Armazenamento: serviços de armazenamento em nuvem da AWS. Ideais para armazenar grandes volumes de dados, de aplicações, backups, arquivos de máquinas virtuais e muito mais! Além de seguros, esses produtos oferecem disponibilidade assertiva das suas informações. Serviços como S3, Glacier e Snow se encontram nesse pilar. Banco de Dados: serviços voltados à disponibilização de banco de dados SQL, NoSQL, Redis, Memcached e Graph Database. Dentro desse ecossistema encontramos o RDS, DynamoDB, ElasticCache e o Neptune. Esses serviços permitem e facilitam no armazenamento de informações para aplicações. Serverless, Containers e Aplicações: aqui você encontra soluções para criação de sites como LightSail, ou para aplicações ou entrega rápida de um MV, temos serviços como Lambda, Fargate e Beanstalk. AI e Machine Learning: serviços voltados para aprendizado de máquina e IA. Nessa categoria temos o Rekognition que faz reconhecimento de vídeos e imagens, o Comprehend para linguagem natural em texto, o Polly para criar áudio através de textos, o Translate para tradução em tempo real, o Lex que auxilia na criação de chatbots e o SageMaker que simplesmente faz deploy, compila e treina seu próprio machine learning! Data: temos duas famílias quando se trata de data no Amazon, sendo uma que cuida de transferência de dados e a outra de parte analítica dos dados. Para transferência de dados, o AWS oferece serviço para transporte físico de seus dados como Snowcone, Snowball e Snowmobile ou o DataSync, que ajuda na migração dos dados on-premises ( local ) para a nuvem. Na família analítica temos serviços para análise de arquivos, ETL, leitura de dados de vídeos e áudio e visualização. Dentro desse pacote, temos o Data Consolidation, Athena, Glue, Kinesis e QuickSight. Outros serviços oferecidos Além dos serviços oferecidos, como citados anteriormente, o grande ecossistema também contempla ferramentas para administração, governança e gestão do seus recursos alocados no Amazon Web Service. O Amazon Security é um hub que contém soluções para gestão individual de usuários (IAM), Web Firewall para aplicações, AWS Shield para proteger sua aplicação contra ataques de DDOS. Você também pode usar a ferramenta Macie para analisar dados armazenados em seu S3 para vasculhar dados pessoais e protegê-los conforme as leis locais exigem. Em Artifact você encontra em um único lugar uma central de reportes de compliances, SOC Report e PCI, que são importantes para auditorias em caso de eventual necessidade. Para gestão de custos temos diversas ferramentas para auxiliar a gerir todo esse ecossistema de soluções: temos o Budget Alert que é muito útil para alertar em caso de exceder o custo OpEx (Custo operacional de sua infraestrutura) que você planejou. Com o Cost Budget e Usage Budget, você planeja o quanto você quer realmente gastar com sua infraestrutura. Por último, e não menos importante, temos os planos de suporte para solução de problemas para o Amazon Web Services. Seus valores dependem do tamanho da operação que sua empresa realiza. Como veremos na tabela abaixo, a partir de 29 dólares por mês, qualquer desenvolvedor tem direito à abertura de ticket através de email durante o horário comercial da empresa ou com 15 mil dólares por mês, você pode ter um Technical Account Manager responsável por te atender a qualquer momento! Acelere a sua carreira conosco! A Mentoria DevOps é um programa de mentoria de 12 meses com encontros semanais ao vivo, com um grupo seleto e restrito, onde estaremos do seu lado para mantê-lo relevante e atualizado no mercado de tecnologia, aprendendo e implementando as melhores práticas e ferramentas de DevOps. Clique aqui para entrar na prioridade pela melhor oferta de lançamento Como posso começar a praticar o uso das ferramentas AWS? Como parte do seu programa de expansão da ferramenta, o Amazon Web Services disponibiliza para você um voucher grátis de uso por 12 meses, permitindo que você possa efetuar testes e conhecer seus produtos. Para conhecer as condições e o limite disponibilizado por conta basta acessar o link https://aws.amazon.com/pt/free/ e criar sua conta. Outro recurso que permite um bom uso das ferramentas disponíveis da AWS é a sua trilha oficial de treinamento. Hoje temos como referência a SkillBuilder https://explore.skillbuilder.aws/learn e CloudQuest https://aws.amazon.com/pt/training/digital/aws-cloud-quest/, em que você aprende a explorar o mundo AWS através de um RPG. E para mais informações sobre trilhas de treinamentos específicas, você também pode explorar o link https://aws.amazon.com/pt/training/ . Esperamos que vocês tenham gostado dessa introdução ao mundo AWS, aguardamos você nos próximos artigos. Até a próxima!
Docker Avançado: Cache, segurança e boas práticas para versionamento
O Docker transformou a maneira como desenvolvedores e equipes de infraestrutura gerenciam aplicações, permitindo uma entrega contínua e ambientes de desenvolvimento replicáveis. No entanto, conforme as aplicações e sistemas crescem em complexidade, é essencial que o uso do Docker vá além das práticas básicas. Este artigo se aprofunda em três áreas fundamentais para quem deseja dominar Docker em um nível avançado: cache de containers, segurança e melhores práticas para o armazenamento de imagens. Cada uma dessas áreas pode impactar diretamente a eficiência, o desempenho e a segurança do seu ambiente de produção. Cache de containers O cache de containers é uma das funcionalidades mais poderosas do Docker para otimização de builds. O Docker armazena camadas de imagens (layers) que podem ser reutilizadas em builds futuras, economizando tempo e processamento. Como o cache funciona? Cada comando no Dockerfile cria uma camada, e se o Docker detectar que uma camada já foi construída anteriormente e não sofreu mudanças, ele reutiliza essa camada em vez de reconstruí-la. Vamos ver um exemplo prático: FROM python:3.9 RUN apt-get update && apt-get install -y build-essential libssl-dev COPY requirements.txt /app/ RUN pip install -r /app/requirements.txt COPY . /app/ CMD [“python”, “/app/main.py”] Neste Dockerfile, o Docker verifica se o conteúdo do requirements.txt foi alterado antes de executar o comando RUN pip install. Se nada mudar, o Docker reutiliza a camada de cache, economizando tempo. Assim, o processo de instalação de pacotes Python não é refeito em cada build, desde que as dependências não tenham sido modificadas. Melhoria no uso de cache É importante otimizar o Dockerfile para maximizar o uso de cache. Um truque comum é separar a cópia de arquivos estáveis (como o requirements.txt) das instruções de cópia do código-fonte. Veja como: FROM python:3.9 RUN apt-get update && apt-get install -y build-essential libssl-dev COPY requirements.txt /app/ RUN pip install -r /app/requirements.txt COPY . /app/ CMD [“python”, “/app/main.py”] Neste exemplo, a cópia do requirements.txt e a instalação dos pacotes ocorrem antes da cópia do código-fonte, permitindo que as dependências permaneçam no cache, a menos que sejam alteradas. Isso é especialmente útil em projetos onde o código muda com mais frequência do que as dependências. Segurança A segurança em containers é crítica para garantir a integridade e a confidencialidade das aplicações. Existem várias boas práticas de segurança que podem ser adotadas em ambientes Docker. Uso de imagens leves Uma das melhores práticas de segurança é minimizar o tamanho das imagens. Quanto menor a imagem, menor a superfície de ataque. Imagens como a alpine, que é uma versão minimalista de distribuições Linux, são amplamente utilizadas em ambientes de produção. FROM python:3.9-alpine RUN apk update && apk add –no-cache gcc musl-dev libffi-dev COPY requirements.txt /app/ RUN pip install –no-cache-dir -r /app/requirements.txt COPY . /app/ CMD [“python”, “/app/main.py”] Ao usar alpine, a imagem final será significativamente menor e mais segura, pois contém apenas os pacotes necessários para a aplicação. Execução com usuários não root Executar containers com o usuário root é uma prática perigosa, pois, se o container for comprometido, um atacante pode ter acesso irrestrito ao sistema host. Para mitigar esse risco, crie e utilize um usuário não privilegiado: FROM python:3.9-alpine RUN addgroup -S appgroup && adduser -S appuser -G appgroup WORKDIR /app COPY . /app RUN chown -R appuser:appgroup /app USER appuser CMD [“python”, “/app/main.py”] Com esse Dockerfile, o container será executado com permissões reduzidas, dificultando possíveis ataques. Scanners de vulnerabilidades Ferramentas como Trivy podem ser usadas para identificar vulnerabilidades em imagens Docker. Elas analisam pacotes de sistema e bibliotecas de aplicações em busca de problemas de segurança. Instale o Trivy e faça um scan simples da sua imagem: trivy image python:3.9-alpine A saída mostrará possíveis vulnerabilidades, permitindo que você tome ações corretivas, como a atualização de pacotes ou a adoção de versões mais seguras. Storage de imagens O armazenamento eficiente de imagens Docker é essencial para ambientes que utilizam múltiplos containers. Sem uma gestão adequada, o espaço em disco pode ser rapidamente consumido por imagens e containers não utilizados. Limpeza de imagens e containers antigos Com o tempo, imagens antigas, containers parados e volumes não utilizados ocupam espaço desnecessário. É possível fazer uma limpeza manual usando o comando docker system prune: docker system prune -a –volumes Este comando remove containers parados, imagens órfãs e volumes não utilizados, liberando espaço. Use a flag -a para remover também imagens antigas e não referenciadas. Armazenamento em registros privados Para projetos maiores, é importante armazenar as imagens em um repositório centralizado, como o Docker Hub ou registros privados como o Amazon ECR ou Google Container Registry. O uso de registros privados permite compartilhar imagens de forma segura entre diferentes ambientes e equipes. Além disso, eles oferecem integração com sistemas de autenticação, como IAM (Identity Access Management), garantindo que apenas usuários autorizados possam acessar as imagens. Versionamento adequado Outra prática importante é o versionamento de imagens. Nunca utilize a tag latest em ambientes de produção, pois ela pode levar à incerteza sobre a versão da imagem que está sendo executada. Em vez disso, utilize um sistema de versionamento claro: docker build -t minha-imagem:1.0.0 . docker push minha-imagem:1.0.0 Esse tipo de controle facilita o gerenciamento de versões e garante que diferentes ambientes (desenvolvimento, teste e produção) utilizem exatamente a mesma imagem. Compressão de imagens Se o espaço for uma preocupação constante, considere o uso de ferramentas como o docker-slim para reduzir o tamanho das imagens. O docker-slim remove partes desnecessárias das imagens, deixando-as mais leves e rápidas para transferir: docker-slim build –http-probe minha-imagem:1.0.0 Isso pode reduzir significativamente o tempo de deploy e a utilização de largura de banda, especialmente em ambientes de CI/CD. Acelere a sua carreira conosco! A Mentoria DevOps é um programa de mentoria de 12 meses com encontros semanais ao vivo, com um grupo seleto e restrito, onde estaremos do seu lado para mantê-lo relevante e atualizado no mercado de tecnologia, aprendendo e implementando as melhores práticas e ferramentas de DevOps. Clique aqui para entrar na prioridade pela melhor oferta de lançamento Conclusão Ao adotar práticas avançadas no uso do Docker,
Google Cloud: Um guia rápido de introdução à plataforma
No cenário atual, a computação em nuvem tornou-se um elemento crucial para empresas que buscam inovação e escalabilidade. Entre as plataformas de nuvem mais proeminentes está o Google Cloud Platform (GCP), conhecido por sua robustez, segurança e facilidade de uso. Este guia oferece uma introdução aos fundamentos do GCP, apresentando seus principais serviços e mostrando como você pode começar a utilizar a plataforma de forma eficiente O que é o Google Cloud Platform? O Google Cloud Platform (GCP) é um conjunto de serviços de computação em nuvem oferecido pelo Google. Ele oferece soluções que vão desde o armazenamento e processamento de dados até o desenvolvimento e a implantação de aplicações. Um dos grandes diferenciais do GCP é que ele oferece a mesma infraestrutura global que suporta serviços como Google Search e YouTube, garantindo alta disponibilidade e desempenho. Componentes essenciais do GCP Para iniciar sua jornada no GCP, é fundamental entender os principais serviços que compõem a plataforma. Abaixo estão os serviços mais utilizados: Compute Engine Serviço que oferece máquinas virtuais (VMs) na nuvem. Com o Compute Engine, você pode executar workloads complexos, hospedar websites e aplicativos, e até mesmo migrar servidores locais para a nuvem. A flexibilidade na escolha do sistema operacional e configuração da VM faz do Compute Engine uma ferramenta poderosa para diversas necessidades. Documentação recomendada Visão geral do Compute Engine Guia de início rápido para criar uma VM Cloud Storage Ua solução escalável de armazenamento de objetos, ideal para armazenar dados não estruturados, como arquivos de mídia, backups e grandes datasets. O Cloud Storage oferece durabilidade e segurança, além de permitir a integração com outros serviços do GCP, facilitando o gerenciamento e o acesso aos dados. Documentação recomendada Introdução ao Cloud Storage Guia de melhores práticas para Cloud Storage App Engine Uma plataforma como serviço (PaaS) que permite a criação e implantação de aplicações web sem a necessidade de gerenciar a infraestrutura. O App Engine cuida do balanceamento de carga, auto escalonamento e integração com outros serviços do GCP, permitindo que os desenvolvedores se concentrem exclusivamente no código. Documentação recomendada Visão geral do App Engine Guia para criar seu primeiro aplicativo no App Engine Cloud SQL Serviço de banco de dados gerenciado que suporta MySQL, PostgreSQL e SQL Server. Com o Cloud SQL, você pode configurar, manter e escalar seus bancos de dados com facilidade, aproveitando a segurança integrada do GCP e a alta disponibilidade. É uma excelente opção para quem deseja focar no desenvolvimento de aplicações sem se preocupar com a administração de bancos de dados. Documentação recomendada Introdução ao Cloud SQL Guia de início rápido com MySQL no Cloud SQL Firestore Um banco de dados NoSQL flexível e escalável que facilita o desenvolvimento de aplicações móveis e web. O Firestore oferece sincronização em tempo real, suporte offline e integração nativa com o Firebase, o que o torna uma escolha poderosa para aplicações que requerem baixa latência e alta disponibilidade. Documentação recomendada Introdução ao Firestore Começando com Firestore Como começar? Tudo pode parecer desafiador à primeira vista, mas com a orientação correta e os recursos oficiais, você pode rapidamente se familiarizar com a plataforma e começar a explorar seus serviços. Abaixo listamos as etapas essenciais para começar a utilizar o GCP de maneira eficiente e segura. Criando uma conta no Google Cloud O primeiro passo para começar no GCP é criar uma conta. Para isso: Acesse a página inicial do Google Cloud: visite cloud.google.com e clique em “Comece gratuitamente”. Inscrição: preencha as informações necessárias, como detalhes de contato e métodos de pagamento. Mesmo que seja solicitado um cartão de crédito, você não será cobrado automaticamente após o uso do crédito gratuito. Créditos gratuitos: o Google oferece $300 em créditos gratuitos que podem ser usados em qualquer serviço do GCP nos primeiros 90 dias. Isso permite que você explore a plataforma sem custos iniciais significativos. Mais uma vez vamos direcionar você à documentação oficial sobre como criar uma conta no Google Cloud, caso você ainda fique com alguma dúvida. Configurando o ambiente Inicial Após criar sua conta, é essencial configurar seu ambiente de trabalho para garantir que você possa gerenciar seus recursos de maneira eficiente e segura. Criação de Projetos: no GCP, todos os recursos estão organizados em projetos. Um projeto é uma entidade que permite organizar e gerenciar todos os seus recursos, como VMs, bancos de dados e APIs. Ao criar um projeto, você também define o escopo de faturamento e as permissões de acesso. Configuração de Faturamento: vincule uma conta de faturamento ao seu projeto para rastrear e gerenciar os custos. É importante configurar alertas de orçamento para evitar gastos inesperados. No Console do GCP, vá até a seção “Faturamento” e configure seu orçamento e alertas de gastos. Gerenciamento de Identidade e Acesso (IAM): configure as permissões de acesso ao seu projeto usando o IAM. Defina quem pode acessar e gerenciar os recursos dentro do seu projeto. Por exemplo, você pode conceder acesso apenas de leitura a certos usuários ou permitir que outros administrem totalmente os recursos. Explorando a Interface do Console: o Console do GCP é a interface gráfica que permite gerenciar todos os recursos e serviços da plataforma. Familiarizar-se com o Console é crucial para navegar pelos diferentes serviços e configurar os recursos de forma eficaz. Algumas documentações da google podem ser úteis nesse momento, entre elas: Guia para Gerenciamento de Projetos Guia para Gerenciamento de Projetos Configuração de alertas de orçamento no GCP Visão geral do IAM no GCP Introdução ao Cloud Shell Recursos educacionais oficiais O Google Cloud oferece uma ampla gama de recursos educacionais oficiais para ajudá-lo a dominar a plataforma e se preparar para as certificações, mas o destaque vai para a Google Cloud Skills Boost. Essa plataforma oficial de aprendizado online oferece uma vasta seleção de laboratórios práticos, cursos e trilhas de aprendizado. Cada curso é projetado para ensinar conceitos específicos do GCP, com a oportunidade de praticar em um ambiente real sem custos adicionais. Para quem desejar ir ainda mais fundo e validar seus conhecimentos,
Construindo sua primeira aplicação com Docker
Veja como Docker pode transformar seu ambiente de desenvolvimento, simplificando a criação e a execução de aplicações em qualquer lugar.
ASP.NET no Kubernetes: Como fazer deploy da sua aplicação localmente
Neste artigo guiaremos você através do processo de configuração, desenvolvimento e deploy de uma aplicação .NET simples usando Kubernetes localmente
Como usar variáveis/segredos no GitHub Actions
Neste artigo iremos explorar como na prática podemos guardar dados sensíveis como chaves, senhas ou connection strings para serem utilizadas em seu fluxo de CI/CD no GitHub.
Git Tag, Release e Versioning: Entendendo a rastreabilidade de software
Na gestão de software, versões de lançamento são cruciais para manter a rastreabilidade, garantir a qualidade e facilitar a colaboração entre as equipes. Para desenvolvedores que ainda não estão familiarizados com práticas de DevOps, termos como Git Tag, Release e Semantic Versioning podem parecer complexos. Este artigo tem como objetivo desmistificar esses conceitos e mostrar como eles se relacionam na prática. Todo exemplo usado neste artigo estará disponível neste projeto público aqui: https://github.com/toolbox-playground/terraform-exemplo-gcp Git Tag: marcos de código O conceito de tag no Git é fundamental para marcar pontos específicos no histórico de commits de um repositório, como se fosse uma ‘conquista’. Como boa prática, sempre devemos criar esses marcos a partir da branch mais estável e que represente o código em produção (normalmente usamos a branch main para isso). Uma tag no Git é essencialmente um rótulo fixo que você pode atribuir a um commit específico no seu repositório. Diferente dos branches, que continuam a evoluir conforme novos commits são adicionados, uma tag aponta para um commit específico e permanece imutável. Isso é particularmente útil para marcar releases de software, versões específicas ou conquistas importantes. Vamos imaginar que você esteja prestes a lançar uma nova versão estável do seu software. Após a conclusão do desenvolvimento e os testes finais, você decide criar uma tag para marcar esse momento no histórico do seu repositório Git. Isso pode ser feito da seguinte forma: git tag -a v1.4 -m “my version 1.4” git push –follow-tags origin main Release: Formalizando e publicando versões de software Numa fábrica de qualquer produto, toda matéria prima se torna um produto final, numa pipeline de softwares não é diferente. Uma Release é uma entrega formal de uma versão do software que foi preparada para distribuição. Geralmente, essa entrega está associada a uma tag e inclui: Versão do software: definida através do Semantic Versioning. Release Notes: um resumo das principais mudanças, melhorias, novos recursos e correções de bugs incluídos na versão. Essas notas são cruciais para informar ao público usuários e desenvolvedores sobre o que esperar da nova versão. Artefatos: em alguns casos, especialmente para projetos em linguagens compiladas, o release pode incluir binários ou outros arquivos necessários para a execução do software. Na prática, podemos considerar qualquer biblioteca disponível para download ou software como um exemplo real de um Release na prática. Abaixo, temos o exemplo da própria ferramenta Git. Cada Release gera um documento oficial, conforme abaixo, em que vemos uma das releases do Git: Semantic Versioning Semantic Versioning (SemVer) é uma convenção de versionamento para softwares que segue um padrão específico para nomear versões. Esse padrão é composto por três números separados por pontos: MAJOR.MINOR.PATCH. Cada um desses números tem um significado específico e uma regra de incremento baseada nas mudanças feitas no software. MAJOR: incrementado quando há mudanças incompatíveis na API (breaking changes); MINOR: incrementado quando funcionalidades são adicionadas de maneira compatível com versões anteriores; PATCH: incrementado quando correções de bugs são feitas de maneira compatível com versões anteriores. Por exemplo, a versão 2.1.3 pode indicar: 2: segunda versão maior do software, possivelmente com mudanças significativas e incompatíveis com a versão 1.x.x; 1: primeira atualização menor, adicionando funcionalidades novas, mas mantendo compatibilidade com a versão maior; 3: terceira correção de bugs desde a última atualização menor. Há várias formas de decidir o momento em que sua empresa ou time irão atualizar a versão do software e o fator maturidade do time pode contar muito no momento de desenhar essa lógica. Há situações em que o software efetua a troca de versão por “tipo de mensagem” no commit, como o padrão commit–zen apresenta. Há softwares que geram novas versões por tempo de projeto, como o SQL Server, que lançava sempre uma versão a cada dois anos: SQL Server 2012, SQL Server 2014, SQL Server 2016. Não há certo ou errado ao assumir qualquer estratégia e lembre-se sempre de adequar uma estratégia que faça sentido para o momento e a senioridade do seu time. Acelere a sua carreira conosco! A Mentoria DevOps é um programa de mentoria de 12 meses com encontros semanais ao vivo, com um grupo seleto e restrito, onde estaremos do seu lado para mantê-lo relevante e atualizado no mercado de tecnologia, aprendendo e implementando as melhores práticas e ferramentas de DevOps. Clique aqui para entrar na prioridade pela melhor oferta de lançamento Conclusão Todos esses conceitos, quando bem aplicados, garantem o que chamamos de rastreabilidade de software, permitindo que desenvolvedores, operadores e usuários finais saibam exatamente o que esperar de cada versão e até mesmo retornem para uma versão anterior se tiverem necessidade. A partir de agora, com base no conteúdo que vimos neste artigo, você pode adotar essas práticas em seus projetos ou mesmo fomentar seu uso no seu time e empresa.
Pipeline no Azure DevOps para uma aplicação ASP.NET Core
Neste artigo vamos te guiar passo a passo na configuração de um pipeline usando a estratégia de uso dos arquivos YAMLs dentro do Azure DevOps.
Melhores práticas para testes de software em pipelines
A qualidade de software é um fator crucial para o sucesso de qualquer aplicação. Em um ambiente de desenvolvimento ágil, em que mudanças são rápidas e frequentes, manter um alto padrão de qualidade pode ser desafiador. É aí que podemos utilizar estratégias do mundo DevOps para nos auxiliar. Este artigo vai explorar como garantir a qualidade do software durante o ciclo de CI/CD, destacando ferramentas e boas práticas que podem ser adotadas mesmo por quem é novo no assunto. Os mandamentos da pipeline Para um ciclo excelente de qualidade em sua esteira de software, podemos dividir em 3 grandes pilares que são: Testes de software Análise de segurança Versionamento de artefatos Neste artigo, focaremos no pilar de Testes de Software e para garantir que nossa abordagem funcione corretamente e produza resultados de alta qualidade, devemos considerar esses 3 pilares como inegociáveis e que uma vez implementado, toda a cadeia de pessoas responsável pelo software como produto final deverá entender seus benefícios e trabalhar em prol dos resultados. Lembre-se sempre: não há ferramenta ou processo que faça milagre em um ambiente em que se negocie qualidade. Os testes de um software Dentro de um processo de CI/CD, podemos executar vários tipos de testes. Cada um desses tipos teste tem uma finalidade e por esse motivo eles podem e devem ser alocados em momentos estratégicos durante uma pipeline. 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-los 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. Testes de regressão Os testes que têm 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. 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. Benefícios Durante o processo de implementação das práticas descritas, podemos esbarrar em uma variável muito importante: o tempo total de execução de uma pipeline. Quanto mais atividades e processos colocamos em uma pipeline, ela tende a aumentar exponencialmente o seu tempo de execução, exigindo muito provavelmente uma maior capacidade computacional ou quantidade maior de servidores disponíveis para sua execução. Para resolver esse problema, a ideia que apresentamos é que cada teste pode ser executado em diferentes momentos em uma pipeline e evitados em outros, exatamente para evitar o consumo total das máquinas e tornar o processo muito mais eficiente e produtivo. Desde que o processo de pipeline execute todos os testes, não há problema em separarmos o momento de execução de cada uma das partes do processo para melhorar sua eficiência. Grande parte dos serviços de pipelines no mercado nos possibilitam tirar uma grande vantagem no processo de execução de testes através de condicionais e análise dos resultados de testes. Podemos até abortar um processo de deployment se eventualmente algum dos testes não se comportar da forma que esperávamos ou se os resultados extraídos dos testes não atingiram o mínimo solicitado. O uso de ferramentas como o Sonar durante as pipelines nos possibilitam usar seu Quality Gate para analisar a qualidade dos testes e do código, evitando assim de prosseguir com qualquer mudança que não atingir a qualidade exigida. Acelere a sua carreira conosco! A Mentoria DevOps é um programa de mentoria de 12 meses com encontros semanais ao vivo, com um grupo seleto e restrito, onde estaremos do seu lado para mantê-lo relevante e atualizado no
CI/CD com Bitbucket: primeiros passos
O Bitbucket Pipelines é uma ferramenta poderosa que permite a automação de builds, testes e implantações diretamente do Bitbucket. Para um profissional de DevOps, compreender e utilizar essa ferramenta pode otimizar significativamente o fluxo de trabalho e garantir maior eficiência nas entregas de software. Neste artigo vamos explorar os primeiros passos para configurar e utilizar o Bitbucket Pipelines. Introdução ao Bitbucket Pipelines Um dos pontos positivos do Bitbucket é que ele faz parte do ecossistema de soluções da Atlassian, que também é proprietária de ferramentas como Zendesk, Jira, Trello e Confluence. Se você ainda não conhece essas ferramentas, um dia muito provavelmente irá conhecer pelo seu potencial ou pela sua popularidade na indústria de desenvolvimento de software. O ponto positivo é a facilidade de integração entre as ferramentas e todo suporte ao ecossistema que você tem, deixando tudo centralizado e fácil para administrar. Assim como seus concorrentes, o Bitbucket Pipelines é uma ferramenta focada em CI/CD, possibilitando automação de processos, compilação, testes de código e deploys. Estrutura do Bitbucket Pipelines Dentro do Bitbucket, temos a tradicional hierarquia de Organizações, Projetos e Repositórios. Dentro de cada repositório, você pode criar uma pipeline de execução. Dentro do repositório, os pré requisitos que você tem que ter para executar esse passo a passo são: ter um código versionado; ter permissões suficientes para alterar as configurações básicas do repositório. Em configurações, habilite o repositório para executar a pipeline. A própria ferramenta irá sugerir um template para facilitar a sua vida. Nesse momento, podemos ignorar e aceitar a sugestão da ferramenta apenas para criar nosso exemplo. Esse arquivo é padrão e obrigatório para criarmos pipelines no Bitbucket, ou seja, ele sempre precisará estar na raiz do projeto e se chamar bitbucket-pipelines.yml. Pipeline na prática Para fins didáticos, utilizaremos um exemplo de “Hello world” em Node.js que está disponível aqui. Neste exemplo básico, definiremos apenas a instalação dos pacotes do Node.js. Abaixo temos o conteúdo do arquivo bitbucket-pipelines.yml, que define a estrutura da pipeline. image: node:lts-alpine3.19 pipelines: default: – step: name: Build and Test caches: – node script: – npm install Vamos analisar cada linha do código do arquivo bitbucket-pipelines.yml fornecido e entender o que ela faz: image: define a imagem do Docker a ser usada para executar o passo. Neste caso, a imagem “node:lts-alpine3.19” será usada, que contém o Node.js instalado. pipelines: define a seção “pipelines” do arquivo YAML. As pipelines são usadas para definir os passos ou estágios de um processo de integração contínua. default: define a seção “default” dentro da seção “pipelines”. A seção “default” é usada para definir os passos padrão que serão executados quando nenhum outro estágio específico for especificado. – step: define um passo dentro da seção “default”. Um passo é uma tarefa específica que será executada durante o processo de integração contínua. name: Build and Test: define o nome do passo como “Build and Test”. É uma descrição opcional que ajuda a identificar o objetivo do passo. caches: define a seção “caches” dentro do passo. Os caches são usados para armazenar dados em cache entre as execuções dos passos, a fim de melhorar o desempenho. – node: define um cache chamado “node”. Neste caso, o cache “node” será usado para armazenar as dependências do Node.js, a fim de evitar a necessidade de instalá-las novamente a cada execução. script: define a seção “script” dentro do passo. A seção “script” contém os comandos que serão executados durante o passo. Aqui é onde você preenche todos os passos que sua aplicação deverá seguir, seja instalação de pacotes, execução de testes e etc. Cada comando pode ser representado separadamente assim: script: – npm install – npm test – npm x Variáveis e Segredos Podemos utilizar o recurso de variáveis e segredos no Bitbucket para armazenar informações sensíveis, parâmetros de configuração que variam entre ambientes e etc. Dentro de configurações de repositório, em Pipelines, encontramos a opção para criar variáveis. Para utilizar as variáveis dentro do arquivo YAML, basta referenciar o nome da variável criada, precedido de $, por exemplo: script: – npm install – npm test – echo $Teste Scripts Uma outra funcionalidade muito importante é a capacidade de executar scripts dentro da pipeline. Desde que o arquivo exista dentro do repositório em que você irá criar a pipeline, você também consegue criar scripts bash para serem executados dentro dela: script: – ./deploy.sh Triggers: decidindo quando uma pipeline será executada No contexto de DevOps e integração contínua (CI), as triggers de pipeline são mecanismos essenciais para automatizar e controlar a execução dos pipelines com base em eventos específicos. No Bitbucket Pipelines, as triggers definem quando e como um pipeline deve ser iniciado, oferecendo flexibilidade e controle para diferentes fluxos de trabalho. Para o Bitbucket, temos alguns tipos de trigger e iremos explorá-las para entender melhor como configurar a execução de sua pipeline. Triggers de Branches Nessa configuração, você poderá executar diferentes scripts para branchs distintas. Para a branch Master, a pipeline irá executar a mensagem: “Pipeline para a branch master” e para a Develop “Pipeline para a branch develop”. Esse tipo de estratégia é excelente quando você precisa economizar tempo de pipelines, executando apenas trechos ou eliminando a necessidade de executar o mesmo script sempre: pipelines: branches: master: – step: script: – echo “Pipeline para o branch master” develop: – step: script: – echo “Pipeline para o branch develop” Triggers de Pull Requests Executam pipelines quando um pull request é criado ou atualizado. Isso é útil para garantir que as alterações propostas não introduzem erros. pipelines: pull-requests: ‘**’: – step: script: – echo “aqui só vai executar no momento do Pull Request” Triggers Agendadas ou CRON Permitem executar pipelines em horários específicos, independentemente de commits ou pull requests. Isso é útil para tarefas de manutenção, backups ou testes periódicos. Esse tipo de operação é muito utilizado para fazer check-ups durante a madrugada ou fora do horário comercial, fazendo com que você desafogue a maior parte das execuções excessivas ou que demore muito para um horário menos concorrido de execução. Para isso, basta