O que é DevOps – minha experiência como executivo nessa frente.

Aqui quero trazer um pouco da minha experiência com DevOps passando por questões bem técnicas e gestão do processo. Muitas das coisas que eu pude fazer foi por uma questão de experiência em projetos e por isso tive condições de pavimentar uma estrada de sucesso para essa frente!

Eu tive a oportunidade de criar a área de DevOps por uma empresa na qual passei, então pude aprender desde subir uma máquina com wizard (next, next e finish) nas clouds AWS, Azure, e GCP, como também aprendi coisas como versionamento de imagens, configurações de Redis, pipelines simples e complexos no Jenkins, com certeza me diverti muito com isso. Também tive a oportunidade de pensar em processo e gestão dessa área, além de implantar isso,pois, claramente sem um mínimo de gestão e organização a frente de DevOps pode sucumbir e ao invés de facilitar pode travar todo o processo de melhoria e entrega contínua.

Na Ciência da Computação o DevOps (contração de development e operations), é uma prática da engenharia de software que unifica o desenvolvimento de software (Dev) e a operação de software (Ops), com característica principal de defender a automação e monitoramento em todas as fases da construção de um software (desde a integração, teste, liberação para implantação, ao gerenciamento de infraestrutura), auxiliam empresas no gerenciamento de lançamento de novas versões, padronizando ambientes em ciclos de desenvolvimento menores, frequência de implantação aumentada, liberações mais seguras, em alinhamento próximo com os objetivos de negócio. Isso segundo a Wikipedia.

CALMS

  • (C)ultura – pessoas e processos são mais importantes. Se a cultura não estiver presente, qualquer tentativa de automação está destinada a falhar;
  • (A)utomação – libere humanos para realizar tarefas que exigem criatividade e intuição e deixe as tarefas repetitivas para os computadores, que sabem executá-las rapidamente e de forma bem mais confiável;
  • (L)ean (pensamento enxuto) – diversos princípios lean influenciam a cultura DevOps, como a melhoria contínua, o foco em qualidade, a eliminiação de desperdícios, a otimização do todo e o respeito às pessoas;
  • (M)edição – se você não souber medir, não saberá avaliar se está melhorando ou piorando. Uma adoção de DevOps de sucesso irá medir tudo o que for possível, por exemplo: métricas de desempenho, métricas de processo, métricas de negócio etc;
  • (S)haring (compartilhamento) – a colaboração e o compartilhamento de ideias e conhecimento ajudam a criar a cultura necessária para o sucesso com DevOps.

FOCO

  • Provisionamento – Provisionar ambientes de infraestrutura como código significa de forma automática e escalável;
  • Monitoria– Utilização e construção de ferramentas para monitoria do ambiente;
  • Automação – Criação de pipeline CI/CD de produtos e ambientes.

PROBLEMA







O problema cosutma ser aumento de deploys, o que aumenta a quantidade de mudanças e por consequência acabamos tendo mais processo o que tende a diminuir a frequência de deploys, ou seja, temos mais dificuldade em colocar em produção o que foi construído.

SOLUÇÃO

Aqui começa a ficar claro que quanto mais automação no processo você faz, mais fácil fica fazer deploy, logo seus deploys levam quantidades menores de alteração para produção e seu risco diminui. E tem mais, como a alteração é pequena se gerar algum erro, com o processo automatizado fazer um rollback é mais fácil, mais rápido e mais seguro.

STACK TECNOLÓGICO

Há uma gama vasta de sabores para o mundo de DevOps, porém eu segui essa linha.

DOCUMENTAÇÃO E GESTÃO

  • Slack – uma ferramenta (talvez até uma plataforma) de comunicação parecida com WhatsApp, porém com mais possibilidades, sendo permitido conectar a ela produtos como repositórios Git, Jenkins, Google Drive entre outros, é uma ferramenta para ter as comunições do time além das comunicações de deploys, merges e até mesmo alertas de produção.
  • Confluence – de forma muito simples e resumida, esse é um portal wiki, também é possível plugar aqui o Jira para ter reports relacionados ao andamento de suas sprints por exemplo, há série de templates nessa solução desde retrospectiva de sprint até visão de valores.
  • Jira – é um software comercial desenvolvido pela empresa Australiana Atlassian. É uma ferramenta que permite o monitoramento de tarefas e acompanhamento de projetos garantindo o gerenciamento de todas as suas atividades em único lugar.
  • BitBucket – Bitbucket é um serviço de hospedagem de projetos controlados através do Mercurial, um sistema de controle de versões distribuído. É similar ao GitHub.

CODIFICAÇÃO E CONSTRUÇÃO

  • Visual Studio Code – é um editor de código-fonte desenvolvido pela Microsoft para Windows, Linux e macOS. Ele inclui suporte para depuração, controle Git incorporado, realce de sintaxe, complementação inteligente de código, snippets e refatoração de código.
  • Aptana – é um software open source gratuito para IDE desenvolvido em Java que suporta as linguagens PHP, Python, Ruby, Ruby on Rails, CSS3, HTML5, JavaScript, ScriptDoc, XML e texto comum, embora também seja possível configurá-lo para suportar Adobe® AIR e Bibliotecas AJAX.
  • Vue.js – é um framework JavaScript de código-aberto, focado no desenvolvimento de interfaces de usuário e aplicativos de página única.
  • Angular – uma plataforma de aplicações web de código-fonte aberto e front-end baseado em TypeScript liderado pela Equipe Angular do Google e por uma comunidade de indivíduos e corporações. Angular é uma reescrita completa do AngularJS, feito pela mesma equipe que o construiu.
  • .Net Core – framework livre e de código aberto para os sistemas operacionais Windows, Linux e macOS. É um sucessor de código aberto do .NET Framework. O projeto é desenvolvido principalmente pela Microsoft e lançado com a Licença MIT.
  • Node.js – um interpretador de JavaScript assíncrono com código aberto orientado a eventos, criado por Ryan Dahl em 2009, focado em migrar a programação do Javascript do cliente (frontend) para os servidores, criando aplicações de alta escalabilidade (como um servidor web), manipulando milhares de conexões/eventos simultâneas em tempo real numa única máquina física.
  • MongoDB – banco de dados orientado a documentos livre, de código aberto e multiplataforma, escrito na linguagem C++. Classificado como um programa de banco de dados NoSQL, o MongoDB usa documentos semelhantes a JSON com esquemas.
  • Redis – base de dados em rede open-source, que armazena chaves com durabilidade opcional, patrocinado pela Pivotal Software e pela VMware, a partir de 2015 mudou para a Redis Labs. De acordo com o ranking mensal da DB-Engines.com, Redis é o banco de dados de valores-chave mais popular do mundo

INTEGRAÇÃO CONTÍNUA E ENTREGA CONTÍNUA

  • Jenkins – Jenkins é um servidor de automação gratuito e de código aberto. Ajuda a automatizar as partes do desenvolvimento de software relacionadas à construção, teste e implantação, facilitando a integração contínua e a entrega contínua.
  • Ansible – uma ferramenta de código aberto de provisionamento, gerenciamento de configurações e implantação de aplicativos. É executado em muitos sistemas tipo Unix e pode configurar sistemas tipo Unix, bem como Microsoft Windows. Ela inclui sua própria linguagem declarativa para descrever a configuração do sistema.
  • Nexus – É um gerenciador de repositório de arquivos binários. Permite buscar, coletar e gerenciar suas dependências para que você não esteja constantemente manipulando suas dependências dentro de seus projetos. Facilita a distribuição do seu software. Internamente, você configura sua compilação para publicar artefatos no Nexus e eles ficam disponíveis para outros desenvolvedores

CONTAIENERS (RECIPIENTES?!)

  • Kubernetes – é um sistema de orquestração de contêineres open-source que automatiza a implantação, o dimensionamento e a gestão de aplicações em contêineres. Ele foi originalmente projetado pelo Google e agora é mantido pela Cloud Native Computing Foundation.
  • Docker – é um software contêiner da empresa Docker, Inc, que fornece uma camada de abstração e automação para virtualização de sistema operacional no Windows e no Linux, usando isolamento de recurso do núcleo do Linux como cgroups e espaços de nomes do núcleo, e um sistema de arquivos com recursos de união, como OverlayFS criando contêineres independentes para executar dentro de uma única instância do sistema operacional, evitando a sobrecarga de manter máquinas virtuais (VM).

