• (31) 99973-2709
  • hugomoraismendes@gmail.com

Category Archive DevOps

Simian Army (Exército Símio)

Simian Army (Exército Símio) é um conjunto de ferramentas e técnicas criadas pela Netflix analisar/testar a disponibilidade de um serviço/ferramenta mesmo em situações caóticas assim descobrindo se o sistema tem tolerância a falhas. Uma vez que nenhum componente pode garantir 100% de tempo de atividade. Logo a netflix projetou uma arquitetura em nuvem onde componentes individuais podem falhar sem afetar a disponibilidade de todo o sistema.

O nome dado a essa técnica é bem interessante, imagine um macaco selvagem com uma arma solto em um datacenter. Pense no potencial destrutivo.

Veja abaixo os integrantes do Simian Army:

Chaos Monkey, uma ferramenta que desativa aleatoriamente as instâncias de produção para garantir que o serviço continue a funcionar sem qualquer impacto no cliente.

Latency Monkey, propositalmente aumenta a latência em respostas dos serviços REST possibilitando testar a recuperação à indisponibilidade dos serviços, assim acaba simulando a degradação dos serviços e mede se os serviços upstream respondem adequadamente.

Conformity Monkey, encontra instâncias que não seguem as práticas recomendadas e as desliga. Por exemplo, se encontrar instâncias que não pertencem a um grupo de escalonamento automático, é um problema esperando para acontecer, logo essa máquina é desligada para ser feito a correção.

Doctor Monkey, utiliza verificações de integridade que são executadas em cada instância, bem como monitora outros sinais externos de integridade (carga de memoria, CPU) para detectar instâncias não íntegras. Depois que as instâncias não íntegras são detectadas, elas são removidas do serviço para serem adequadas.

Janitor Monkey, garante que nosso ambiente de nuvem esteja funcionando sem bagunça e desperdício. Ele procura recursos não utilizados e os desliga.

Security Monkey, é uma extensão do Conformity Monkey. Ele encontra falhas de segurança ou vulnerabilidades, como grupos de segurança configurados incorretamente e encerra as instâncias. Ele também garante que todos os nossos certificados SSL e DRM estejam válidos e não estejam próximos do vencimento.

10–18 Monkey, detecta problemas de configuração e tempo de execução em instâncias atendendo clientes em várias regiões geográficas, usando diferentes idiomas e conjuntos de caracteres.

Chaos Gorilla, é uma evolução do Chaos Monkey que, pois dentro de uma região, desabilita zonas para verificar se o sistema continua funcionando sem impacto para o usuário.

Chaos Gorilla, é semelhante ao Chaos Monkey, mas simula uma interrupção região inteira da AWS. Para verificar se os serviços se reequilibram automaticamente para as zonas de disponibilidade funcionais, sem impacto visível ao usuário ou intervenção manual.

Retrospectiva Ágil

A reunião de retrospectiva tem como forma inspecionar e adaptar, seja realizada em projetos ágeis ou cascata, sendo o seu principal objetivo levantar o que funcionou e o que deu erro durante a etapa de entrega, assim juntos estudando uma melhor forma de melhorar a execução na próxima entrega.

A reunião de retrospectiva deve ser realizada sempre que houver necessidade, é interessante que ocorra também a cada entrega que pode ser semanal, quinzenal ou mensal. Levante todos os fatos que aconteceram e tirem ações de melhoria para o próximo ciclo. Com o passar dos meses, os integrantes do time vão se conhecendo e trabalhando de forma mais integrada e menos reativa

As reuniões de retrospectivas podem ser conduzidas de uma forma simples, seguindo a perguntas da imagem abaixo, podendo utilizar post its, quadros, flips charts, canetas. A reunião deve ser realizada em locais que as pessoas se sentem a vontade para debater.

Fonte: https://annelisegripp.com.br/retrospectivas-ageis/

Abaixo segue algumas dicas de técnicas que podem ser utilizadas.

Técnica do M&M

Cada pessoa pega um confeite do pacote. Cada cor de um confete deve ser relacionado a uma parte processo de trabalho, como: sprint (amarelo), daily (vermelho), review (marrom), etc… A cor que a pessoa sortear vai ser o assunto que ela vai falar, o que foi legal e o que precisa melhorar.

