DEV Community: Lázaro Vinícius de Oliveira Bonifácio

Semelhança entre DevOps e bactérias comedoras de resíduos industriais oleosos

Lázaro Vinícius de Oliveira Bonifácio — Tue, 07 Nov 2023 01:18:06 +0000

Esses dias eu participei do maior evento de inovação, empreendedorismo e tecnologia do Rio Grande do Norte: o GO!RN 2023. Essa experiência foi muito útil para mim em diversos aspectos profissionais e pessoais, mas o que chamou minha atenção foi o fato apresentado no título do post.

Certamente, não uma relação direta entre ambas as coisas, mas ainda assim elas são semelhantes. A analogia faz mais sentido na minha cabeça do que na sua agora, mas é apenas um certo aspecto que eu gostaria de frisar aqui.

Contexto situacional

Eu tinha acabado de chegar no evento e a primeira palestra que eu participei acabou com 30 minutos de antecedência para a próxima. Então eu aproveitei para ir até o estande da próxima palestra que me interessou. Chegando lá eu me vi no momento de pitch da segunda colocada do AES startups. Porém foi o do primeiro colocado que chamou a minha atenção.

Se tratava de uma empresa que produzia bactéria para tratar tanques de resíduos oleosos. Tais resíduos precisam de um transporte e tratamento muito caros. Desta forma, a ideia deles é tratar esses resíduos de forma mais barata e ecológica. Eles desenvolveram uma bactéria capaz de se alimentar desse lixo muito rapidamente.

O estalo inicial

Neste momento, eu me peguei a pensar: Nossa! As pessoas ganham dinheiro com tanta coisa diferente, e eu, aqui, só pensando em sair de operações para ir para a área de desenvolvimento. Essa situação abriu os meus olhos para perceber que não existe apenas tecnologia do mundo digital, mas de como diferentes áreas de conhecimento são relevantes, são capazes de deixar um legado, e podem ser inovadoras também.

Tenho muito admiração pelas demais áreas do conhecimento, mas nenhuma me fascina mais do que a engenharia que envolve o mundo digital, a programação, a eletrônica, e tudo que possui um circuito elétrico. É nessa área que quero trabalhar e fazer minha carreira, mas o meu contexto atual não me é muito favorável à aquilo que eu tinha idealizado.

Contexto pessoal

Há umas semanas eu me vi em um dilema profissional: será que é realmente que eu quero para a minha vida? Confesso que ele me ocorre com mais frequência do que o desejado (algum tipo de impaciência).

De fato, hoje eu trabalho na área de engenharia de cloud, que eu me identifico bastante. Mas de uns 2 anos para cá, eu tenho deseja me tornar um engenheiro DevOps, e atualmente eu estou bem próximo disso. O que tem me incomodado é o fato de que, sabendo o que eu sei sobre DevOps hoje e tudo o que ele promete, parece inadmissível que trabalhar de outra forma que não seja esta.

Parece tolice deixar que alterações sejam feitas em ambientes de testes e produção, e que isso não seja codificado ou documentado. Da mesma, me parece sem razão fazer processo manuais sem se questionar se eles não podiam ser automatizados. Mas como seguir agindo dessa forma, sem se cansar, quando você é um dos poucos que pensa numa perspectiva DevOps.

Além disso, onde mais pode-se praticar DevOps se não no desenvolvimento Web? Foi nesse momento que eu percebi que essa cultura possui um nicho, um propósito e situação específica, e poucos vão precisar disso a longo prazo.

DevOps é nichado

Eu fico me perguntando: faz sentido que uma empresa com apenas um time de desenvolvimento, com seus próprios servidores empoeirados, cujo o negócio não é TI, ter um engenheiro DevOps? Ou pior, é relevante que eles saibam o que é isso? Não e sim, respectivamente.

Se o time de desenvolvimento e o ambiente é pequeno, mais vale um desenvolvedor do que um engenheiro DevOps. Em todas as situações onde eu vi uma posição para DevOps foram em médias para grandes empresas, cujo o negócio é TI e que tinham que manter uma plataforma Web. E não é que falte espaço no mercado, mas que o desenvolvimento de software é si é menos nichado do que isso.

Mesmo sem implementar o cargo de DevOps, eu acredito ser vital que qualquer empresa cultive a cultura dentro de casa. Porque essa perspectiva vai garantir soluções mais longínquas, eficientes e manuteníveis. Além disso, um pipeline de CI/CD é útil para qualquer nível de maturidade de projeto. E versionar infraestrutura também entra nesse conjunto.

Dificuldades do mercado Júnior

Outro ponto que me desmotiva é a dificuldade para iniciar na área de baixo. São pouquíssimas as vagas para juniores e raríssimos os estágios. As vagas presentes são altamente concorridas, juntamente pelo nicho e a própria ideia do DevOps.

O próprio roadmap DevOps é muito diversificado entre áreas de operações e desenvolvimento. Eu entendo que um bom DevOps deve entender bem da operação em seus processos e ideologias, mas também de programação em sua essência e agilidade. Desta forma, ter ambas as experiências em sua bagagem é tentadoramente vantajoso.

Com isso em vista, noto que as vagas mais abundantes são pra plenos e seniores. Não é difícil encontrar vagas de DevOps para que já tem pelo menos 5 anos de carreira. Enquanto isso, apesar de a diminuição, as vagas para desenvolvedores juniores são mais frequentes.

Conclusão

O cenário atual não é muito favorável para o juniores no geral, mas se você quiser ter maiores chances de conseguir um emprego, é melhor procurar posições de desenvolvimento ou de operações; e então, subir a escada corporativa rumo ao cargo de DevOps. É isto que estou fazendo hoje.

Acredito que o caminho seja fazer aquilo que os primeiros engenheiros DevOps fizeram (Os devopeiros ancestrais kk): fazer um nome com experiências sólidas em áreas relacionadas com DevOps, como programador ou sysadmin, e depois migrar para a área como pleno. Ainda assim, é difícil encontrar vagas com descrições que não peçam uma experiência mais ampla em ambos os cargos.

Esperança

Ela existe, e está no fim do túnel de pelo menos cinco anos de experiência. Enquanto isso, é currículo atualizado, portfólio, estudo e trabalho!

Até a próxima!

DevOps Deep Dive (parte 1): O que é a cultura DevOps

Lázaro Vinícius de Oliveira Bonifácio — Sat, 04 Nov 2023 16:39:24 +0000

README

Esse artigo é uma adaptação de uma palestra, oriunda do conjunto de duas palestras chamada "DevOps Deep Dive". Por esse motivo, o texto pode parecer um pouco subjetivo, mas na verdade ele deixa o espaço para que você reflita e faça suas contribuições no momento em que for apresentá-lo, colocando um pouco das suas experiências e perspectivas em cada tópico.

