No GitLab, processamos correções de software de duas maneiras: manual e automaticamente. Continue lendo para aprender sobre o trabalho do gerente de lançamento de criar e entregar atualizações importantes por meio de implantação automatizada em gitlab.com, bem como patches para os usuários trabalharem em suas próprias instalações.
Recomendo definir um lembrete no seu smartwatch: todo mês, no dia 22, os usuários que trabalham com o GitLab em suas instalações poderão ver as atualizações da versão atual do nosso produto. O lançamento mensal contém novos recursos, desenvolvimentos dos existentes e geralmente mostra o resultado final de solicitações da comunidade para ferramentas ou fusões.
Mas, como mostra a prática, o desenvolvimento de software raramente ocorre sem falhas. Quando um bug ou vulnerabilidade de segurança é descoberto, o gerente de lançamento da equipe de entrega cria um patch para nossos usuários com suas instalações. Gitlab.com é atualizado durante o processo de CD. Chamamos esse processo de CD de implantação automática para evitar confusão com o recurso de CD no GitLab. Este processo pode incorporar sugestões de solicitações pull enviadas por usuários, clientes e nossa equipe interna de desenvolvimento, de modo que a solução do chato problema de lançamento de patches seja resolvida de duas maneiras muito diferentes.
«Garantimos que tudo o que os desenvolvedores fazem seja implantado em todos os ambientes todos os dias antes de lançá-lo no GitLab.com", explica , Gerente Técnico Sênior, Departamento de Infraestrutura. "Pense nos lançamentos de suas instalações como instantâneos para implantações do gitlab.com, para os quais adicionamos etapas separadas para criar um pacote para que nossos usuários possam usá-lo para instalar em suas instalações".
Independentemente do bug ou vulnerabilidade, os clientes do gitlab.com receberão as correções logo após serem publicadas, o que é um benefício do processo automatizado de CD. Patches para usuários com instalações próprias requerem preparação separada pelo gerenciador de lançamento.
A equipe de entrega está trabalhando duro para automatizar a maioria dos processos envolvidos na criação de versões para reduzir (tempo médio de produção, ou seja, tempo gasto na produção), o período de tempo desde o processamento de uma solicitação de mesclagem por um desenvolvedor até a implantação no gitlab.com.
«O objetivo da equipe de entrega é garantir que possamos avançar mais rápido como empresa, ou pelo menos fazer com que o pessoal de entrega trabalhe mais rápido, certo?, diz Marina.
Tanto os clientes do gitlab.com quanto os usuários de suas instalações se beneficiam dos esforços da equipe de entrega para reduzir os tempos de ciclo e acelerar as implantações. Neste artigo explicaremos as semelhanças e diferenças entre esses dois métodos. e também descreveremos como nossa equipe de entrega prepara patches para usuários que trabalham em suas instalações e também como garantimos que o gitlab.com esteja atualizado usando implantação automatizada.
O que um gerente de lançamento faz?
Membros da equipe mensalmente nossos lançamentos para os usuários em suas instalações, incluindo patches e lançamentos de segurança que podem ocorrer entre os lançamentos. Eles também são responsáveis por liderar a transição da empresa para a implantação automatizada e contínua.
As versões de auto-instalação e as versões gitlab.com usam fluxos de trabalho semelhantes, mas são executadas em momentos diferentes, explica Marin.
Em primeiro lugar, o gerenciador de lançamento, independente do tipo de lançamento, garante que o GitLab esteja disponível e seguro desde o momento em que o aplicativo é lançado em gitlab.com, inclusive garantindo que os mesmos problemas não acabem na infraestrutura dos clientes com seus próprias capacidades.
Depois que um bug ou vulnerabilidade é marcado como corrigido no GitLab, o gerenciador de lançamento deve avaliar se ele será incluído nos patches ou atualizações de segurança para usuários com suas instalações. Se ele decidir que um bug ou vulnerabilidade merece uma atualização, o trabalho preparatório começa.
O gerente de lançamento deve decidir se deve preparar uma correção ou quando implantá-la – e isso depende muito do contexto da situação”, afirma.entretanto, as máquinas não são tão boas em gerenciar o contexto quanto as pessoas", diz Marin.
É tudo uma questão de correções
O que são patches e por que precisamos deles?
O gerenciador de lançamento decide se lançará uma correção com base na gravidade do bug.
Os erros variam dependendo da sua gravidade. Portanto, os erros S4 ou S3 podem ser estilísticos, como deslocamento de pixel ou ícone. Isso não é menos importante, mas não há impacto significativo no fluxo de trabalho de ninguém, o que significa que a probabilidade de criação de uma correção para esses erros S3 ou S4 é pequena, explica Marin.
No entanto, as vulnerabilidades S1 ou S2 significam que o usuário não deve atualizar para a versão mais recente ou há um bug significativo que afeta o fluxo de trabalho do usuário. Se eles estiverem incluídos no rastreador, muitos usuários os encontraram, então o gerente de lançamento começa imediatamente a preparar uma correção.
Assim que um patch para vulnerabilidades S1 ou S2 estiver pronto, o gerenciador de lançamento começa a liberar o patch.
Por exemplo, o patch GitLab 12.10.1 foi criado depois que vários problemas de bloqueio foram identificados e os desenvolvedores corrigiram o problema subjacente que os causava. O gerente de lançamento avaliou a exatidão dos níveis de severidade atribuídos e, após a confirmação, foi iniciado o processo de liberação de uma correção, que ficou pronta em até XNUMX horas após a descoberta dos problemas de bloqueio.
Quando muitos S4, S3 e S2 se acumulam, o gerenciador de lançamento analisa o contexto para determinar a urgência do lançamento de uma correção e, quando um certo número deles é atingido, todos são combinados e liberados. Correções pós-lançamento ou atualizações de segurança são resumidas em postagens de blog.
Como um gerenciador de lançamento cria patches
Usamos GitLab CI e outros recursos como ChatOps para gerar patches. O Release Manager inicia o lançamento da correção ativando a equipe ChatOps em nosso canal interno #releases no Slack.
/chatops run release prepare 12.10.1ChatOps funciona dentro do Slack para acionar diferentes eventos, que são então processados e executados pelo GitLab. Por exemplo, a equipe de entrega configurou o ChatOps para automatizar várias coisas para lançar patches.
Depois que o gerente de lançamento inicia a equipe ChatOps no Slack, o restante do trabalho acontece automaticamente no GitLab usando CICD. Há comunicação bidirecional entre ChatOps no Slack e GitLab durante o processo de lançamento, à medida que o gerenciador de lançamento ativa algumas das etapas principais do processo.
O vídeo abaixo mostra o processo técnico de preparação de um patch para GitLab.
Como funciona a implantação automática em gitlab.com
O processo e as ferramentas usadas para atualizar o gitlab.com são semelhantes aos usados para criar patches. A atualização do gitlab.com requer menos trabalho manual do ponto de vista do gerente de lançamento.
Em vez de executar implantações usando ChatOps, usamos recursos de CI, por exemplo. , com o qual o gerenciador de liberação pode agendar determinadas ações para serem executadas no horário necessário. Em vez de um processo manual, há um pipeline executado periodicamente uma vez por hora que baixa as novas alterações feitas nos projetos do GitLab, empacota-as e agenda a implantação, e executa automaticamente testes, controle de qualidade e outras etapas necessárias.
“Portanto, temos muitas implantações em execução em ambientes diferentes antes do gitlab.com, e depois que esses ambientes estão em boas condições e os testes mostram bons resultados, o gerente de lançamento inicia as ações de implantação do gitlab.com”, diz Marin.
A tecnologia CICD para suporte a atualizações do gitlab.com automatiza todo o processo até o ponto em que o gerente de lançamento deve iniciar manualmente a implantação do ambiente de produção no gitlab.com.
Marin entra em detalhes sobre o processo de atualização do gitlab.com no vídeo abaixo.
O que mais a equipe de entrega faz?
A principal diferença entre os processos de atualização do gitlab.com e o lançamento interno de patches para os clientes é que o último processo requer mais tempo e mais trabalho manual do gerente de lançamento.
“Às vezes atrasamos o lançamento de patches para os clientes com suas instalações devido a problemas relatados, problemas de ferramentas e porque há muitas nuances que precisam ser levadas em consideração ao lançar um único patch”, diz Marin.
Um dos objetivos de curto prazo da equipe de entrega é reduzir a quantidade de trabalho manual por parte do gerente de lançamento para acelerar o lançamento. A equipe está trabalhando para simplificar, agilizar e automatizar o processo de lançamento, o que ajudará a obter correções para problemas de baixa gravidade (S3 e S4, Aproximadamente. tradutor). Focar na velocidade é um indicador-chave de desempenho: é necessário reduzir o MTTP - o tempo desde o recebimento de uma solicitação de mesclagem até a implantação do resultado no gitlab.com - das atuais 50 horas para 8 horas.
A equipe de entrega também está trabalhando na migração do gitlab.com para uma infraestrutura baseada em Kubernetes.
Nota do editor: Se você já ouviu falar da tecnologia Kubernetes (e não tenho dúvidas de que já ouviu), mas ainda não a tocou com as mãos, recomendo participar de cursos intensivos online , que acontecerá de 28 a 30 de setembro, e , que acontecerá de 14 a 16 de outubro. Isso permitirá que você navegue e trabalhe com confiança com a tecnologia.
São duas abordagens que perseguem o mesmo objetivo: entrega rápida de atualizações, tanto para gitlab.com quanto para clientes em suas instalações.
Alguma idéia ou recomendação para nós?
Todos são bem-vindos para contribuir com o GitLab e agradecemos o feedback de nossos leitores. Se você tiver alguma ideia para nossa equipe de entrega, não hesite marcado team: Delivery.
Fonte: habr.com