TÉCNICA PDCA

  • O que precisamos começar?
  • O que podemos continuar?
  • O que precisamos melhorar?
  • O que temos que parar?

TÉCNICA STARFISH

  • O que precisamos manter (keep doing)?
  • O que precisamos parar de fazer (stop doing)?
  • O que precisamos começar a fazer (start doing)?

TÉCNICA LEARNNING MATRIX

  • O que foi bom?
  • O que devemos parar de fazer?
  • Novas ideias, formas de trabalhar
  • Boas ações durante o ciclo

TÉCNICA HOT AIR BALLON

Olhando para trás – o fogo e o ar quente: O que nos ajuda a ir mais alto – Quais são as coisas que nos empurram para a frente?

Olhando para trás – forças puxando para baixo: Quais são as forças que nos puxam para baixo?

Olhando para o futuro – tempestade: Qual é a tempestade pela frente? O que terá o nosso turbulenta viagem?

Olhando para o futuro – sol: O que poderíamos fazer para evitar a tempestade e virar-se para dias de sol? O que vamos fazer para superar os possíveis desafios à nossa frente?

TÉCNICA DO PAPEL PICADO

Pegue uma folha em branco e escreva as palavras, dando espaço entre elas para depois cortar a folha, que falam sobre o processo. Tipo: PLANNING, REVIEW, RETROSPECTIVA, DAILY, GROOMING, USER STORY, SCRUM MASTER, PRODUCT OWNER, ENTREGA, QUALIDADE DE CÓDIGO… entre outros que você achar importante. Corte cada palavra dessa, dobre e embaralhe. Cada membro do time vai sortear um papel, vai ler e falar um ponto positivo e um ponto a melhorar daquela palavra. Depois se tiver mais alguém que queira complementar, pode abrir para discussão. Isso vai sendo feito até o último papel para sorteio.

TÉCNICA “VAMOS TRANSFORMAR”

Essa técnica utilizamos para refletir sobre como podemos melhorar a nossa atuação dentro da empresa com intuito de transformar o ambiente que trabalhamos. As perguntas são simples, mas muito importantes para sabermos onde e quando agir. Basta fazer as perguntas e pra cada pergunta, pedir o pessoal para colocar respostas nos post its e debatermos sobre as soluções propostas. Seguem as perguntas : “O que está fora do nosso alcance?”, ou seja, não vale focar nesse momento, pois não teremos força e nem braço para agir. “O que podemos fazer para influenciar?”, ações que podem ser feitas para influenciar pessoas, ambientes, cenários. “O que depende de nós?”, é nossa área, nos dividimos para agir, podemos e devemos fazer para promover mudanças.

Praticas Avançadas de DevOps

Alguns times ágeis já tem práticas básicas implementadas dentro de algumas disciplinas DevOps. Ou outros times podem ter necessidades muito específicas dentro do mundo DevOps, que poderiam ser classificadas como avançadas. Neste contexto, compilo aqui 12 práticas DevOps avançadas de grande auxílio para diversos tipos de times que estejam buscando melhoria contínua de sua maturidade.

1. Testes de Carga

Em aplicações Web, podem haver variações abruptas no perfil de carga da aplicação em produção. Isso se deve a natureza estocástica no comportamento de requisições Web e a natureza do protocolo HTTP. Não é incomum que picos aconteçam e gerem 10x mais carga de trabalho que o uso médio da aplicação. Os sintomas comuns nas aplicações de mercado são longos tempos de resposta e até mesmo indisponibilidade do servidor Web (erros 5xx).

Estes sintomas podem ser minimizados com o uso de testes de carga em aplicações Web. O teste de carga é uma prática que permite gerar uma carga controlada para uma aplicação em um ambiente de testes específico ou homologação e assim estabelecer se um determinado build é robusto e pode ser promovido para ambientes de produção.

2. Testes de Estresse