São duas apresentações que tratam sobre os conceitos e pilares da cultura de DevOps e como ela acontece no dia-a-dia. São as apresentações:

1. O que é a cultura DevOps (este artigo);
2. DevOps na prática.

Apresentação: O que é a cultura DevOps

Definição

O termo DevOps já tem mais de dez anos. Ele foi utilizada pela primeira vez em uma palestra sobre desempenho Web e operações (na Velocity da O'Reilly) ao se demonstrar como era possível entregar valor 10 vezes ao dia para os clientes sem que esse processo fosse instável e burocrático. Há mais de 10 anos, e acredito que até hoje, há um conflito de interesses entre essas duas áreas em algum nível. Por um lado, temos um time muito mais próximo do processo de tomada de decisão, dando forma às necessidades do negócio; enquanto do outro há um time mais voltado para a manutenção e o suporte da plataforma onde o negócio funciona.

Preciso abrir um parenteses para dizer que ambos os times são igualmente importantes para o funcionamento do negócio e que um depende do outro para sobreviver, como veremos mais adiante. Mas pelo fato de que ambos tem papéis e estão em pontos diferentes da esteira de entrega de valor, o time de desenvolvimento tem um papel bem mais influente. Se pararmos para pensar um pouco, veremos que o processo de entrega de valor acontece majoritariamente desta forma: a estratégia da empresa define as prioridades (C-level), o time de produtos verifica as prioridades e o que precisa ser feito, o time de desenvolvimento faz o que precisa ser feito (o valor é gerado aqui), o time de testes valida e o time de operações se encarrega de refletir o valor para o ambiente produtivo e garantir que o valor está sendo entregue. Verifica-se que o time de desenvolvimento diz o que é tecnicamente viável enquanto o time de operações apenas aplica o que foi feito.

Desta forma, fica claro que o maior do desejo do time de desenvolvimento é ver suas funcionalidades refletidas o mais rápido possível no ambiente, enquanto o do time de operações é ver o ambiente estável. Porém, as novas mudanças podem trazer instabilidade e, por isso, o processo de transição pode ser demorado.

Esse tipo de pensamento tradicional torna o relacionamento entre os dois setores um pouco tempestuoso. Se quisermos mudar essa realidade, precisamos fazer com que ambos se entendam. Ou seja, precisamos que a operação pense um pouco mais como desenvolvimento e vice-versa. Assim como no universo do desenvolvimento, todas as metodologias atuais apontam para as mudanças rápidas, a uma boa dinâmica de codificação, testes e lançamento do software; o time de operações também precisa se adequar a essa mentalidade.

Vivemos em um mundo em que a mudança é constante e o alinhamento com as necessidades do mercado, e principalmente dos clientes, é vital para o máximo ganho e o menor prejuízo. Cem porcento de todas as pessoas de um empresa sabem como certos contextos estão no limiar entre uma grande oportunidade e um abismo de prejuízo. Porém, se quisermos continuar relevantes, precisamos estar sempre alinhados com o que os nossos clientes precisam. Só assim as empresas sobrevivem.

Como eu faço para que o time de operações se alinhe com as necessidades do seu cliente "a empresa"? Pegando algumas metodologias ágeis (que fizeram isso muito bem) e olhando para as melhores práticas de operação a partir dessas lentes. Em suma: cultura e ferramentas.

Pilares

O nível estratégico sabe melhor do que todos que para alcançar os objetivo de uma empresa/projeto precisamos que todos os elementos dela apontem em direção ao alvo. Se queremos implantar a cultura DevOps de maneira assertiva, precisamos que os processos, investimentos e decisões se baseiem nos seguintes elementos norteadores:

Cultura de colaboração e bom relacionamento entre times;
Automação para eliminar o máximo de trabalho repetitivo e manual (automatizar é a arte de fazer em seis horas algo que levaria seis minutos mas que depois disso não vai mais precisar ser feito em seis e sim em um minuto);
Medição é a base do processo de melhoria contínua, se não aferirmos o que fazemos, ficamos às cegas durante as tomadas de decisão.
Compartilhamento e experimentação. Ou seja, incentivo a inovação e ao aprendizado. Errar faz parte do processo de aprender qualquer coisa.

Em termos práticos, esses pilares afetam diretamente o relacionamento entre times de desenvolvimento e operações. Mas se pensarmos na cultura de uma empresa como um todo, podemos ver que esses pilares facilmente se encaixam em quase toda empresa. Com efeito, sabemos que a colaboração e o bom relacionamento são cruciais para termos um ambiente de trabalho sadio e produtivo. Já a automação é a chave para desburocratização e aumenta não só o valor da empresa, que terá processos mais eficientes, mas também o valor do funcionário, que terá desafios mais complexos e menos repetitivos. Além disso, é inegável que a medição e o processo de melhoria contínua são indissociáveis. Pois se não é possível medir, é impossível de se melhorar; e não sabemos melhorar o que não se mede. Por fim, o compartilhamento e a experimentação fazem parte da industria 4.0. Compartilhamos informações, experiências, erros e acertos; damos oportunidade a novos conceitos e métodos e não esquecemos de fazer isso seguindo os passos anteriores: colaboração, automatização, medição, compartilhamento.

Vantagens

Quanto temos uma boa implementação do DevOps, conseguimos ver claramente o nosso progresso pela aferição de alguns objetivos. São eles:

Melhorar a frequência de implantações: isso significa implantar quanto for necessário por mês, semana ou dia;
Automatizar processos: ferramentas em prol da redução de trabalhos repetitivos;
Diminuir a ocorrência de erros em novas versões: integração e testes contínuos;
Encurtar períodos de tempo para mudanças e melhorias: alinhamento com a cultura ágil (não é para tanto que hoje a cultura DevOps está debaixo do guarda-chuva ágil);
Recuperação rápida em casos de falhas no ambiente: boas práticas de operações;
Padronização nos processos de configuração e servidores: alinhamento com governança, automações e agilidade.

Se observarmos com atenção, veremos que todos os níveis da organização gozam dos benefícios de uma implantação da Cultura DevOps. Visto que, para a operação, isso significa entregar exatamente o que o negócio precisa com estabilidade; para o time de desenvolvimento o mais importante é a agilidade na entrega das suas soluções; para o gestor do produto é a garantia da entrega de valor; e para o time estratégico é escalabilidade, eficiência, cliente satisfeito, competitividade e relevância.

Ciclo de Desenvolvimento

O que muda na forma como entregamos valor quando seguimos a esteira DevOps de desenvolvimento? Você pode pensar: "Lá no meu setor nós meio que já fazemos essas coisas" ou "Isso não parece estar tão distante da minha realidade", o que já é excelente. Mas se desejamos usufruir de todas as vantagens no nosso processo de entrega de valor, precisamos que todo os envolvidos estejam alinhados com as melhores práticas da cultura DevOps.

Vale ressaltar de ante-mão que estamos falando de um ciclo contínuo, bem definido, ainda assim flexível, escalável e independente. Ou seja, quando pensamos em todos os elementos na imagem acima, devemos entender que todas essas etapas acontecem de forma independente em diferentes setores. Dando um exemplo prático: enquanto um está codificando uma nova funcionalidade, outro está esperando os testes do código finalizarem; entregáveis estão sendo transicionados de ambientes de teste para produção automaticamente; enquanto isso os dados de desempenho da última entrega já estão sendo gerados, e os problemas críticos já estão sendo triados para que ações rápidas sejam tomadas; ao mesmo tempo outras melhorias estão sendo planejadas, fundamentadas em dados concretos e nas necessidades do negócio.

Há ainda um tópico que eu gostaria de mencionar, que é a abertura para falhas. Entendo que em certos contextos é difícil manter essa proposta, mas acredito que ela é capaz de fazer seu projeto progredir com segurança. Quando não absorvemos esse tipo de cultura para a nossa organização, ou ciclo de desenvolvimento, estamos limitando o aprendizado, aumentando a insatisfação das equipes, aumentando os níveis de estresse por medo de errar, diminuímos a qualidade do software, aumentamos a resistência a mudanças e favorecemos a ocultação de problemas. Porém, não podemos ser desleixados. Existe uma frase do Eric Ries, autor do livro "The Lean Startup", que diz: "você precisa errar fácil, erra rápido e errar barato".

Então, como lidamos com essa cultura no dia-a-dia: colocando cada uma das etapas em cima dos pilares. É difícil falar de uma sem mencionar a outra.

O planejamento é posterior ao monitoramento e anterior à codificação. Isso implica dizer que os processos que tangem ao planejamento terão influência dos nossos resultados anteriores, isto é, feedback. Com efeito, paramos de apenas receber os pedidos de desejo de modificações e novas funcionalidades, e passamos a nos aprimorar por nós mesmos. Esse tipo de prática é a base da melhoria contínua. O que significa ocupar em torno de 20% do esforço para a reduzir débitos técnicos e corrigir bugs. Se ocuparmos 20% do nosso esforço na sprint para essas atividades, dificilmente precisaremos de força-tarefas para aplicação de melhoria ou correções críticas, sem contar que não teríamos a necessidade de reescrever funcionalidades inteiras por ela ter muitos bugs, ou ser ineficiente ou não ter documentação.

Do que é referente ao processo de planejamento, eu não tenho autoridade para falar quais as melhores metodologias ágeis para tal, mas em termos culturais precisamos que as decisões sejam tomadas com, ao menos, o conhecimento de todos os envolvidos, ou seja: desenvolvimento e operações. Em linhas de desenvolvimento, a arquitetura da solução e os elementos necessários para tal precisam ser tecnicamente viáveis, e os prazos e esforços precisam ser alinhados. Em linhas de operações, precisa-se garantir que os recursos necessários estarão disponíveis e são capazes de atender à necessidade da solução, contando ainda com o alinhamento do time de finops e o financeiro. Sabendo de tais coisas, fica assim comprovada a necessidade do envolvimento de ambos os times no processo de planejamento das soluções.

Além disso, no que tange a etapa anterior (de monitoramento), é essencial que possamos medir os diferentes aspectos das soluções que estão sendo planejadas. Desta forma, saberemos se o que foi entregue passou por toda a esteira de maneira eficaz, se as expectativas do cliente foram atendidas, se algo foi executado errado, se o que estava planejado e os gastos esperados condizem com a realidade (para mais ou para menos), entre outros. Neste ponto, cada um dos times vai saber quais as métricas mais importantes para os relatórios de cada um, e é importante que todos saibam quais são: 1) para que as ações necessárias para tais sejam tomadas, seja de desenvolvimento, operações, financeiro, etc; 2) para que seja evitado retrabalho e falta de entendimento das necessidades de cada setor; 3) para que todos tenham suas necessidades atendidas e consigam realizar um bom trabalho.

Na codificação, realizamos aquilo que foi previamente combinado e definido no planejamento. Aqui devemos pensar em ferramentas que nos auxiliem durante o trabalho de codificar, indo desde a máquina de trabalho até inteligências artificias. Quando o time se comunica e troca suas experiências sobre a forma como cada um aborda os problemas diários, conseguimos identificar e definir padrões, mas também sabemos até que ponto fazer isso. Se desejamos remover impedimentos e agilizar o processo de desenvolvimento, precisamos que a máquina, o SO, a IDE, as ferramentas de análise, bibliotecas e o gerenciador de pacotes se adequem ao programador sem que a conformidade e as necessidades do negócio sejam desprioradas. Neste ponto, vemos que os pilares de compartilhamento e experimentação são relevantes.

Ademais, durante a elaboração da solução, devemos usar uma abordagem que favoreça a reutilização e o automação. Como dito anteriormente, o DevOps é totalmente compatível com o ágil e com as melhores práticas de programação. Então não haverá conflitos de interesses aqui no tocante a cultura, pelo contrário, haverá um incentivo para tal. Com a implementação da integração contínua, os testes e as validações serão feitos precocemente na evolução da solução. Desta forma, garantimos que as novas linhas sejam compatíveis com o código atual e não apresentem um comportamento inesperado. Algumas metodologias vão tirar mais vantagem do continuos integration (CI), como é o caso do Desenvolvimento guiado a testes (TDD) e do Desenvolvimento guiado a comportamento (BDD).

Não podemos apenas valorizar as ferramentas e as técnicas nesse etapa. Esse tipo de pensamento é tentador, mas podemos cair na armadilha de estar sempre procurando por coisas mais sofisticadas e automatizadas, e não valorizar aquilo é fundamental: a colaboração e o bom relacionamento. O que significa dizer que apesar de haverem boas ferramentas, por vezes não temos o capital financeiro para as implementar. Nesse contexto, a colaboração e ajuda dos colegas do time é essencial. Cada um divide a sua experiência e faz a sua contribuição, e fazendo isso, cada um aprende e reforça os próprios conhecimentos. Uma equipe que não faz esse exercício de compartilhamento, não teve toda a sua potencialidade explorada ainda.

Agora, eu falarei de dois elementos que não há consenso sobre a ordem de execução deles, eu particularmente não vejo diferença, mas ambos precisam existir e estar ligados. Estou falando dos testes e o build. De toda forma, ambas podem ocorrer de forma simultânea e automática. Vou me deter, a princípio, na etapa de testes:

Os testes são cruciais quando se deseja produzir software com excelência. Nesta etapa, o time de desenvolvimento e o time de qualidade de código trabalham mais próximos para que haja diversos tipos de coberturas de testes. Um QA saberia falar melhor do que eu sobre todos os aspectos desse etapa, mas o que eu gostaria de frisar é a automação. Creio que essa seja uma das maiores necessidades dos testadores. Podemos integrar testes ao processo de CI e fazer os testes mais fundamentais, como também os unitários, funcionais e build. Ainda podemos integrar testes de carga, estresse e caixa branca ao pipeline, sem contar os de segurança.

