Ferramentas do DevOps

Na fase Discover, uma equipe de DevOps pesquisa e define o escopo de um projeto. Em particular, envolve atividades como pesquisa de usuários, estabelecimento de metas e definição de sucesso.

Ferramentas como Mural e Miro capacitam toda a equipe de software a reunir ideias e conduzir pesquisas. O Jira Product Discovery organiza essas informações em entradas acionáveis e prioriza as ações das equipes de desenvolvimento. Ao priorizar, você também vai precisar manter em mente o backlog de feedback dos usuários.

O Product Discovery é a primeira atividade de design de um produto, que então se torna a linha de base para a tomada de decisões. Durante o Product Discovery, você pode coletar todas as informações cruciais sobre qualquer problema do usuário e, em seguida, oferecer soluções para eles.

Recomendamos procurar ferramentas que incentivem o “brainstorm assíncrono”. É importante que todos consigam compartilhar e comentar sobre qualquer coisa: ideias, estratégias, metas, requisitos, roteiros e documentação.

Usando os ensinamentos do manual ágil, recomendamos ferramentas que possibilitem que as equipes de desenvolvimento e operações dividam o trabalho em partes menores e gerenciáveis para implementações mais rápidas. Assim, você vai aprender com os usuários mais rápido, além de ajudar a otimizar um produto com base no feedback. Procure por ferramentas que ofereçam planejamento de sprint, rastreamento de problemas e permitam a colaboração, como o Jira.

Outra boa prática é coletar feedback de usuários continuamente, organizar essas informações em entradas acionáveis e priorizar essas ações com as equipes de desenvolvimento. Procure ferramentas que incentivem o “brainstorming assíncrono” (se preferir). É importante que todos consigam compartilhar e comentar sobre qualquer coisa: ideias, estratégias, metas, requisitos, roteiros e documentação.

E não se esqueça das integrações e dos sinalizadores de funções. Qualquer que seja o escopo de sua função ou projeto, ele deve ser transformado em histórias de usuários no backlog de desenvolvimento. Os sinalizadores de função são instruções SE na base de código que permitem que as equipes ativem e desativem funções.

Para saber mais sobre essa fase, confira esta publicação dos gerentes de produto da Atlassian sobre a revisão de tarefas e a priorização do backlog.

Ambientes idênticos à produção para o desenvolvimento

Embora o Puppet e o Chef beneficiem principalmente as operações, os desenvolvedores usam ferramentas de código aberto, como Kubernetes e Docker, para provisionar ambientes de desenvolvimento individuais. A codificação em réplicas de produção virtuais e descartáveis ajuda você a trabalhar com mais eficiência.

Quando cada membro da equipe trabalha em um ambiente com provisionamento idêntico, a frase “Funciona na minha máquina!” deixa de ser engraçada e passa a ser verdadeira (agora isso é engraçado).

Infraestrutura como código

Os desenvolvedores criam aplicativos modulares porque eles são mais confiáveis e a manutenção é mais fácil. Então, por que não estender esse pensamento à infraestrutura de TI? Pode ser difícil aplicar esse conceito aos sistemas porque eles estão sempre mudando. Contornamos isso usando código para o provisionamento.

Infraestrutura como código significa que o reprovisionamento é mais rápido do que o reparo — além de mais consistente e reproduzível. Também significa que você pode criar com facilidade variações do seu ambiente de desenvolvimento com uma configuração semelhante à produção. O código de provisionamento pode ser aplicado e reaplicado para colocar um servidor em uma linha de base conhecida. Ele pode ser armazenado no controle de versões. Além disso, pode ser testado, incorporado à CI (integração contínua) e revisado por pares.

Quando o conhecimento institucional é, digamos, codificado em um código, a necessidade de ter manuais de execução e documentações internas desaparece. O resultado são processos repetíveis e sistemas confiáveis.

Controle de origem e codificação colaborativa