O teste de estresse é um tipo de teste de carga onde queremos criar fraturas em uma aplicação dentro de um ambiente com parâmetros de hardware previamente estabelecidos. Ele consiste em aumentarmos gradativamente a carga em uma aplicação para saber qual será o primeiro componente a falhar por sobrecarga (ex. Banco de dados, servidor Web ou fila de mensagem). Esta técnica permite que o time de operações possa priorizar a sua atenção em infraestruturas complexas. Ela também permite aos times de desenvolvimento estabelecer os limites de uso da sua aplicação para os seus clientes.

3. Integração Contínua (Continuous Integration)

Depois que a automação dos builds acontece, ela pode ser programada para ser executada em base diária ou até mesmos várias vezes por dia. Quando esta maturidade for alcançada, podemos avançar para que ela seja executada continuamente, i.e., toda vez que um um commit acontecer em um código fonte.

É esperado que esta prática faça pelo menos o seguinte conjunto de passos:

  • promova a recompilação do código fonte do projeto;
  • execute as suites de teste de unidade automatizados do projeto;
  • gere o build do produto;
  • crie um novo rótulo para o build;
  • gere defeitos automatizados para o time se o build falhou por algum motivo.

A prática da integração continua promove as seguintes vantagens:

  • detectar erros no momento que os mesmos acontecem;
  • buscar um ambiente de gestão de configuração minimamente estável de forma continuada;
  • estabelecer uma mudança cultural no paradigma de desenvolvimento, através de feedbacks contínuos para o time de desenvolvimento da estabilidade do build.

4. Implantação Contínua (Continuous Deployment)

Depois que um processo mínimo de integração e implanatção estiver em curso, podemos avançar também para um processo contínuo de implantação nos ambientes intermediários (testes ou homologação). Este processo pode ser controlado por uma ferramenta e normalmente é ativado quando um novo build foi gerado pela ferramenta de automação de builds.

Em linhas gerais, a prática da implantação contínua garante que mesmo conjunto de bits do build é replicado no ambiente do desenvolvedor para ambientes controlados de desenvolvimento e homologação, garantindo a consistência do build em outros ambientes.

Em ambientes rigidamente governados onde existam processos ITIL, DBAs e times independentes de QA, naturalmente irão haver ciclo de pré-aprovações ou pós-aprovações para que as promoções de ambiente ocorram. O fato importante a notar na cultura DevOps é que o ser humano envolvido não copia arquivos ou parametriza aplicações. Ele examina a requisição, o build, parâmetros e as suas evidências de teste. Ao aprovar a solicitação de promoção, um robô irá fazer a movimentação dos builds e a parametrização apropriada da aplicação. Se ele não autorizar a promoção, um defeito é aberto para o solicitante no canal apropriado.

5. Entrega Contínua (Continuous Delivery)

Em termos simples, a entrega continua é o processo de implantação contínua em ambiente de produção. Ela é normalmente ativada por uma ferramenta automatizada quando um novo build for publicado com sucesso no ambiente de homologação. A entrega contínua normalmente envolve:

  • a requisição de aprovação de implantação para o responsável pelo ambiente de produção;
  • a cópia dos arquivos do ambiente de homologação para o ambiente de produção;
  • a verificação do estado da aplicação disponibilizada em produção.

Observe que a entrega contínua não significa que o ambiente de produção é modificado a todo instante. Apenas empresas de serviços de Internet podem e devem fazer isso. A entrega contínua implica que o ambiente de produção pode ser alterado se um novo build estiver disponível e as aprovações necessárias foram dadas para a promoção do build.

A entrega contínua envolve tipicamente a execução de smoke tests, que são testes de sanidade da aplicação. Estes testes verificam minimamente a estabilidade do build colocado em produção e testam cenários funcionais mínimos.

6. Integração Contínua, Implantação Contínua e Entrega Contínua – Entenda as diferenças

integração continua (Continuous Integration) é o processo de compilar o código em ambiente limpo, rodar testes e outros processos de qualidade e gerar um build, disparado por qualquer modificação no código fonte.

Já a implantação continua (Continuos Deployment) é o processo de promover o build gerado no processo de integração para ambientes intermediários como QA ou homologação.

Finalmente, a entrega continua (Continuous Delivery) é o processo de implantação continua que busca promover os builds para o ambiente de produção.