Existe uma gama muito grande de testes que podem ser integrados ao pipeline de integração. Acerca disso, é necessário que haja um diálogo aberto entre o time de desenvolvimento, testes, operações e financeiro. Visto que quanto maior a bateria de testes, maiores serão os critérios de avaliação, maior será a quantidade de relatórios para avaliar, podem haver maiores custos com ambientes e ferramentas de teste, entre outros. O importante é que os testes atendam a necessidade do negócio, estejam disponíveis sempre que necessários e possam agregar valor.

Outro aspecto relevante dos testes é a presença de múltiplos ambientes. Quando trabalhamos desta forma, conseguimos níveis de capacidade e disponibilidade diferentes por ambiente. Deveríamos ter tantos ambientes quanto o necessário para evitar que o máximo de instabilidade seja transmitido de um para outro. O ambiente de produção deve ser o mais robusto possível, dentro dos requisitos e limitações da organização. Já o ambiente de homologação é considerado essencial para testes com o cliente e testes fim-a-fim, ele deve ser o mais semelhante do ambiente produtivo possível. Há ainda literaturas que tratam de ambiente de QA, desenvolvimento e teste. Os ambientes de desenvolvimento e testes se aproximam mais da abordagem gitflow de versionamento de código, onde o ambiente de desenvolvimento tem o software que será lançado ao fim da sprint; e nos ambientes de testes temos o código das branchs de feature e hotfix, em que a segregação é feita por funcionalidade. Em qualquer abordagem que seja, a automação é vital para o gerenciamento eficiente de múltiplos ambientes, porque o pipeline precisa ser inteligente para entender para qual ambiente o código integrado deve ir e a infra precisa estar automatizada/codificada para atender as necessidades do negócio sob demanda.

O build, ou empacotamento, é a etapa de construção do entregável. Isso pode ser um pacote de aplicação, um módulo, um zip ou uma imagem de contêiner. Só é possível automatizar um processo quando ele está bem definido. Por isso é mister que a construção da entrega passe pelas mãos tanto do time de desenvolvimento como da operação. Porque o desenvolvedor, o criador, deve saber exatamente que parâmetros passar, que passos realizar para a execução da funcionalidade, quais os cenários de falha esperados, quais os elementos críticos do novo fluxo, entre outros. E o time de operações precisa saber onde colocar os parâmetros, quais a melhores práticas de segurança para a plataforma onde roda a automação, quais métricas devem ser coletadas, como implantar e fazer rollback, entre outros. Ratifico que, essa etapa exige que operações e desenvolvimento trabalhem juntos, para que todos os requisitos sejam repassados para a construção e implantação da solução. Digo isso porque é neste momento em que ocorre a maior parte dos desentendimentos. Pela falta de comunicação e bom relacionamento entre as equipes, o processo de atualização é conturbado. Quando o objetivo dos times é o mesmo, todas as necessidades do outro time, são nossas também. Por muitas vezes, a necessidade do time de desenvolvimento é de informações para throubleshooting, ou comunicação sobre os problemas, ou relatórios de erros e desempenho, entre outros. Em contrapartida, o time de operações precisa saber como lidar com erros, quais erros são críticos ou não, como garantir o SLA, entre outros.

Não podemos esquecer de testar o entregável antes de aplicá-lo. Lembra que eu mencionei anteriormente que não há um consenso sobre qual vem primeiro: Build ou Testes? Então, isso não faz diferença na esteira DevOps, mas está diretamente ligado aos critérios de aceite da demanda, empresa ou cliente. Há alguns testes que só são possíveis de se acontecer com o entregável pronto, como os testes fim-a-fim, testes de aceitação, teste de carga, entre outros. O objetivo dos testes é, assim como em outros momentos, garantir que o comportamento da funcionalidade, adicionada ou modificada, esteja dentro do esperado. Dos testes que comumente são realizados nessa etapa, o teste de usuário é um dos mais importantes.

Por vezes, precisamos verificar o comportamento da aplicação em ambiente produtivo e, para tal, utilizamos da implantação automatizada para nos auxiliar.

Quando falamos de implantação, não podemos deixar de mencionar a entrega. A etapa de release, ou entrega contínua, é responsável por gerenciar as entregas das novas funcionalidades, versionar os pacotes de implantação e documentar as alterações feitas. Entregar software pode ser um trabalho complicado quando não temos a metodologia e a cultura certa. Antigamente, os times de desenvolvimento e operações trocavam muitas farpas durante a entrega da aplicação pelo bom relacionamento e compartilhamento de informações serem precários. Mas hoje, com o advento da cultura DevOps e das metodologias ágeis, temos um cenário muito mais colaborativo e construtivo. Se analisarmos os passos anteriores, veremos que ambos os times participaram da concepção, criação, testes e construção da entrega.

Analise comigo essa etapa: 1) gerenciar entregáveis é gerenciar o produto final... isto é: verificar o que entra de novo e o que sai, verificar se os critérios de aceite foram atingidos, saber quais os comportamentos esperados e inesperados; 2) e tudo isso será versionado e disponibilizado para todos aqueles a quem essas informações importam; 3) alem de tudo isso, precisamos garantir o minimo de documentação possível que garanta o entendimento imediato daquilo que interessa a todas as partes (negócio, desenvolvimento, produtos, operações).

Desta forma, os últimos alinhamentos foram feitos e o pacote é entregue para o cliente.

A etapa de implantação é a mais esperada por todos. Alguns sentem alívio, outros sentem ansiedade, e outros ficam em estado de alerta. Nesta etapa, o ambiente alvo passa pelas mudanças necessárias para que a aplicação seja atualizada. Seja qual for o ambiente, a implantação deve acontecer da mesma maneira em todos eles. Além de poupar retrabalho, isso poupa incompatibilidades, ajudando também na manutenibilidade e na redução da complexidade dos ambientes. Outrossim, a maior semelhança entre ambientes melhora a confiabilidade dos testes.

Um pilar importante nas etapas de operações é o de automatização. Apesar de a imensa quantidade de ferramentes disponíveis para tal, os times de operações tendem a se apegar ao bom e velho bash script. Para nós, ele é essencial, mas deve ser buscado como última alternativa na maioria dos casos; casos esses como: provisionamento, subida de infraestrutura, notificação, alterações em massa, atualização de aplicativos, entre outros. Ele tem o seu lugar em tarefas simples, mas não podemos limitar a ele. Pense no bash como um canivete suíço: ele é bom, versátil, pode fazer quase tudo e é confiável; porém, fugindo de alegoria, ele é complexo, tem pouco desempenho, possui uma acoplação perigosa como sistema operacional e é difícil de manter. Na cultura DevOps, especialmente em infraestrutura de nuvem, abordagens de mercado para codificação de infra e provisionadores são muito mais modernas, robustas, performáticas e modulares. E quando elas não dão conta, podemos trabalhar com o Python que dá muito mais suporte e facilidades do que o bash, é mais performático, suporta múltiplas plataformas, é ainda mais versátil, e muito mais. Por isso, é importante que a caixa de ferramentas do operador esteja cheia de opções no tocante a lida com a implantação.

Outro elemento que é mister de se encontrar no arcabouço de um time de operações é a capacidade para múltiplas metodologias de implantação e testes em produção. Parece um pouco exagerado fazer um teste em produção para alguém de operações, mas essa é uma necessidade mais presente do que um SRE gostaria que fosse. Para isso, utilizamos certos métodos já bem documentados e suportados por diversas plataformas de operação: são as implantações canário e blue/green. Essas metodologias não apenas nos asseguram de certos problemas, como também garantem que comportamentos inesperados e instabilidades sejam evitadas de ocorrer para uma boa parcela dos clientes. Também conseguimos dados de métricas, de log e de banco (isto é, transações), para por meio deles tomar decisões sobre os próximos passos, o que pode ser melhorado, o que não se comportou como deveria, etc.

Conforme o ciclo de vida do software evolui no ambiente, alguns eventos específicos ocorrem, e certas atitudes são responsabilidade do time de operações. Por vezes, são ações referentes a escalabilidade, disponibilidade, investigações de comportamentos inesperados e até mesmo scripts de rotina. Na maioria das vezes, são eventos que estão indiretamente ligados ao que foi desenvolvido. Por exemplo, a troca de arquivos entre cliente e plataforma; a geração de relatórios operacionais; o suporte e manutenção à infraestrutura; as alterações de rotas e lógica de redes; as configurações de soluções de terceiros; as tarefas voltadas para finops com foco em infraestrutura; a criação de elementos de monitoramento; entre outros.

Quando trazemos uma veia de desenvolvimento para a operação, esperamos que os softwares auxiliem nas tarefas citadas acima, automatizando-as. Sejam eles de terceiros ou desenvolvidos pela própria equipe, precisamos que as necessidades específicas do negócio sejam atendidas. Muitas soluções de mercado surgiram desta maneira. Espera-se que, com a adoção da cultura DevOps, a quantidade esmagadora dos processos dentro da operação seja automatizada, ocorrendo de forma instantânea ou com o apertar de um simples botão. Uma das linguagens mais populares é o Python, pela sua baixa curva de aprendizado e versatilidade.

A automatização de processos repetitivos é primordial, mas não podemos negligenciar a automatização da infraestrutura. Resiliência e elasticidade são as regras quando falamos de programação WEB. Por isso, a maioria das ferramentas e plataformas dão suporte a ações automáticas que previnam indisponibilidade ou sub-capacidade das aplicações. Esse recurso é importante para que o acordo de nível de serviço seja satisfeito, para que os gastos com infraestrutura sejam minimizados, para que a aplicação seja responsiva à demanda de clientes, para que as recuperações pós-desastres sejam mais eficientes, entre outros.

E não podemos deixar de mencionar a governança quando o assunto é a operação. Muitas vezes precisamos nos adequar a certos padrões da indústria para ganhar uma licitação, enquadrar-nos com as determinações estatais ou ainda para fazer parcerias com outras empresas. Essas padronizações nos ajudam a ter um processo de entrega de software mais adequado à empresa, e ele pode influenciar em diferentes aspectos dela. No nosso caso, precisamos nos atentar a normas que ditem a forma como o software deve ser desenvolvido, como os dados devem ser armazenados, como lidar com a segurança nas esferas de desenvolvimento e operações, como os diferentes processos internos devem ocorrer, etc.

Por fim, a etapa de monitoramento é o elemento que interliga a operação com o planejamento das entregas. Esse tópico eu gostaria de começar com uma pergunta: por que é tão importante medir? Dar-lhe-ei a resposta mais adiante, mas antes uma provocação: você dirigiria um carro sem painel de instrumentos? Isso é pelo menos falta de bom senso. Pensando sob essa perspectiva, a medição da nossa operação é essencial quando desejamos saber quando um elemento crítico do funcionamento da empresa está prejudicado. Ela é importante para verificar o nosso desempenho, respeitar normas e acordos de serviços, verificar se temos os insumos necessários para manter o operação do produto, juntar dados que justifiquem planos de ação, etc. Em suma, geramos feedbacks e monitoramos o estado da aplicação.

Os feedbacks são elementos fundamentais do processo de melhoria contínua. A evolução exige consciência das deficiências e forças do estado atual para que a mudança que venha a ocorrer seja benéfica, porque podemos evoluir positivamente, mas também negativamente. Ou seja, se eu apenas mudo, mas não sei que resultados obtivemos com isso, ficamos sem saber se fizemos de fato uma decisão boa (que vai manter a engrenagem funcionando), ou se tomamos uma péssima decisão (causando prejuízo e até falência). Ou seja, ficamos sujeitos a mediocridade, ou pior: ficamos antiquados. Uma empresa desatualizada vai perdendo aos poucos espaço de mercado para outras que sabem operar de forma adequada, sabendo aproveitar as oportunidades e se esquivando dos perigos.

Já o monitoramento, que não deixa de ser um tipo de feedback, vai garantir que todos os aspectos importantes do negócio estejam visíveis, disponíveis, documentados e cobertos. Seu objetivo é observar os indicadores e dizer se eles estão nos valores esperados. Não estando eles, será verificado se esse cenário é positivo ou negativo para o produto final. Sendo eles positivos, podemos dizer que aproveitamos uma oportunidade adequadamente ou que encontramos uma boa oportunidade para investir. Caso negativos, devemos notificar a quem compete resolver a situação, já o munindo das informações necessárias para tomada de decisão ou início da investigação em caso de problema. Podemos ainda identificar casos desavantajosos que não são urgentes, mas que revelam um mal planejamento ou uma oportunidade a se explorar (que eu acredito que seja o melhor dos casos, porque transforma uma fraqueza em uma vantagem).

Desafios

Apesar de todas as vantagens, pode ser desafiar implantar essa cultura na empresa alvo. Como se trata de algo cultural, fica muito mais difícil fazer com que todos optem por ela. Uma metodologia, ou um protocolo é muito fácil de ser implantado, visto que não implicar em mudança de perspectiva. Por outro lado, uma mudança cultura envolve não só uma mudança de paradigma mas uma mudança de mente. Tais coisas somente são internalizadas quando repetidas e incentivadas.

Outro ponto desafiador, é implementar uma série de ferramentas e práticas para pessoas de diferentes níveis de conhecimento. Porque sempre há pessoas com mais dificuldades de aprendizado e pessoas de áreas distintas. Por isso, o reforço e o aprendizado contínuo são peças fundamentais para a adoção da cultura DevOps.