É importante ter controle de origem do seu código. As ferramentas de controle de origem ajudam a armazenar o código em cadeias diferentes para que você possa ver cada alteração e colaborar com mais facilidade compartilhando essas alterações. Em vez de esperar pelos painéis de aprovação de mudanças antes de implementar na produção, você pode melhorar a qualidade e a taxa de transferência do código com revisões por pares feitas por pull requests.

E aí você pergunta: o que são pull requests? Os pull requests informam a equipe a respeito das alterações que você fez em uma ramificação de desenvolvimento no repositório. Assim, a equipe pode revisar as alterações propostas e discutir as modificações antes de integrá-las à linha de código principal. Os pull requests melhoram a qualidade do software, o que resulta em menos bugs/incidentes, reduzindo custos operacionais e promovendo um desenvolvimento mais rápido.

As ferramentas de controle de origem devem se integrar a outras ferramentas. Assim você pode conectar as diferentes partes do desenvolvimento e entrega do código. Assim, você consegue saber se o código da característica está sendo executada na produção. Se ocorrer um incidente, o código poderá ser recuperado para esclarecer o incidente.

A integração contínua é a prática de verificar o código em um repositório compartilhado várias vezes por dia e testá-lo todas as vezes. Dessa forma, é possível detectar problemas automaticamente e com antecedência, corrigi-los quando for mais fácil e implantar novas características para os usuários o quanto antes.

A revisão de código por pull requests exige ramificações e está em alta. A North Star de DevOps é um fluxo de trabalho que resulta em menos ramificações e mais rápidas, além de manter o rigor dos testes sem sacrificar a velocidade de desenvolvimento.

Procure por ferramentas que apliquem os testes nas ramificações de desenvolvimento de maneira automática, e que dão a opção de enviar por push para o principal quando as compilações de ramificação forem bem-sucedidas. Você também recebe feedback contínuo por meio de alertas de bate-papo em tempo real da sua equipe com uma integração simples.

Veja como o Bitbucket Pipelines ajuda você a automatizar o código do teste à produção.

Teste Automatizado

As ferramentas de teste abrangem muitas necessidades e recursos, como testes exploratórios, gerenciamento de testes e orquestração. No entanto, para a cadeia de ferramentas de DevOps, a automação é uma função essencial. A automatização dos testes compensa com o tempo, pois acelera os ciclos de desenvolvimento e testes a longo prazo. E, em um ambiente de DevOps, ela é importante por outro motivo: ganhar visibilidade.

A automação de testes pode aumentar a qualidade do software e reduzir os riscos, ao testar com antecedência e frequência. As equipes de desenvolvimento podem executar testes automatizados repetidas vezes, abrangendo várias áreas, como testes de IU, verificação de segurança ou teste de carga. Elas também geram relatórios e gráficos de tendências, que ajudam a identificar áreas de risco.

O risco é uma realidade no desenvolvimento de software, mas você não consegue mitigar o que não é capaz de prever. Faça um favor à sua equipe de operações e deixe que eles vejam os bastidores com você. Procure por ferramentas compatíveis com murais e deixe que todos os envolvidos no projeto comentem sobre resultados específicos da compilação ou implementação. Ferramentas que facilitam o envolvimento das Operações em testes blitz e testes exploratórios ganham mais pontos.

Painéis de implementações

Uma das partes mais estressantes do lançamento de um software é colocar todas as informações de alterações, testes e implementação de uma nova versão em um só lugar. A última coisa que alguém precisa antes de um lançamento é uma longa reunião para relatar o status. É aqui que entram os painéis de lançamento.

Procure por ferramentas com um único painel integrado ao repositório de código e às ferramentas de implementação. Encontre algo que ofereça visibilidade total sobre ramificações, builds, pull requests e avisos de implementação em um só lugar.

Implementação automatizada