7. Testes Canários (ou Testes A/B)

Os testes canários são práticas úteis para empresas que praticam a entrega contínua e querem minimizar efeitos colaterais de novas funcionalidades na comunidade de usuários.

Quando um novo produto é colocado em produção pela automação dos releases, pode haver um risco de negócio em liberar as novas funcionalidades para toda a sua comunidade de usuários. Talvez seja necessário fazer um certo experimento de negócio para saber se aquela funcionalidade será realmente útil e se será mantida ou removida do produto.

Estes experimentos controlados, especialmente úteis em startups, podem ser ativados com os testes canários. O termo é devido a uma prática que ocorria nas minerações na Europa há alguns séculos. Mineiros levavam canários em gaiolas para novos veios em suas minas. Eles começam a trabalhar e deixavam os canários perto deles ao longo do dia de trabalho. Se um canário morresse depois de um tempo pequeno naquele ambiente, era porque o ambiente não estava saudável para a atividade humana devido a gases tóxicos. Na cultura DevOps da TI, o teste canário consiste em habilitar novas funcionalidades apenas para um grupo controlado de usuários (os canários). Ou seja, em ambiente de produção a aplicação opera de duas formas distintas para duas comunidades (A/B). Isso pode ser implementado através do padrão de desenho chamado Feature Toogles[1] e permite estabelecer uma prática chamada HDD (Hypothesis Driven Development). Se os canários não gostam do ambiente, a funcionalidade pode ser removida facilmente do produto em ambiente de produção sem intervenção no código fonte.

8. Infraestrutura como Código (IAC)

Times de baixa performance DevOps ainda possuem processos manuais e morosos de acionamento entre desenvolvimento e operações. Um exemplo prático é a criação de uma nova máquina feita do time de desenvolvimento para o time de ops. Em muitas empresas, este tipo de requisição demora horas, dias ou até mesmo semanas para ser realizada.

Quando times alcançam boa maturidade na configuração de elementos como scripts, elas podem avançar e tratar até o mesmo o hardware como código. Através de tecnologias disseminadas nos últimos anos em ambientes Linux, Windows e OS/X, é possível configurar os processos de automaçao de build e automação de releases para criar uma máquina virtual através de um código de script. A infraestrutura como código é prática essencial para aproximar devs e ops, pois ela permite estabelecer para o time de operações confiabilidade apropriada para as novas implantações realizadas em ambientes de produção.

A infraestrutura como código traz ainda como grande benefício estabelecer um protocolo comum entre os times de desenvolvimento e o time de operações. Esta prática elimina a necessidade da criação manual de ambientes físicos, que é moroso, propenso a erros e que causa muito atrito entre times. Ao automatizar esse processo, podemos reduzir brutalmente o tempo de ciclo para entrega de aplicações em produção. A tecnologia do Docker[2] é um excelente exemplo neste sentido.

Através de ferramentas utilitárias como o Power Shell DSC no Windows, Puppet, Chef, entre outras, arquivos de scripts que especificam configurações de máquinas podem ser compilados e então implantados em plataformas de nuvens como a Microsoft Azure ou Amazon EC2. A implantação deste arquivo cria, dinamicamente, uma máquina virtual com a exata especificação informada. Ou seja,  o trabalho de criação manual de uma máquina virtual e sua tediosa configuração é eliminado. Ao invés, criamos e testamos um script em alguma linguagem e o ambiente subjacente se encarrega de fazer o provisionamento das máquinas virtuais no ambiente de produção.

Até alguns anos atrás, somente era possível pensar no IAC se usássemos ambientes de nuvens públicas. Mais recentemente, isso é também possível com tecnologias similares em nuvens privadas com Linux e Windows. Tecnologias como o Pivotal Cloud Foundry e o IBM Bluemix, entre outras, tornaram possíveis fazer IAC em nuvens privadas.

9. Ambientes Self-Service

Em muitas empresas, é comum que um novato demore horas ou até dias para que consiga estabelecer um novo ambiente de trabalho. Isso é devido ao conjunto de passos manuais necessários, falta de procedimentos operacionais e dificuldades implíticas a montagem de ambientes Java EE ou .NET.

A prática de ambientes self-service permite que através de um código de script todo um ambiente de trabalho seja baixado, criado e disponibilizado para habilitar um desenvolvedor no seu trabalho em poucos minutos. Dado que um desenvolvedor tenha uma estação de trabalho com excelente memória RAM e uma rede veloz, é possível operacionalizar esta prática e salvar tempo precioso como o estabelecimento de ambientes de trabalho com confiabilidade e robustez. O Docker, em particular, é uma tecnologia que ganhou popularidade nos últimos anos para apoiar também esta prática.

10. Injeção de Falhas

Uma prática avançada DevOps é injetar defeitos no ambiente de produção de forma explícita. Por exemplo, podemos deliberadamente desligar o acesso ao banco de dados ou outros recursos críticos e forçar a aplicação a falhar. Isso pode parecer bizarro para alguns ou um contrassenso para outros. Mas pode fazer todo o sentido quando estamos buscando ambientes de alta disponibilidade e confiabilidade. Através do uso de procedimentos controlados de desestabilização da aplicação, podemos verificar como a aplicação se recupera de uma falha em ambiente de produção. Algumas perguntas que o time de operações poderia investigar incluem:

  • Ela se recupera automaticamente e retorna para o estado original antes da falha?
  • Ela emite alarmes apropriados para as partes interessadas?
  • Ela fornece mensagens simples e explicativas para os usuários finais?

Esta prática começou a ganhar momento na TI depois que a Netflix publicou o uso desta prática nos seus ambientes de produção e a disponibilização da sua ferramenta de injeção de falhas chamada Simian Army[4]. Conceitualmente, esta prática permite estabelecer um mecanismo de antifragilidade[5] na sua aplicação, tornando-a melhor ao longo do tempo à medida que ela seja estressada.

11. Telemetria

A telemetria é uma forma avançada de monitoração de aplicações em ambiente de produção. Ela permite conhecer mais profundamente os padrões de uso de uma aplicação, variações de carga, acesso, entre outras questões. A Telemetria conta também com um mecanismo intrínseco de capacidade de análise de uso (analytics) que permite aos times conhecer os padrões de acesso e assim evoluir o produto tecnicamente e também do ponto de vista de negócio com mais sabedoria.

12. Planejamento de Capacidade

O planejamento de capacidade envolve o uso de técnicas estatísticas e teoria de filas para conhecer, modelar e simular a carga de trabalho em aplicações e assim estabelecer o hardware mais apropriado para rodar uma aplicação, bem como ter ciência dos limites e potenciais problemas de operação.

Esta técnica pode ser implementada por ferramentas de testes de carga e performance e são especialmente úteis para empresas que trabalhem com cenários desafiantes de cargas de trabalho e busquem o uso de computação elástica em ambientes de nuvens.

[1] http://martinfowler.com/articles/feature-toggles.html

[2] http://docker.com

[3] https://www.infoq.com/br/news/2012/08/netflix-chaos-monkey

[4] https://github.com/Netflix/SimianArmy

[5] A fragilidade significa que algo quebra sob algum estresse, como por exemplo um copo fino solto de certa altura. Já a robustez indica que algo resiste a um estresse sem alterar o seu estado. Mas a antifragilidade vai muito além da robustez e resiliência. Um organismo antifrágil melhora o seu estado depois de submetido a um estresse. Por exemplo, exercícios físicos, até um certo nível, geram estresses em pessoas e a resposta do corpo delas é se tornar melhor com uma melhor densidade óssea e maior massa muscular. A antifragilidade é o oposto matemático da fragilidade. Enquanto a fragilidade é denotada como um número negativo -X, a robustez seria denotada como o número 0 e a antifragilidade seria denotada como um número positivo X. Este conceito é apresentado e discutido no livro AntiFrágil – Coisas que se beneficiam com o caos, de Nicholas Taleb, publicado em 2012.

Práticas Básicas de DevOps

Não existe uma lista definitiva sobre práticas técnicas de DevOps, por isso estou propondo uma proponho aqui uma lista de práticas básicas para a implantação desta cultura. A lista abaixo não possui uma ordem de prioridade, pois depende da realidade de cada organização e da cultura já instalada nos seus times de desenvolvimento, qualidade e operações.