E existe ainda o risco de que, se a cultura for má implementada, teremos um aumento da complexidade dos processos. Isso é a consequência da automatização, que pode ser feitas de variadas formas e em diferentes cenários. Desta forma, o compartilhamento e a margem para erros devem ser intrínsecos aos envolvidos.

Conclusão

Então, como você pode notar, o ciclo DevOps apresenta coesão. Ele busca aprimorar o ciclo de desenvolvimento de software por meio da maior sinergia entre as áreas, de forma multidisciplinar, colaborativa, programática e contextualizada. Ele contempla desde o planejamento do projeto até o monitoramento do que foi entregue, estruturando as etapas ordenada e logicamente. Ele enfatiza a automação e as ferramentas durante todos os elementos para reduzir falhas, aprimorar entregas, agilizar processos e assegurar padrões. Além disso, a colaboração é outro componente fundamental da cultura, bem como o bom relacionamento entre desenvolvimento e operações. E podemos contar também com o aspecto da medição, que nos dará os insumos para os processos de tomada de decisão, monitoramento e melhoria contínua.

Links úteis

Slides para apresentação

Testes e validação de software

Lázaro Vinícius de Oliveira Bonifácio — Sat, 16 Sep 2023 00:44:25 +0000

Indicações

Livro: Accelerate - Building and Scaling High Performing Technology Organizations
Pesquisa: Os testes finais de aceitação pelo usuário (UAT: User acceptance Testing) exigem perguntas difíceis de responder em um ambiente ágil.

Desejo

A grande maioria das empresas de serviços digitais desejam que suas aplicações estejam disponíveis para o consumo dos clientes sempre que precisarem. Para obter esse nível de disponibilidade, elas vão precisar, além de outras coisas, que o produto seja devidamente testado e validado. Sejam arquiteturas, servidores ou sistemas, se desejamos resiliência, confiabilidade e segurança precisamos fazer isso.

Vamos ao que interessa!

Code & Test & Release & Repeat

Agil

Algumas metodologias ágeis são mais favoráveis aos testes, como: Estórias de usuário, Behavior Driven Development (BDD) e Teste Driven Development (TDD). Pode-se utilizar os princípios INVEST para criar as estórias de usuário. Para esse tema eu recomendo muito esse post.

A técnica conhecida como TDD foi introduzida no XP e é a mais eficaz em garantir que os testes automatizados funcionem de forma confiável. Antes mesmo de iniciarmos o desenvolvimento, o programador já faz a criação do teste seguindo três princípios: testes de falha esperada, testes de sucesso, e tanto testes antigos como testes novos bem estruturados/refatorados.

Os testes precisam estar versionados. As mudanças precisam ser integradas ao repositório remoto diariamente (Integração Contínua).

Testes

Quando falamos de desenvolvimento de software, costuma-se dividir os testes em duas classes: os funcionais, que verificam o comportamento da aplicação, e os não-funcionais, que verificam os elementos que a aplicação precisa.

No tocante aos testes funcionais, o Manual de DevOps divide os testes em quatro tipos:

Testes unitários: testes de um método, função ou classe (pequenas parte) do código com valores de entrada, consulta e saída pré-definidos (mockados);
Testes de aceitação: esse tipo de teste verifica se o que foi desenvolvido foi o que o cliente pediu, e não o que o programador esperava desenvolver;
Testes de integração: visando garantir que a nova funcionalidade não interfiram de forma inesperada com as demais;
Teste de segurança: garantem que as politicas de segurança e conformidade foram seguidas, e verificar a existência de vulnerabilidades.

Por outro lado, os testes não-funcionais, não estamos falando apenas da aplicação, mas da infraestrutura que a suporta, da lógica e dos diretórios, das regras e das integrações internas e externas. Em suma, limites e requisitos. Muitas vezes, o testes não-funcionam dizem respeito ao desempenho. Existem três testes primordiais quando tratamos de limites e requisitos. São eles:

Testes de carga: valida o volume que uma aplicação suporta;
Testes de resistência: valida a estabilidade e capacidade de um ambiente (aplicação, plataforma, banco, cache) em um determinado período de tempo;
Testes de stress: verificamos o comportamento das métricas de uma aplicação, sua estabilidade e capacidade de recuperação quando levada ao limite.

Ferramentas

Além das metodologias citadas (TDD e BDD), também existem frameworks de testes e bibliotecas de testes, como é o caso, respectivamente, do JBehave e da XUnit's. Foram desenvolvidos até mesmos recursos linguísticos para criação de testes, como o Gherkin.

Realidade

Espero que tenha ficado mais do que claro que quando se deseja que suas aplicações sejam consumíveis sempre que os clientes precisarem é preciso uma boa cobertura de testes. Os testes previnem e anteveem problemas nos ambientes produtivos por meio do aferimento de diversos indicadores. Quer sejam arquiteturas, servidores ou sistemas, se desejamos resiliência, confiabilidade e segurança precisamos testá-los.

Um minuto do seu tempo

O que eu disse faz sentido pra você? Me fala um pouco da sua experiência com testes!

Não esquece de curtir e comentar esse post. Se esse conteúdo foi relevante pra você ele com certeza pode ser pra alguém do seu trabalho ou empresa.

Me conta o mais você gostaria de ver aqui. Alguma das palavras acima chamou a sua atenção? Me conta.

Um abraço, rede!

Processo de implantação de uma aplicação

Lázaro Vinícius de Oliveira Bonifácio — Sun, 10 Sep 2023 17:57:45 +0000

Introdução

Um bom processo de implantação contínua (CD) é aquele em que às boas práticas de CD estão alinhadas com os objetivos da organização, e vice-versa. A definição de OKRs (Objetivos e Resultados Chave) devem acontecer por parte dos executivos e os envolvidos precisam reconhecê-las.

Então, a entrega de valor ocorrerá de forma cíclica e contínua. E ela será assegurada por indicadores; revisada pelo time; e utilizada para aprimoramento.

O processo de CD aliado à gestão de serviços de TI favorece uma arquitetura robusta e coesa, uma gestão de mudança aprimorada e segurança abrangente.

Vamos ao que interessa!

Processo de melhoria contínua

Quando se fala de melhorias contínua, precisa-se haver uma reservar, em média, 20% da capacidade da equipe para resolução de requisitos não-funcionais e débitos técnicos. Esse tipo de pensamento evita que em médio/longo prazo seja necessário reescrever todo o código, e que o processo de entrega de valor seja interrompido ou seja pouco eficiente.

Entrega ágil X garantia de estabilidade

As OKRs e as diretivas de governança são os melhores balizadores desse conflito de interesses. Por um lado, há o time de desenvolvimento e produtos, que ter suas entregas de valor o mais rápido possível no ambiente; no outro há o time de sustentação e operações, que querem evitar o máximo instabilidades e perdas do que já é entregue. Desta forma, ambos os times devem trabalhar em conjunto, utilizando práticas de integração e testes contínuos, alinhados aos objetivos da organização.

