Como nossa equipe de entrega, usando apenas nossos próprios recursos, refez nosso sistema em CI / CD.
Equipes de engenheiros estão constantemente sob pressão: você precisa fornecer novas funções na forma de um produto digno e, ao mesmo tempo, minimizar constantemente o tempo de ciclo . Muitas vezes, especialistas sem entender se apegam às ferramentas modernas. A integração e entrega contínuas (CI / CD) estão integradas no GitLab, nosso único aplicativo de ciclo de vida do DevOps, e agora estamos migrando para o Kubernetes para reduzir ainda mais o tempo do ciclo. No entanto, para o CI / CD - e, finalmente, para o Kubernetes -, fomos de uma maneira bastante incomum. A equipe de entrega , levando-nos para a entrega contínua do GitLab.com, sobrecarregou o sistema antigo e só então mudamos completamente para o Kubernetes.
Como lançamos lançamentos antes do CI / CD
Entre 7 de agosto e 27 de setembro de 2019, a enorme comunidade GitLab e os membros de nossa equipe alcançaram uma média de 55 confirmações por dia - são iterações contínuas do nosso produto para criar novos recursos. Porém, antes de dominar a entrega contínua, usamos períodos de congelamento de novas funções a partir do dia 7 de cada mês: nesse momento, nossos engenheiros mudaram sua atenção do desenvolvimento de novas funções para a depuração e a preparação dos próximos lançamentos, lançando-se de maneira estável no dia 22 de cada mês.
Ao introduzir um prazo estrito, incutimos nos desenvolvedores um comportamento que os ajudou a se concentrar em uma data específica, em vez de se concentrar na prontidão.
"... os desenvolvedores começaram a dançar a partir do sétimo dia, porque examinaram o calendário e pensaram: bem, ainda há tempo, o sétimo dia em uma semana e, depois, à meia-noite do dia 6, eles se fundiam freneticamente", disse Marine Jankowski , CTO da equipe de entrega. "Eles sabem que se eles quebrarem os prazos, terão que esperar mais um mês e, se conseguirem fazê-lo a tempo, terão mais duas semanas boas para depurar."
Desde o início do GitLab.com, períodos de congelamento de novos recursos foram usados como tempo para estabilizar ”, explicou Marine.
No entanto, o número de usuários estava crescendo e a necessidade de novos recursos nos forçou a acelerar o ritmo de desenvolvimento. O período de estabilização retardou o ciclo e atrasou bastante a transição para depuração, regressão e entrega de funções - tanto para usuários no Gitlab.com quanto para clientes individuais.
"Em alguns casos, [congelar novos recursos] provocou instabilidade na plataforma - devido ao fato de que as correções de alta prioridade não chegaram ao cliente a tempo", disse Marine. - "Ao mudar para CI / CD, entregamos novos produtos e os depuramos muito mais rapidamente."
Antes de formarmos a equipe de entrega para transferir o GitLab.com para entrega contínua - e, finalmente, para o Kubernetes -, dependíamos do gerente de lançamento . Essa era uma posição de transição entre os desenvolvedores, realizada por quem estava preparando o novo lançamento. Temos iterado o processo há mais de 5 anos , mas os gerentes de versão criaram uma base de conhecimento e a automatizaram mais ou menos.
No entanto, o método acabou sendo ineficaz, porque o cronograma de implantação e a preparação para a liberação flutuaram: de meio dia para vários dias, devido ao fato de que tarefas para execução manual estavam se acumulando no processo .
"O gerente de lançamento recebeu uma lista fixa de tarefas, um prazo e repetiu as etapas acima várias vezes até que um lançamento completamente pronto e estável no GitLab.com fosse obtido", disse Marine. No sentido mais geral, era necessário o seguinte ao gerente de lançamento:
- Sincronizando manualmente os muitos repositórios que compõem o GitLab.
- Verifique se as versões corretas estão incluídas nos ramos Git criados manualmente.
- Quando a versão receber as tags, implante manualmente os ambientes de teste e produção no GitLab.com.
- Verifique se tudo funciona e publique manualmente os pacotes para usuários individuais.
Em uma apresentação no Brooklyn durante o GitLab Commit dedicado a este tópico, Marine compartilhou os resultados das observações para 2018: no período de duas semanas antes do lançamento, a equipe de entrega passou 60% do tempo interagindo com implantações, outros 26% gastos em tarefas manuais e semi-manuais, como escrever uma revisão liberação mensal.
Resultados da observação para 2018, antes de passar para entrega contínua: é assim que a equipe de entrega passou um tempo 2 semanas antes do lançamento.
"Falando em geral, 14 dias, duas semanas antes do lançamento, a equipe apenas fez o que estava olhando para os monitores, observando como a tinta estava secando, ou algo assim", disse Marine.
Mas, assumindo 86% dessa torta (60% para implantações + 26% para tarefas manuais), a equipe de entrega resolveria vários problemas:
- Novos lançamentos sem demora.
- Implantações repetidas e mais rápidas sem tempo de inatividade.
- Mais tempo para migrar o GitLab.com para o Kubernetes.
- Mais liberdade para preparar sua organização para entrega contínua.
Embora o CD esteja disponível apenas no GitLab.com, nossos clientes individuais também se beneficiam da nossa transição para ele. Agora, tudo o que não é afetado pelo teste de IC é testado automática e manualmente nos ambientes - antes de chegar ao GitLab.com. Tudo o que chega ao GitLab.com e precisa de depuração será depurado dentro de algumas horas. Portanto, a versão final para clientes individuais estará limpa.
A transição do congelamento para o CD foi uma questão de tempo, à medida que nossa pilha de funções cresceu, e uma equipe de engenheiros liderada por Marina pareceu observar a transição: “A equipe de Entrega foi formada com o único objetivo de transferir a empresa para o modelo de CD e, ao mesmo tempo, transferir a empresa à plataforma Kubernetes para facilitar o dimensionamento e acelerar o ciclo ".
A maioria das empresas no lugar do GitLab começaria a transição para CI / CD e Kubernetes, integrando primeiro novas tecnologias em seu fluxo de trabalho e corrigindo o processo de desenvolvimento no processo. Nós escolhemos uma abordagem diferente.
A migração para Kubernetes requer uma mudança não apenas no sistema de produção, mas também na abordagem de desenvolvimento ”, disse Marine. O Kubernetes oferece determinados recursos que estão disponíveis facilmente e sem investimento adicional. Mas, para realmente se beneficiar dos recursos gratuitos oferecidos pelo Kubernetes, você precisa de algum tipo de CI / CD.
A equipe de entrega aceitou o seguinte: para facilitar a transição para o Kubernetes para entrega contínua, nossos engenheiros já devem trabalhar com foco no CI / CD, o que implica um controle de qualidade aprimorado (QA) e um planejamento de funções mais rigoroso. E então nossa equipe de Entrega tomou uma decisão sombria : construiu um sistema de CD com as ferramentas existentes e reorganizou a infraestrutura do aplicativo GitLab.com - em vez de dominar imediatamente as novas ferramentas e tecnologias de CD.
"A idéia era simples", disse Marine, " usamos as ferramentas à nossa disposição , automatizamos a maioria das tarefas manuais e testamos todo o sistema estático sob carga. Se o sistema estático resistir, procederemos ao teste dinâmico".
Essa abordagem forneceu dois benefícios principais:
Primeiro , identificamos todos os pontos fracos de nossa abordagem e os estabilizamos ao automatizar com o CI, para que nosso aplicativo se fortalecesse e o sucesso da transição para o Kubernetes se tornasse mais real.
Em segundo lugar , ao montar uma equipe de engenheiros em CD, implementamos na mente dos engenheiros do GitLab, que estão acostumados a implantações toda semana e esperam, às vezes o dia inteiro, pois afetam a fusão, é uma mudança cultural real.
"Desde que dominamos o CI / CD, nossos desenvolvedores começaram a entender de uma nova maneira o que significa ser feito", disse Marine.
Antes da introdução do IC / CD, a mudança foi considerada pronta assim que a revisão foi concluída. Isso eliminou a implantação em vários ambientes, o que consumia tempo. Hoje, as implantações são entregues dentro de algumas horas; portanto, não há razão para não confirmar se as alterações estão operacionais nos ambientes de teste e produção.
A implantação de aplicativos de revisão do Kubernetes permite que os desenvolvedores executem verificações de qualidade literalmente em tempo real, e o uso de sinalizadores de recursos para entrega progressiva também acelera o desenvolvimento.
"Desde a primeira etapa do CD, os desenvolvedores são obrigados a responder a todos os controles de qualidade automatizados e também a realizar confirmações manuais em um novo nível nos ambientes de produção e teste. Além disso, os desenvolvedores podem fazer alterações no ambiente de produção em um dia enquanto que anteriormente levava vários dias (ou até semanas) ".
Com o CD, você pode realizar verificações de qualidade de código com muito mais frequência. E como com o nosso sistema de CI / CD as alterações no código são entregues 24 horas por dia, os desenvolvedores alternam sob demanda por problemas não padrão que aparecem em tempo real, uma vez que o "período de incubação" é bastante reduzido.
Nosso novo método
Após a implementação do sistema de CI / CD , automatizamos 90% do processo. Os 10% restantes requerem intervenção humana - é necessária coordenação entre muitas pessoas com direito de acesso.
"Estamos gradualmente reduzindo esses 10% - de modo que precisamos apenas de aprovação para a publicação do lançamento", afirmou Marine. Na iteração atual, o processo de CI / CD funciona da seguinte maneira :
- O IC pesquisa automaticamente tags específicas em solicitações de mesclagem aprovadas por revisores e desenvolvedores.
- O CI sincroniza automaticamente os repositórios necessários e, ao mesmo tempo, cria as ramificações, tags e Git necessárias, além de incluir as versões corretas que queremos entregar.
- Quando as construções são concluídas, os pacotes são implantados automaticamente nos ambientes de teste.
- São realizadas verificações automáticas de qualidade e, se tudo correr bem, a implantação é entregue a um pequeno segmento de usuários em um ambiente de produção.
- Paralelamente, os desenvolvedores realizam o controle de qualidade de um nível diferente manualmente - para garantir que as novas funções funcionem como deveriam.
- Se um problema de alta prioridade for descoberto durante a confirmação manual, as implantações serão interrompidas.
- Quando a etapa anterior for concluída, o membro da equipe de entrega iniciará a entrega da implantação para todos os usuários do GitLab.com.
- Em seguida, com base na mais recente implantação de produção lançada no GitLab.com, é criada uma versão individual do cliente.
Como em qualquer outra equipe de engenharia, o dimensionamento é um verdadeiro desafio para nós. No entanto, um dos maiores desafios para os técnicos é garantir que o controle de qualidade cubra tudo, mas para um projeto grande como o GitLab.com, esse é um trabalho intenso. E você também precisa garantir que haja monitoramento e notificação suficientes, para que o projeto não funcione apenas em regras predefinidas.
O segundo grande desafio para nós é a complexidade do sistema GitLab.com e a transferência de alterações diretamente no processo para todas as equipes de engenharia. "Quebrar o processo e os hábitos estabelecidos ao longo dos anos está longe de ser fácil", disse Marine.
Resultados
O GitLab já se beneficia muito ao mudar para CI / CD.
Observações e avaliações em 2019 mostraram que, naqueles 14 dias antes do lançamento, a equipe de entrega gasta 82% do tempo mais produtivo: foi liberada para trabalhar em outras tarefas importantes.
A observação de 2019 mostrou que, nas mesmas duas semanas, muito tempo precioso foi liberado dos desenvolvedores, graças à transição para o c CD.
Ao automatizar o trabalho manual, a equipe de entrega finalmente mudou para a infraestrutura do GitLab.com para melhorar o suporte à velocidade de desenvolvimento e ao tráfego de usuários e, ao mesmo tempo, à migração para o Kubernetes.
"E, como eu já disse, tudo isso é sem o Kubernetes. Tudo foi feito no antigo sistema antecessor", disse Marine a convidados do Brooklyn GitLab Commit. - "Mas vencemos o tempo, então agora minha equipe está intimamente envolvida na migração. No entanto, uma das maiores mudanças ocorreu precisamente no hábito de organizar o desenvolvimento".
Os resultados após a transição são significativos. Se no sistema antigo, em maio de 2019, a equipe entregou em algum lugar 7 implantações, em agosto de 2019 esse número aumentou para 35. E esse não é o limite: os números aumentarão significativamente - agora que a equipe realiza muitas implantações diariamente.
"Acabamos de migrar nosso Serviço de Registro para o Kubernetes, e se você usar o registro de contêiner no GitLab.com , todos os seus pedidos serão executados na plataforma Kubernetes", disse Marine. - "O GitLab é um sistema com vários componentes e continuamos a isolar e transferir outros serviços."
Cada nova versão inclui novos recursos de CI / CD. Por exemplo, na versão 12.3, expandimos o GitLab Container Registry - permitindo aos usuários usar o CI / CD e coletar e incorporar imagens / tags em seus próprios projetos . Havia outras inovações emocionantes.
Também transferir o sistema para entrega contínua?
Marin aconselhou as empresas que estão prestes a mudar para o CD para começar com o que têm.
"Quanto a mim, aguardar a migração para uma nova plataforma é prejudicar a si mesmo", disse Marine. "A maioria dos sistemas pode ser alterada de alguma maneira e acelerar o ciclo de processamento sem migrar para um sistema completamente novo. A aceleração do ciclo de desenvolvimento / liberação aumenta muito a eficiência de cada engenheiro no sistema e libera mais tempo para migrar para uma nova plataforma, como o Kubernetes".
Se você estiver curioso sobre o que está por vir, dê uma olhada neste resumo detalhado dos novos e interessantes recursos de CI / CD que estão esperando nos bastidores - com o lançamento 12.4 em diante.
Perdeu o commit do Brooklyn GitLab?
Se você não pôde assistir à apresentação da Marina com os antecedentes de nossa transição para o Kubernetes, assista ao vídeo completo abaixo e junte-se a nós no European GitLab Commit em Londres, em 9 de outubro .