TESTES

  • Selenium – Selenium é uma estrutura portátil para testar aplicativos da web. O Selenium fornece uma ferramenta de reprodução para a criação de testes funcionais sem a necessidade de aprender uma linguagem de script de teste.
  • Sonarqube – plataforma de código aberto desenvolvida pela SonarSource para inspeção contínua da qualidade do código, para executar revisões automáticas com análise estática do código para detectar bugs, odores de código e vulnerabilidades de segurança em mais de 20 linguagens de programação.
  • BrowserStack – é uma plataforma de teste móvel e na nuvem que permite que os desenvolvedores testem seus sites e aplicativos móveis em navegadores sob demanda, sistemas operacionais e dispositivos móveis reais, sem exigir que os usuários instalem ou mantenham um laboratório interno de máquinas, dispositivos ou emuladores virtuais.
  • JMeter – é uma ferramenta que realiza testes de carga e de estresse em recursos estáticos ou dinâmicos oferecidos por sistemas computacionais. Além disso, é parte do projeto Jakarta, da Apache Software Foundation.
  • Postman – uma ferramenta com a função de testar e desenvolver APIs em uma interface bastante simples e intuitiva. Ele nos permite simular requisições HTTP de forma rápida, armazenando-as para que possamos usá-las posteriormente.

MONITORIA E LOG

  • Elasticsearch – um servidor de buscas distribuído baseado no Apache Lucene. Foi desenvolvido por Shay Banon e disponibilizado sobre os termos Apache License. ElasticSearch foi desenvolvido em Java e possui código aberto liberado sob os termos da Licença Apache.
  • Fluentd – é um coletor de dados open source que permite unificar a coleta e o consumo para melhorar o uso e compreensão dos dados. O maior usuário da ferramenta atualmente coleta logs de mais de 5.000 servidores e 5TB de dados diários, movimentando 50.000 mensagens por segundo no horário de pico. Sim, a principal razão para usá-lo é o desempenho.
  • Kibana – é um plugin de visualização de dados de fonte aberta para o Elasticsearch. Ele fornece recursos de visualização em cima do conteúdo indexado em um cluster Elasticsearch. Os usuários podem criar gráficos de barra, linha e dispersão, ou gráficos e mapas de torta em cima de grandes volumes de dados.
  • Grafana – O Grafana é uma solução de código aberto de várias plataformas para executar análises de dados, extrair métricas que compreendem a enorme quantidade de dados e monitorar aplicativos por meio de painéis personalizáveis.
  • Prometheus – é um aplicativo de software gratuito usado para monitoramento e alerta de eventos. Ele grava métricas em tempo real em um banco de dados de séries temporais criado usando um modelo de recepção HTTP, com consultas flexíveis e alertas em tempo real.

OPERAÇÃO

Em uma visão de governança a operação ficará mais ou menos assim:

  • Toda comiunicação sempre é feita pelo Slack;
  • Todo planejamento está no Jira e toda documentação está no Confluence;
  • Toda condificação está nas IDE’s e já aqui os desenvolvedores podem versionar suas imagens, com ou sem utilização de pipeline;
  • A qualidade de código está no Sonarqube;
  • O Jenkins faz a orquestração entre todos os sistemas após o commit/push no repositório
  • Através dos scripts Ansible podemos subir novas máquinas e já deixá-las configuradas por lá;
  • O Docker participa o tempo do processo de deploym uma vez que baixamos as imagens do Nexus e fazmos o deploy das mesmas através de um container Docker dentro do cluster Kubernetes;
  • As ferramentas de teste podem ser executadas em qualquer ambiente e a qualquer momento.

CI/CD

Um dos processos que pode ser seguido é:

  • Um push feito pelo desenvolvedor, o código chegará no repositório;
  • Através de SCM Pool o Jenkins pode buscar o código alterado ou através de um Webhook feito pelo BitBucket o Jenkins faz um pull no repositório;
  • O code review é disparado pelo Jenkins para o Sonarqube, só passa para a etapa de build se estiver atendendo os requisitos mínimos de qualidade;
  • A etapa de build é feita no Jenkins (já com todos as dependências) e gera o pacote de binários do produto/sistema;
  • Uma imagem do pacote é feita ou seja é feito versionamento no Nexus;
  • O deploy do pacote é feito no ambiente previsto (dev, homolog, pré-prod, prod, beta etc.)
  • Testes funcionais automatizados são executados em cima do ambiente que o deploy foi executado. Testes de carga quando são automatizados geralmente não ficam no mesmo pipeline que o deploy, são feitos em momentos apartados;
  • Para cada etapa uma notificação deve ser feita, aqui no caso é no Slack.

MÉTRICAS

