BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Envio mais seguro, incentivando o domínio de implantações

Envio mais seguro, incentivando o domínio de implantações

Favoritos

Muitos incidentes acontecem durante ou logo após o lançamento, argumenta Charity Majors, CEO da Honeycomb. Ela acredita que uma maior participação no processo de implantação pelos desenvolvedores garantirá que ele seja executado regularmente e reduza os riscos. O medo do pipeline de lançamento levará os desenvolvedores a entregar menos, o que, por sua vez, aumenta o risco e o impacto da entrega de novos códigos. Ela defende um forte investimento em ferramentas, alta observabilidade durante e após o lançamento, e pequenos lançamentos frequentes, como forma de minimizar o impacto causado pela entrega de novos códigos.

De acordo com Majors, se entregar é arriscado ou altamente impactante, então é preciso consertar essa prioridade. No curto prazo, ela recomenda acompanhar a frequência de falhas e, em seguida, executar post mortems nessas falhas. Isso fornecerá áreas nas quais se pode investir para tornar seu pipeline mais resiliente. Também pode executar suas implantações de manhã, durante o horário comercial, quando todos estiverem disponíveis e atualizados.

Para começar a impulsionar melhorias a longo prazo, o projeto precisa de um proprietário. Como Majors observa, "se não tiver um dono, nunca melhorará". As empresas podem sinalizar a importância deste projeto, tornando um de seus melhores engenheiros o proprietário dessas melhorias. A Majors propõe que o software de implantação seja, com frequência, "um remanso técnico, um acúmulo de scripts e código de cola, gemas bifurcadas e tentativas sérias". Na sua opinião, implantar software é o código mais importante que se tem e deve ser tratado como tal. Isso ressoa com Alek Sharma, escritor técnico da CircleCI, que acredita que o DevOps é baseado no argumento de que "o código não está realmente cumprindo seu propósito até ser entregue".

Majors então sugere que o desenvolvedor que mescla o código também deve ser aquele que implanta o código. Para garantir que isso seja possível, ela afirma que todos os desenvolvedores devem ser proprietários de software que:

  1. Escrever código
  2. Poder implantar e reverter seu próprio código
  3. Conseguir depurar seus próprios problemas em produção (via instrumentação, não ssh)

Propriedade de software, de acordo com Majors, é o estado final natural do DevOps. Isso ajudará a reduzir os ciclos de feedback e garantir que o desenvolvedor com o maior número de contextos da mudança esteja pronto para ajudar se a implantação ocorrer mal. Isso leva a um software melhor e uma melhor experiência para os clientes. Ela continua afirmando que um desenvolvedor não deve ser promovido a uma posição sênior se não souber como implantar e depurar, em produção, seu próprio código.

No entanto, Serhat Can, evangelista técnico da Atlassian, sugere que, se a liberação exigir aprovação humana, a equipe de plantão deve realizar a liberação. Eles podem, então, acompanhar os desenvolvedores para que eles realizem as verificações pós-lançamento. Os desenvolvedores devem garantir que seja fácil para a equipe de plantão ver os problemas mais recentes que podem surgir no lançamento.

O objetivo dessas melhorias não é eliminar falhas. Como Majors observa, "os sistemas distribuídos nunca são 'para cima'; eles existem em um estado constante de serviço parcialmente degradado. Aceite falhas, projete resiliência, proteja e encolha o caminho crítico." Em vez disso, o foco deve ser permitir o envio de pequenas alterações com freqüência e exercitar o processo o suficiente para que as falhas se tornem não-eventos, uma vez que são rotineiras e sem impacto. A partir daqui pode-se começar a usar os fracassos como oportunidades de aprendizado.

Majors então introduz o conceito de Desenvolvimento Orientado por Observabilidade. Christine Yen, CPO da Honeycomb, descreve isso como "usando dados de produção para informar o quê, quando e como você desenvolve, sinaliza recursos e libera a funcionalidade do sistema". Ela recomenda incorporar os substantivos usados ​​durante o desenvolvimento, como IDs de construção, sinalizadores de recursos ou IDs de clientes, diretamente em suas ferramentas de observação. Isso facilitará a conexão dos dados à alteração que introduziu a falha. Como Majors observa, "a qualidade do código não é cognoscível antes de chegar à produção", portanto, equipando seu código com a instrumentação apropriada antes que ele seja enviado para auxiliar na depuração das alterações na produção.

Embora seja verdade que a maioria dos incidentes acontecem logo após o lançamento, como a Majors conclui, ter uma forte cultura de propriedade pode ajudar a reduzir a frequência e o impacto desses incidentes. Ter desenvolvedores que possam depurar seu próprio código em produção aumentará a propriedade sobre seus lançamentos. De acordo com Majors, uma maior propriedade sobre o processo de lançamento incentivará os desenvolvedores a enviar com mais frequência, resultando em versões menores e de maior qualidade.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT