Mais notíciasA maioria de nós concorda que cinco atividades compõem o DevOps: integração contínua, entrega contínua, infraestrutura de nuvem, automação de testes e gerenciamento de configuração. Se você faz essas cinco coisas, você faz DevOps. Claramente, todas as cinco são importantes para ter sucesso em DevOps. No entanto, integração contínua e entrega contínua podem ser os pilares mais difíceis de dominar.
A integração contínua é a prática de integração e testes de um novo código à base de código existente, e é uma condição necessária para que o processo de entrega contínua possa acontecer da forma correta. O objetivo é testar o código o mais rápido possível para identificar problemas o mais cedo possível.
Já Entrega contínua (DC) é um conjunto de práticas que tem como objetivo garantir que o novo código pode ser implantado no ambiente de produção a qualquer momento. Entre os seus maiores benefícios estão a redução de custo e do risco na entrega de mudanças incrementais em um software.
Juntas, integração contínua e entrega contínua formam o que chamamos de CICD.
Algumas empresas como Facebook e Netflix usam CICD para completar 10 ou mais lançamentos por semana. Outras empresas lutam para bater esse ritmo, porque elas sucumbem a uma ou mais das cinco armadilhas listadas abaixo.
1: Automatizar os processos errados
Esta armadilha tende a atacar as organizações que fazem a mudança do desenvolvimento em cascata para o DevOps. Novas organizações têm a vantagem de implementar CICD a partir do zero. Empresas existentes precisam mover-se de forma gradativa do desenvolvimento manual para o desenvolvimento altamente automatizado. A transição completa pode levar vários meses, o que significa que você precisa ser iterativo na forma como irá adotar CICD.
A pergunta "Será que isso precisa ser automatizado agora?" deve vir acompanhada de outras perguntas relevantes. Entre elas:
Com que frequência o processo ou cenário é repetido?
Quanto tempo dura o processo?
Quais pessoas e dependências de recursos estão envolvidos no processo? Eles estão causando atrasos na CICD?
É o processo sujeito a erros, se não for automatizado?
Qual é a urgência em adotar o processo automatizado?
Usando esta lista de questionamentos você pode priorizar as etapas em uma implementação CICD. Em primeiro lugar, automatizar o processo de compilação de código. Idealmente, você vai integrar código várias vezes por dia. Manualmente, o processo leva de alguns minutos a um par de horas. Isso atrasa a tarefa. Também é um processo susceptível a erro humano. É, optar pelo desenvolvimento automatizado pode reduzir tempo.
Podemos executar a mesma lista de verificação para os testes. Uma vez em transição para CICD, você pode se perguntar: Será que devemos automatizar todos os testes ou primeiro os testes funcionais de UI? Ambos serão repetido pelo menos uma vez por dia. Ambos podem levar de duas a três horas para uma aplicação de médio porte. Mas eles envolvem múltiplas dependências. Se você automatizar testes funcionais, você pode não ter que atualizar o script de automação. Mas, por outro lado, a interface do usuário muda muitas vezes e, portanto, requer frequentes mudanças no roteiro. Embora ambos sejam propenso a erros, devo priorizar o teste funcional antes do teste de interface do usuário para fazer melhor uso dos recursos.
Vamos fazer isso mais uma vez com o processo de criação de ambientes. Este cenário só é repetido com frequência se você estiver em uma farra de contratação ou experimentando churn pesada. É um processo bastante demorado que pode levar várias horas se não dias. Novos membros da equipe não podem fazer nada útil, sem ambientes. Portanto há dependência que pode provocar atraso. Mas eu não diria que o processo é passível de erro. Talvez por isso não seja tão urgente.
Se você tiver recursos ilimitados, provavelmente vai optar por automatizar tudo que for possível. Mas não pode atingir a automação total dos testes. Às vezes você pode quebrar as tarefas em segmentos menores e automatizar partes. Às vezes você deve simplesmente documentar o processo em detalhe e executá-lo manualmente.
2: Confundir implantação contínua com entrega contínua
Implantação contínua é o conceito de que todas as alterações feitas no código são implantadas quase imediatamente para a produção. Isso é terrível para a maioria das organizações, porque as mudanças rápidas de produtos podem assustar os usuários.
As empresas acreditam que, se elas não praticam implantação contínua, eles não estão fazendo CD. Não conseguem distinguir entre implantação contínua e entrega contínua.
Entrega contínua é o conceito de que todas as alterações no código base passam antes por ambientes de não-produção. A equipe encontra e aborda questões imediatamente, e não mais tarde, quando já liberaram o código para uso.
Quando liberar o código-base para a produção é uma decisão de negócios.
3: Não ter dashboards e métricas significativas
Em implementações CICD, a equipe Scrum pode criar um painel antes que os membros saibam o que precisam rastrear. Como resultado, a equipe cai vítima de uma falácia lógica: "Estas são as métricas que temos, de modo que devem ser importantes." Em vez disso, faça uma avaliação progressiva antes de projetar um painel.
Diferentes membros de uma organização de TI, e até mesmo vários membros de uma equipe Scrum, têm prioridades diferentes. Por exemplo, as pessoas em um centro de operações de rede (NOC) amam indicadores vermelhos, amarelos e verdes. Tais painéis tipo semáforo permitem que o pessoal do NOC possa distinguir problemas imediatamente. Semáforos ajudam a tornar administráveis centenas de servidores.
Você pode ser tentado a usar um painel de controle de semáforo para CICD também. Verde, estamos no caminho certo. Amarelo, estamos fora da pista, mas temos um plano para lidar com isso. Vermelho, estamos fora da pista e, provavelmente, precisamos mudar os nossos objetivos.
Esse painel pode ser útil para um Scrum Master, mas para o VP de desenvolvimento ou o CTO, nem tanto. Se uma equipe Scrum tem 350 horas de trabalho pela frente para duas semanas de sprint, e os seus 10 membros são responsáveis ??por 35 horas cada, talvez a velocidade de conclusão das tarefas seja o mais importante. Os membros da equipe estão conseguindo lidar com suas cargas de trabalho? Quão rapidamente? A performance está melhorando ao longo do tempo?
Se você pode avaliar quais os dados que todo mundo quer e estabelecer uma narrativa padrão para o que significam, você pode criar um dashboard útil. Pergunte como as partes interessadas querem olhar o projeto graficamente também. O que é melhor para eles? Gráficos, textos ou números?
Fazer com que um painel CICD seja útil não é fácil. Muitas vezes, o membro da equipe mais vocal sequestra o processo, e outros se sentem frustrados com um painel que reúne apenas as preferências de uma pessoa. Ouça todos.
4: Faltar coordenação entre a CI e CD
Esta armadilha nos leva de volta à nossa definição de consenso de DevOps, que sustenta que CI e CD são dois itens diferentes. CI alimenta CD. A implementação de um pipeline CI decente e um sistema CD completo leva meses e requer colaboração e garantia de qualidade da equipe de DevOps, engenheiros de operação, Scrum masters... Todos devem contribuir. Talvez o aspecto mais difícil da CICD é este fator humano, em vez de qualquer dos desafios técnicos que discutimos. Assim como você não pode programar um relacionamento saudável entre duas pessoas, você não pode automatizar colaboração e comunicação.
Empresas como a Netflix pode completar a integração, teste e entrega em questão de duas a três horas. Eles estabeleceram um sistema que passa o código de mão em mão, sem indecisão e discussão. Não, não é 100 por cento automatizado, porque isso é impossível com a tecnologia atual.
5: Balancear a frequência de execução de trabalhos de IC e a utilização de recursos
Trabalhos de IC devem ser acionados para cada mudança introduzida no código. Isso incentiva os desenvolvedores a realizarem check-ins de pequenos pedaços de código, aumentando a produtividade em um dia. No entanto, os trabalhos de IC desnecessários consomem recursos, o que desperdiça tempo e dinheiro.
Como esse processo envolve um monte de utilização de recursos (CPU, alimentação, tempo), o software deve ser dividido em componentes menores para criar pipelines mais rápidos em execução. Ou os trabalhos de IC devem ser concebidos para check-ins por lote.
O objetivo é encontrar um equilíbrio entre a frequência de execução de trabalhos de IC e a utilização dos recursos.
Manter a meta à vista
Em última análise, CICD é essencial porque ele atende os objetivos de negócio.
Executivos de tecnologia sabem que a evolução contínua, consertos rápidos e a garantia de qualidade ajudam a reter clientes. DevOps pode criar uma experiência de trabalho melhor para a sua equipa, mas não é por isso que as empresas implementam DevOps.
Simplificando, vale a pena rever as armadilhas de CICD porque bilhões de dólares estão em jogo.
Fonte: CIO
Data: 19/10/2016
Hora: 7h09
Seção: Tecnologia
Autor: John Troyer
Foto: ------
Link: http://cio.com.br/tecnologia/2016/10/19/qual-e-o-segredo-para-o-sucesso-do-devops/
Destaques
Comentários
