De maneira resumida, o DevOps é uma cultura que encoraja um desenvolvimento de software onde o principal objetivo é aprimorar a capacidade de distribuir em alta velocidade aplicativos e serviços.
Para alcançar esses objetivos, os times de desenvolvimento e de operações (Dev + Ops) trabalham juntos em cada fase da criação de aplicativos e softwares.
Por que precisamos de DevOps?
O serviço de TI se torna cada vez mais complexo devido a requisitos técnicos e de negócios sempre mais desafiadores.
Só que para implementar o DevOps e mudar para um local onde os benefícios fluem, você precisa pensar além da entrega técnica. Pois o problema é que, no mundo da TI, as coisas mudam mais rápido que você.
A exigência do mercado é muito mais intensa agora, e você não pode simplesmente dizer : “Estou cansado de mudar, me dê um tempo”.
Vamos pegar o exemplo da nuvem :
A nuvem nos permite implementar soluções complexas e resolver muitos desafios, só que em compensação requer mais habilidades técnicas e de negócios (habilidades inclusive que estão em alta demanda, e que geralmente são do domínio dos administradores de sistema).
Como hoje todas as partes da nuvem são vendidas como escaláveis, e sempre é necessário definir alguns processos DevOps. Isso significa que sempre precisa de algum esforço manual de profissionais atuando na área. Só que quando tem uma pessoa por trás da maior parte do processo, significa que você trabalha da maneira antiga.
Isso é o tipo de situação que demonstra que precisamos mais do que o DevOps.
O que o NoOps oferece?
A abordagem NoOps também tem o objetivo de melhorar a implantação, mas alcançaria isso aliviando os desenvolvedores de qualquer problema de infraestrutura e evitando perder tempo nas interações com os administradores do sistema (No + Ops).
Em 2013, já se falava sobre o NoOps que seria a evolução lógica do DevOps, por ser o nível de maturidade que a abordagem DevOps encoraja alcançar.
O modelo NoOps inclui o uso de técnicas de Integração Contínua, que permitem que os desenvolvedores se concentrem apenas no desenvolvimento de aplicativos.
Seguindo com o exemplo da nuvem:
Em vez de ter um administrador de sistema atuando manualmente para cuidar das configurações de parte escaláveis, poderia ter um arquivo no próprio código desenvolvido pelos devs que cuidaria de todas as configurações.
Assim, os desenvolvedores apenas escrevem o código, fazem as alterações por push e, através de sistemas adequados de construção, o aplicativo relacionado é produzido automaticamente, pronto para a implantação.
Dessa forma, a equipe de desenvolvimento não precisa mais se comunicar com os administradores de sistema e economizar tempo dedicado a problemas de infraestrutura. Podemos dizer que o NoOps representa um passo à frente na inovação e, graças às ferramentas adequadas, permite obter um processo de implantação mais rápido, ainda mais que o DevOps.
Em um mundo NoOps, os recursos estão disponíveis sob o comando dos devs, e tudo é automatizado. Assim, os desenvolvedores verificam suas entregas com base na própria definição de concluído (definition of done) e a qualidade é incorporada – em vez de colada.
Como realizar a transição de DevOps para NoOps?
Para conseguir essa transição para NoOps é preciso ter profissionais que consigam identificar quais são os pontos de gargalo que existem hoje nos fluxos de entrega de valor, e capazes de ajudar a reduzir-los.
→ Porque abrir tickets e ter uma burocracia gigantesca de aprovação envolvendo terceiros para operações simples como liberação de repositórios para novos integrantes do time?
→ Porque sempre acionar um administrador de sistema para criar e configurar novas plataformas se isso pode ser realizado pelo próprio desenvolvedor de maneira rápida, segura e protegida usando um script?
Precisamos ter esse mindset para garantir que os times, e em particular os desenvolvedores, possam ser verdadeiramente produtivos, simplificando os processos ao máximo, os ajudando a criar, testar, proteger e implantar o código em produção sem precisar gerenciar credenciais de segurança ou lidar com logs, monitoramento e conectividade a bancos de dados.
Como Ritchie ajuda nisso?
É pensando nessa melhoria da experiência do desenvolvedor que o novo produto da Zup, o Ritchie, foi criado.
Esse CLI, estruturado em “árvore de decisões”, busca simplificar tarefas repetitivas e de fácil execução que, em muitos casos, demandam muito do profissional em lembrar de todos os comandos, além de seus parâmetros e argumentos.
O Ritchie funciona como um repositório único de automações, chamadas de fórmulas. Enquanto outros CLI geralmente são focados em apenas operações relacionadas a uma aplicação, no Ritchie você encontra, em um só lugar, as operações relacionadas a todas as suas fórmulas cadastradas. Que sejam relacionadas a NoOps, DevOps, ou outros fins…
Por exemplo: os administradores de sistema poderiam configurar fórmulas associadas a um comando específico no CLI, que permitiriam aos desenvolvedores realizar operações que eram antes exclusivamente do domínio dos times de infraestrutura, tais como criar um pipeline de CI/CD, configurar ambientes, etc…
Quer saber mais sobre a ferramenta? Entenda tudo sobre o Ritchie aqui.