Algumas das técnicas utilizadas para a manutenção e sustentação dos serviços são:

Automatização;
Ambientes simulados;
Planejamento de capacidade, disponibilidade e continuidade;
Gestão de mudanças: para software e plataforma.

Melhores práticas

Dentre as melhores práticas podemos citar o "Gerenciamento de Nível de Serviço". Ele vai gerar alguns documentos, como os de "Requisitos de Nível de Serviço", "Acordo de Nível de Operacional" e "Acordo de Nível de Serviço". Quando devidamente utilizados, esses documentos garantirão que as necessidades dos cliente e conformidade com regulamentos sejam atendidas.

Como stakeholder, procure sempre se inteirar e/ou promover a inteiração dos demais com o contexto do projeto em que você está alocado. Esse conhecimento manterá o time e o projeto alinhados com a satisfação do cliente.

Crie uma um processo confiável e replicável de implantação, não se esquecendo da etapa de feedback.

Antes de implantar continuamente, recomenda-se:

Automatizar todo o processo de build, teste, liberação e implantação;
Ter uma cobertura de testes confiáveis e automatizados;
Registrar, documentar e armazenar os testes de sistemas que são executados no ambiente de produção;
Escrever testes de sistemas funcionais para serem executados em ambiente do tipo produção.

Conclusão

Em síntese, a adoção de práticas de implantação contínua alinhadas aos objetivos da organização, em conjunto com a gestão eficaz de serviços de TI e a colaboração entre equipes, resulta em um processo robusto e ágil. A implementação dessas melhores práticas, como o Gerenciamento de Nível de Serviço e a automação, garante a satisfação do cliente e a entrega de valor contínua, enquanto se mantém a estabilidade e a segurança. Este ciclo virtuoso de melhoria contínua impulsiona a eficiência e a qualidade a longo prazo.

Interaja

Como seria o processo de implantação ideal para você? Deixe uma reação, um comentário e/ou compartilhe esse post com alguém.

Um abraço, rede!

Ciclo de vida DevOps

Lázaro Vinícius de Oliveira Bonifácio — Wed, 06 Sep 2023 23:08:49 +0000

Introdução

Uma cultura que promove a agilidade e colaboração entre os times de desenvolvimento e operação certamente está de baixo do guarda-chuva ágil. Quando bem implantada, os processos afetados por ela tornam-se tão automatizados e seguros quanto se deseja.

Vamos ao que interessa!

A cultura DevOps é fundamentada no sistema de gestão Lean. Seus valores fazem referência ao manifesto ágil. Seu objetivo é que as equipes consigam desenvolver e entrega software de forma contínua e consistente. A forma encontrada para fazer isso é promovendo a boa comunicação e mutua colaboração entre os times de desenvolvimento e operações.
Falar de ágil é dispensar qualquer menção ao modelo cascata, ficando claro que essa metodologia não é compatível. Por estar de baixo do guarda-chuva ágil, a cultura preza pela responsividade às necessidades do negócio. Isso requer que mudanças sejam feitas, testadas e implantadas continuamente. Ou seja, o software está sempre se alinhando com o objetivo do negócio.

Pipeline DevOps

Na computação, o termo pipeline surgiu para designar uma funcionalidade existente em processadores modernos: o processamento paralelo de instruções em sequência. Da mesma forma, o pipeline DevOps visa definir etapas de desenvolvimento que são seguidas umas das outras, mas que podem acontecer de maneira independente entre funcionalidades distintas. São elas: integração contínua (CI), entrega contínua (CD), teste contínuo, implantação contínua (CD), monitoramento contínuo, feedback contínuo e operação contínua.

Integração contínua

A literatura recomenda que os desenvolvedores devem integrar seu código ao principal ao menos uma vez ao dia, a ideia é que haja mais estabilidade no código com um topo por meio da rápida identificação de falhas na integração de códigos. Em uma esteira DevOps, os códigos são integrados e automaticamente testados, para que esse processo seja muito mais rápido e automático. Aliado ao versionamento e a comunicação automatizada, temos maiores garantias de que os erros serão rapidamente identificados, comunicados e corrigidos.

Entrega contínua

A entrega de software também é automatizada, e os critérios que definem isso podem ser os mais variados: fim de sprint, periodicidade, sucesso em certos testes, etc. O objetivo aqui é que uma funcionalidade nova ou correção estejam prontos para serem implantados.

Teste contínuo

É desnecessário mencionar as vantagens dos testes em software. Há uma metodologia inteira guiada por testes para mostrar isso. Essa etapa dever ser a mais priorizada quando os objetivo é entregar software estável, previsível, seguro, robusto, qualificado e completo. Por muitas vezes, principalmente em pequenos projetos, negligenciamos essa etapa, seja por pressa ou por ignorância. O que a cultura tem a contribuir com os testes é na automatização deles.

Operações contínuas

Tempo fora do ar é tempo perdido, e tempo perdido é prejuízo. A palavra-chave aqui é disponibilidade. Busca-se eliminar as paradas programadas, janelas de manutenção, por meio da automação nos processo de recuperação de falhas, sejam de hardware ou de software.

Monitoramento contínuo

Neste ponto, o desempenho das aplicações é monitorado para que a experiência do cliente esteja dentro das definições de nível de serviço. Não só para isso, mas para a detecção de anomalias, sejam de software como de segurança, e para geração de relatórios que serão utilizados na etapa seguinte.

Feedback Contínuo

Ter retorno sobre o que fazemos é algo essencial quando se quer ir mais longe. O feedback é uma forma excelente de saber se alcançamos ou não aquilo que planejamos. Esse recurso nos dará insumos no processo de tomada de decisão no modelo de melhoria contínua.

Automação de atividades no ciclo DevOps

Automação é sinônimo de aumento de produtividade e redução de falhas humanas. A automação deve priorizar em primeira instâncias os processos mais críticos, como os que agregam maior valor ao negócio. Entre os motivos que sustentam a automação estão:

Menor ocorrência de erros, maior facilidade de identificação de erros;
Processos repetíveis e seguros
Documentação do processo facilitada
Processos automatizados são mais rápidos do que processos manuais
Automação barateia a execução de processos

A automatização é excelentemente aproveitada quando se deseja ter escalabilidade, replicabilidade, confiabilidade e gerenciamento facilitado. Poucos são os processos que não suportam automação.

Ágil x DevOps

O valor "indivíduos e interações mais do que processos e ferramentas" se encaixa com o pilar do compartilhamento/colaboração da cultura DevOps. A Integração contínua, conceito oriundo da metodologia Extreme Programming (XP), foi absorvido na cultura DevOps, devido os seus ganhos significativos para o desenvolvimento. Nota-se que há compatibilidade com outras metodologias e ferramentas ágeis.