É possível ter uma série de métricas através plugins do Jenkins mesmo. Mas, acho que podemos começar essas aqui:

  • Frequência de deployment – Quantidade de deploys feitos por dia, semana, mês etc., com essa métrica é possível identificar:
    • se a equipe de tecnologia é responsiva às demandas por novos recursos nos produtos ou serviços;
    • se as equipes e ferramentas de desenvolvimento são eficientes;
    • se a equipe de tecnologia está apressando a entrega de produtos incompletos ou defeituosos (caso a frequência de deployment seja muito alta).
  • Duração do ciclo de vida do desenvolvimento – aqui vemos desde a ideação do produto, conffecção de códigos até chegar no deploy e entedemos:
    • se o processo de desenvolvimento é eficiente, complexo ou burocrático demais;
    • se as equipes desenvolvedoras são competentes;
    • se algumas etapas do desenvolvimento estão apresentando gargalos (caso o ciclo tenha uma duração muito longa).
  • Números de falhas e incidentes – Agilidade e velocidade no deploy trazem o benefício de acelerar o negócio e trazer para um momento mais próximo funcionalidades para a operação. Entretanto, se subir isso com falhas, é o mesmo que acelerar problemas, e por isso devem ser medidas e jamais devem sair do radar, pois essa métrica ajudará a medir:
    • a qualidade do processo de desenvolvimento, testes e levantamento de requisitos;
    • a qualidade dos produtos ou serviços entregues;
    • o grau de colaboração entre a QA, desenvolvimento e operações.
  • Tempo Médio Para Restauração de um Serviço – Se um microsserviço ou API cair, quanto tempo demoramos para resolver isso? A velocidade em resolver esse problema determinará o sucesso da cultura de DevOps na organização. Uma vez que o serviço de DevOps deve garantir monitoria do ambiente e estabilização do ambiente, com essa métrica iremos medir:
    • a produtividade e a eficiência das equipes DevOps, de modo geral;
    • a agilidade da empresa ao responder às mudanças, considerando as pessoas, os processos e as tecnologias envolvidos no desenvolvimento;
    • o grau de feedback entre os responsáveis pelo desenvolvimento, QA, operações, negócios e usuários finais.

PROCESSO PARA DELIVERY

O que estive fazendo nos últimos anos é basicamente um processo de sempre refinar o backlog como um todo, baseado nas necessidade dos times de desenvolvimento, infra-estrutura e segurança, após isso fazia um comitê de priorização com todos e depois partia para a execução, bem simples, bem direto e sem complexidades para gestão.

Além disso eu fazia uma comunicação do que tinha combinado de ser entregue após o planejamento e antes do comitê eu mandava o que tinha sido executado, por muitas vezes um item ou outro era trocado por alguma demanda mais importante, e até chegarmos a uma maturidade sobre as estimativas a gente errava para menos ou para mais as estimativas.

Acho que a parte mais importante aqui era comunicar a todos os envolvidos sobre as entregas, principalmente quando alguma entrega não seria feita.

PADRONIZAÇÃO PARA VERSIONAMENTO DE IMAGENS

NOMEDOPRODUTO-X.Y.Z
X – Major
Y – Minor
0 – Patch
Major – Todo projeto deve começar na versão zero (ex: 0.1.0), ou seja, ainda não temos uma API definida. A partir da primeira versão de API, podemos ter a versão 1.0.0 e qualquer alteração que quebre a API, mesmo que pequena, uma nova major version deve ser lançada.
Minor – Quando a versão minor é incrementada, significa que uma nova feature foi lançada.
Patch – Versões patch (ou de correção) são lançadas quando há correção de bugs ou mudanças de segurança que não quebram a API.

CONCLUSÃO

Foi muito importante conhecer a cultura dentro de DevOps, hoje em qualquer projeto que eu inicie que tem como entregável algum produto digital/tecnológico eu já coloco pelo menos esse conteúdo em pauta, uma vez que isso acelera de forma incrível as entregas. Mas, até mesmo antes de falarmos de entrega do produto, isso força na maioria dos casos a estruturação tecnológica do projeto, os times terão que já definir os frameworks para trabalho no começo da construção, os PO’s e PM’s terão que se preocupar em utilizar melhor o repositório de estória de usuário/requerimento e a Wiki disponível para comunicar da melhor forma o que deve ser feito.

Há coisas aqui que não abordei como a monitoria com EFK, por exemplo, ou a utilização de uma ferramenta como Dynatrace ou New Relic nessa frente, isso vai em linha com um assunto de NOC/Command Center, e não queria falar disso agora, queria mesmo falar da parte mais divertida que vejo no DevOps que é de fato prover infra e automaizar isso.

Referências
https://pt.wikipedia.org/wiki/DevOps
DevOps na prática: Entrega de software confiável e automatizada eBook Kindle https://amzn.to/2Xsy0Ky

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.