As práticas DevOps buscam endereçar as melhorias em atributos de qualidade tais como a manutenibilidade, testabilidade, implantabilidade e recuperabilidade. Com estas práticas implementadas, teremos maior garantia que minimizaremos o débito técnico dos produtos de software sendo construídos e aceleraremos a entrega para produção dos produtos.

1. Comunicação Técnica Automatizada

A cultura DevOps busca aproximar pessoas dos times de desenvolvimento, qualidade e operações. E essa aproximação pode ser facilitada com ferramentas de comunicação que aliam o melhor da mensagem instantânea e canais de times com alarmes técnicos automatizados. Por exemplo, ferramentas como o Slack ou HipChat permitem que times com pessoas de desenvolvimento, qualidade e operações possam:

  • estabelecer conversas texto, áudio e vídeo em canais privativos e focados;
  • receber notificações de ferramentas tais como a disponibilização de builds, aprovação de releases ou problemas em produção;
  • disparar comandos através de bots para a abertura de defeitos, escalonamento de builds ou releases.

2. Qualidade contínua do código

Em muitas empresas, é muito fácil que uma arquitetura definida pelo time de arquitetura seja continuamente violada pelo time de desenvolvimento. O arquiteto normalmente não tem tempo e dedicação para “vigiar” o código fonte e realizar a aderência arquitetural do código ou observar o uso de práticas apropriadas de codificação. O efeito é que a arquitetura executável colocada em produção é muito diferente da arquitetura imaginada pelo arquiteto.

No sentido de minimizar esta lacuna, esta primeira prática lida com a automação da verificação da qualidade de código por ferramentas. Existem atualmente ferramentas sólidas que permitem avaliar o uso das melhores práticas de programação no seu ambiente (Code Metrics Tools) e avaliar a aderência do seu código a uma arquitetura de referência (Architectural Analysis Tools). E essas ferramentas podem ser programadas para rodar a noite ou até mesmo durante o momento do checkin do código pelo desenvolvedor. Existem ainda ferramentas que facilitam o processo de revisão por pares dos códigos fontes (Code Reviews), estabelecendo workflows automatizados e trilhas de auditoria. O recurso de Pull Requests do Git é um exemplo deste mecanismo.

Com esta prática, temos robôs que atuam continuamente para facilitar a análise do código fonte, educar desenvolvedores e estabilizar ou mesmo reduzir o débito técnico instalado.

3. Configuração como Código

Em muitos times, é comum que desenvolvedores façam muitas tarefas manualmente. Exemplos incluem cópias de arquivos entre ambientes, configuração destes ambientes, configuração de senhas, geração de release notes ou a parametrização de aplicações. Esses trabalhos manuais são propensos a erros e podem consumir tempo valioso do seu time com tarefas braçais.

Times atentos devem observar quando algum tipo de trabalho manual e repetitivo começa a acontecer e buscar automatizar isso. A automação da configuração através da escrita de códigos de scripts é um instrumento DevOps importante para acelerar o trabalho de times de desenvolvimento, reduzir erros e garantir consistência do trabalho.

No mundo DevOps, tudo é código!

4. Gestão dos Builds

A gestão de builds (ou Build Management) é prática essencial para garantir que os executáveis da arquitetura sejam gerados de forma consistente, em base diária. Esta prática busca evitar o problema comum do código funcionar na máquina do desenvolvedor e ao mesmo tempo quebrar o ambiente de produção.

A automação de builds externaliza todas as dependências de bibliotecas e configurações feitas dentro de uma IDE para um script específico e que possa ser consistentemente movida entre máquinas. Embora a automação de builds, na sua definição formal, lide apenas com a construção de um build, a prática comum de mercado é que builds devam executar um conjunto mínimo de testes de unidade automatizados para estabelecerem confiabilidade mínima ao executável sendo produzido.

Esta prática lida ainda com o estabelecimento de repositórios confiáveis de bibliotecas, o que garante governança técnica sobre o conjunto de versões específicas de bibliotecas que estejam sendo usadas para montar uma aplicação.

5. Gestão dos Testes