Para não sobrar dúvidas

A cultura DevOps é uma ferramenta agilizadora e poderosa para promover maior integração entre times. Sua compatibilidade com o manifesto ágil e sua abordagem automatizadora faz com o que as empresas tirem muitas vantagens do seu uso. Mas do que cargos e ferramentas, DevOps é uma cultura. O ciclo de vida DevOps influência tanto quando é influenciado pelo ciclo de desenvolvimento, que não foge muito das metodologias ágeis.

Interaja

Eu estou curioso para saber da experiência de vocês com DevOps na sua empresa ou em empresas que você passou. Deixe um comentário, curta e me siga para mais conteúdos como esse. Um abraço, rede!

CI/CD/CD: Dev e Ops convivendo em harmonia

Lázaro Vinícius de Oliveira Bonifácio — Fri, 26 May 2023 19:35:29 +0000

Dentre todas as etapas de desenvolvimento de software do círculo DevOps, a integração, a entrega e a implantação são centrais. Essas etapas são intermediárias entre o setor de desenvolvimento e o de operações, é nesse ponto em que ambos os times se conectam.

Trabalhar essas etapas na cosmovisão DevOps é buscar o meio-termo entre o lado de desenvolvimento, que quer suas alterações o mais rápido possível no ambiente, e o time de operações, que quer garantir a estabilidade do ambiente. Tendo isto dito, o engenheiro DevOps vai buscar automatizar e otimizar os processos de entrega e implantação, favorecendo o time de desenvolvimento, a fim de que as alterações dos devs sejam refletidas no ambiente com o mínimo de interferência e o máximo de agilidade; e vai automatizar o processo de integração e testes, a favor do time de operações, visando garantir que o código seja seguro, estável, escalável, revisado e aprovado nos mais altos padrões de estabilidade.

Essa cultura implementa esses benefícios é por meio de 2 coisas principais: ferramentas e cultura. As ferramentas de automação, gerenciamento e orquestração são para o Engenheiro DevOps o que a linguagem de programação é para o desenvolvedor de software. Sem elas, ele não consegue alcançar os objetivos da sua função e, consequentemente, da sua empresa. Da mesma forma, sem o suporte da cultura, a prática do DevOps não se sustenta e muitos problemas surgem e oneram a cadeia produtiva tanto de desenvolvimento como de operação. Por isso, um forte alinhamento com o núcleo do negócio vai garantir que o objetivo de cada área da empresa diretamente ligada ao ciclo do software goze dos benefícios da cultura DevOps.

No âmbito ferramental, podemos habilitar elementos cruciais em cada etapa do desenvolvimento e de operação do software. Mas tratando exclusivamente da integração contínua (CI) de código, implementa-se uma esteira, conhecida como pipeline, que submete as novas alterações e/ou todo o código a testes automatizados, onde o objetivo é garantir que o software permaneça estável, seguro, escalável, robusto, coberto e, principalmente, funcionando. Quanto mais aspectos de um código forem testados, mais problemas são prevenidos. Dentre várias ferramentas de teste, podemos frizar as mais utilizadas, como: o SonarQube, para testes de qualidade de código; o Snyk, para testes de segurança de dependências; os testes unitários, cada linguagem tem as suas ferramentas específicas; o OWASP ZAP, para testes de penetração e outros; o APache JMeter, para testes de desempenho; o Selenium, para testes de compatibilidade entre navegadores e plataformas; entre outros.

Tratando de ferramentas de entrega contínua (CD), é importante mencionar a necessidade de automação. É crucial que sejamos capazes de gerar um entregável de forma rápida e eficiente, sem depender de processos manuais que podem ser demorados e propensos a erros. Para isso, podemos estabelecer condições que disparem sua produção, como o fim de um sprint, a aprovação de um responsável ou o sucesso de testes específicos. Dessa forma, garantimos que o pacote seja criado sempre que necessário, sem a necessidade de intervenção manual. Com a implementação de uma esteira, garantimos que o artefato esteja sempre consoante as expectativas do usuário e seja entregue de forma rápida e eficiente.

Quero ainda destacar a relevância do Continuos Deployment (ou Implantação Contínua) na eficiência da operação. Esse processo é repetitivo e sofre pouquíssima modificação com o passar do tempo. A execução desse processo de forma manual e/ou fora de condições específicas certamente ocasionará um problema em médio/longo prazo, visto que torna provável a falha humana. É comum que a equipe de operações crie scripts que automatizem essa tarefa, mas um engenheiro DevOps bem alinhado com ambos os times vai garantir que mudanças importantes nessa etapa sejam consideradas quando necessário, como, por exemplo: alterações a nível de plataforma, parametrização do entregável, novos requisitos de arquitetura, documentação, tratativas de problemas, entre outros.

A prática do DevOps é amplamente reconhecida como benéfica para o desenvolvimento de software, uma vez que permite a integração e a colaboração efetiva entre as equipes de desenvolvimento e operações. No entanto, é importante ressaltar que o uso inadequado dessa cultura pode gerar malefícios que não são inerentes a ela, como a baixa qualidade do software, problemas de segurança, complexidade excessiva, falta de monitoramento e feedback, entre outros.

Um dos principais benefícios da cultura DevOps, além da integração das equipes, é a automação de processos, que aumenta a eficiência e a agilidade do desenvolvimento de software. No entanto, a dependência excessiva de ferramentas e automações pode ser um obstáculo, pois pode gerar complexidade adicional e dificuldades na manutenção dos processos.

Outro obstáculo que as equipes podem enfrentar é a resistência cultural, que pode ocorrer em ambos os lados da cultura DevOps. Os desenvolvedores podem se sentir desconfortáveis com a mudança de paradigma, enquanto os profissionais de operações podem ser relutantes em permitir que as alterações sejam feitas no ambiente de produção. Dessa forma, é importante haver um esforço conjunto para que a cultura DevOps seja adotada de forma efetiva.

Além disso, a curva de aprendizado e o esforço inicial para implementar a cultura DevOps também podem ser desafiadores. É necessário haver um investimento adequado em treinamento e capacitação, bem como na implementação de ferramentas e processos. No entanto, é importante lembrar que, a longo prazo, os benefícios da cultura DevOps superam os desafios iniciais.

Por fim, é importante ressaltar que a adoção da cultura DevOps deve ser acompanhada de um forte alinhamento com o núcleo do negócio, a fim de garantir que os objetivos de cada área da empresa diretamente ligada ao ciclo do software sejam alcançados. A colaboração, a automação, a medição e o compartilhamento são os pilares fundamentais da cultura DevOps, e devem ser incentivados para que a prática seja sustentável e efetiva a longo prazo.

Postagem original: https://naodevcode.blogspot.com/2023/05/cicdcd-dev-e-ops-convivendo-em-harmonia.html