Não existe uma receita mágica para a implementação automatizada que funcione para todos os aplicativos e ambientes de TI. No entanto, converter o runbook de operações em um script cmd executável usando Ruby ou bash é um modo comum de começar. Boas práticas de engenharia são fundamentais. Use variáveis para fatorar nomes de host. Manter scripts ou códigos exclusivos para cada ambiente não é divertido (e perde metade do sentido, na verdade). Crie métodos ou scripts utilitários para evitar códigos duplicados. E use a revisão por pares dos scripts para verificá-los.

Tente automatizar as implementações do ambiente de nível mais baixo primeiro, onde você vai usar essa automação com mais frequência, e depois replique até a produção. No mínimo, este exercício destaca as diferenças entre seus ambientes e gera uma lista de tarefas para padronizá-los. Como bônus, a padronização de implementações com a automação reduz o “desvio do servidor” dentro e entre os ambientes.

Rastreamento de incidentes, alterações e problemas

A chave para liberar a colaboração entre as equipes de DevOps é garantir que elas visualizem o mesmo trabalho. O que acontece quando os incidentes são relatados? Eles estão vinculados a problemas de software e podem ser rastreados? Quando as alterações são feitas, elas são vinculadas às versões?

Nada prejudica mais a colaboração entre "Dev" e "Ops" do que ter incidentes e projetos de desenvolvimento de software monitorados em sistemas diferentes. Procure por ferramentas que mantenham incidentes, alterações, problemas e projetos de software em uma única plataforma para que você possa identificar e corrigir problemas mais rápido.

Monitoramento do desempenho de aplicativos e servidores

Existem dois tipos de monitoramento que devem ser automatizados: o monitoramento de servidores e o monitoramento do desempenho dos aplicativos.

“Encerrar” manualmente uma caixa ou acertar a API com um teste servem para verificações pontuais. Mas, para entender as tendências e a integridade geral do seu aplicativo (e ambientes), você precisa de um software que capte e registre dados 24 horas por dia, 7 dias por semana. A observabilidade contínua é um recurso fundamental para equipes de DevOps bem-sucedidas.

Procure por ferramentas que se integrem ao seu cliente de bate-papo em grupo, de modo que os alertas sigam direto para a sala da sua equipe ou para uma sala dedicada a incidentes.

Os clientes já estão dizendo se você criou a coisa certa – basta ouvir. O feedback contínuo inclui a cultura e os processos para coletar feedback regularmente, além das ferramentas para gerar insights a partir dessas informações. Entre as práticas de feedback contínuo estão coleta e revisão de dados de NPS, pesquisas de rotatividade, relatórios de bugs, tickets de suporte e até mesmo tweets. Em uma cultura de DevOps, todos da equipe do produto têm acesso aos comentários dos usuários, porque eles ajudam a orientar tudo o que é feito, desde o planejamento de lançamentos até as sessões de testes exploratórios.

Procure por aplicativos que integrem a ferramenta de bate-papo à sua plataforma de pesquisa favorita para obter feedback ao estilo de NPS. O Twitter e/ou o Facebook também podem ser integrados ao bate-papo para receber feedback em tempo real. Para uma análise mais aprofundada do feedback recebido nas redes sociais, vale a pena investir em uma plataforma de gerenciamento de mídias sociais que extraia relatórios usando dados históricos.

Pode parecer que a análise e a incorporação de feedback diminuem o ritmo do desenvolvimento em curto prazo, mas o processo é mais eficiente em longo prazo do que lançar novas características que ninguém quer.

Na Atlassian, acreditamos na importância de ter uma cadeia de ferramentas de DevOps que se integre às ferramentas que as equipes de desenvolvimento e operações adoram usar. É por esse fato que criamos a plataforma de DevOps para se integrar a mais de 171 grandes fornecedores terceirizados, capacitando você a tomar as melhores decisões entre as ferramentas que usa. Porque o DevOps não deve ser comprado de um único fornecedor, e sim, construído.

Para começar, experimente a solução de DevOps da Atlassian sem custos.