Organizações de baixa maturidade em automação de testes tem muito mais retrabalho ao longo de um projeto e geram muito mais incidentes em ambientes de produção. Esta prática DevOps buscar melhorar a testabilidade de aplicações e envolve:

  • a criação de testes de unidade de código para as regras de negócio não triviais do sistema e também pontos críticos do código fonte tais como repositórios de dados complexos, controladores de negócio e interfaces com outros sistemas e empresas;
  • a automação da interação com telas com testes funcionais automatizados;
  • testes automatizados de aspectos não-funcionais, como segurança, acessibilidade, performance ou carga.

6. Gestão de Configuração

Muito times já usam ferramentas de controle de versão para organizar o seu código fonte, tais como o SVN, GIT ou Mercurial. Ao mesmo tempo, existem outras preocupações associadas ao trabalho feito por times em uma mesma linha de código. A ausência de políticas automatizadas de gestão de configuração digo aumenta a chance que desenvolvedores desestabilizem os troncos principais dos repositórios e gerem fricção e retrabalho para seus pares.

Neste contexto, as ferramentas de gestão de configuração de código permitem que os repositórios sejam mantidos em estado confiável e que erros comuns sejam evitados através da automação de políticas. Tarefas de gestão de configuração de código tais como a criação de rótulos (labels), geração de versões, mesclagem de troncos de desenvolvimento e a manutenção de repositórios podem ser aceleradas e tornadas mais consistentes com o uso destes recursos.  Como exemplo, o Git suporta o conceito de hooks, mecanismo extensível de automação de políticas de gestão de código. Outras ferramentas como o GitLab, VSTS ou Atlassian Bamboo já possuem estes mecanismos embutidos.

7. Gestão dos Releases

A gestão dos releases (Release Management) é uma prática que buscar garantir que o processo de promoção do executável para os ambientes de testes, homologação e produção sejam automatizados e assim tornados consistentes. Isso é importante porque em muitas organizações é difícil colocar um produto em ambiente de produção. A demora para acesso aos ambientes, alto número de passos manuais, a complexidade e a dificuldade de analisar os impactos são comuns. Isso gera atritos, longas demoras e desgastes entre times de QA, desenvolvimento e operações. E no fim isso também provoca erros nos ambientes de produção.

Esta prática tem como principais benefícios:

  • reduzir o tempo para entregar um novo build em ambiente de produção através da automação da instalação e configuração de ferramentas e componentes arquiteturais;
  • reduzir erros em implantação causadas por parâmetros específicos que não foram corretamente configurados pelos times de desenvolvimento e operações;
  • minimizar a fricção entre os times de desenvolvimento, QA e operações;
  • prover confiabilidade e segurança no processo de implantar aplicações.

Um ponto de atenção é que a automação de releases não deve recompilar a aplicação. Para garantir consistência, ela deve garantir que o mesmo executável que foi montado na máquina do desenvolvedor (mesmo conjunto de bits) esteja operando em outros ambientes. Ou seja, a automação de releases faz a movimentação dos executáveis entre os ambientes e modifica apenas os parâmetros da aplicação e variáveis de ambiente. Este processo pode também envolver a montagem de máquinas virtuais em tempo de execução do script.

8. Automação da Monitoração de Aplicações

Ao colocarmos um build em ambiente de produção, devemos buscar que o mesmo não gere interrupções nos trabalhos dos nossos usuários. Infelizmente, muitas empresas convivem com incidentes em ambientes de produção causados por falhas nos processos de entrega em produção e desconhecimento de potenciais problemas.

Uma forma de reduzir a chance de incidentes para os usuários finais é implementar a monitoração contínua de aplicações (Application Performance Monitoring). Esta prática permite que agentes sejam configurados para observar a aplicação em produção. Alarmes podem ser ativados para o time de operações se certas condições de uso forem alcançadas ou se erros inesperados surgirem. Isso permite ter ciência de eventuais incidentes com antecedência e tomar ações preventivas para restaurar o estado estável do ambiente de operações.

E, para melhorar a experiência, alguns times já fazem que estes alarmes sejam enviados através de bots para as ferramentas de comunicação tais como o HipChat ou Slack.