Isenção de responsabilidade . Kostis Kapelonis - Desenvolvedor do Codefresh, a primeira plataforma de CI / CD para Kubernetes e containers, para defender e defender os princípios do desenvolvimento de software. A missão da Codefresh "Automatize e simplifique tudo, desde o código até a nuvem". Como engenheiro de software, a Kostis tem muitos anos de experiência em contêineres de aplicativos, construindo pipelines de CI / CD e desenvolvendo aplicativos Java. Ele mora na Grécia e adora patinar.
Como diz o ditado, "se algo causa dor, faça-o com mais frequência". A integração contínua é, em essência, uma repetição da etapa de integração com alta frequência, a fim de aliviar a “dor” que ela causa. Este artigo é sobre isso - sobre a "dor" do desenvolvimento e como reduzi-lo.
Há muitas informações sobre integração contínua (IC) e entrega contínua (CD). As postagens do blog usam termos técnicos para explicar o que significam as metodologias de CI / CD, o que elas fazem e como podem ajudar sua empresa. Infelizmente, frequentemente essas duas metodologias estão associadas a ferramentas específicas ou mesmo a fornecedores de software. Uma conversa típica sobre esse tópico em uma empresa é:
- Você usa integração contínua em sua equipe?
- Sim, é claro, usamos a ferramenta X!
Deixe-me contar um pequeno segredo. Integração e entrega contínuas são duas abordagens para o desenvolvimento de código que não têm nenhuma relação com uma ferramenta ou fornecedor específico. Apesar de existirem ferramentas e soluções que podem ajudá-lo nos dois casos (por exemplo, Codefresh), na realidade, uma empresa pode praticar o CI / CD usando apenas scripts bash e scripts de linha única Perl. Isso não é muito prático, mas certamente bastante possível.
Portanto, em vez de cair na armadilha geral de explicar a essência do IC / CD usando ferramentas e termos técnicos, explicaremos como essas metodologias se baseiam no fator mais importante no processo de desenvolvimento - pessoal!
A história das pessoas: integração de software em tempos difíceis
Conheça Alice, Bob, Charlie, David e Elizabeth - todos eles trabalham para a SoftwareCo Inc. sobre a criação do aplicativo SuperBigProject. Alice, Bob e Charlie são desenvolvedores. David é engenheiro de teste e Elizabeth é gerente de projetos da equipe.
A maneira tradicional de desenvolver um aplicativo é a seguinte: Alice, Bob e Charlie trabalham em três funções diferentes em suas estações de trabalho. Cada desenvolvedor escreve e testa o código individualmente. Eles usam longas ramificações de funções que existem por várias semanas ou até meses antes de serem combinadas em um produto final.
Em algum momento, a gerente de projetos Elizabeth reúne toda a equipe e diz: “Pessoal, já precisamos lançar um release, então tente!”
Depois disso, Alice, Bob e Charlie tentam integrar as três funções em um único ramo. Este é um momento muito estressante, porque esses recursos nunca foram testados juntos. Muitos erros e problemas aparecem do nada, devido a suposições incorretas ou problemas com o ambiente, porque, se você se lembrar, até o momento todas as funções foram simplesmente testadas em diferentes estações de trabalho, isoladas uma da outra.
Assim que a "febre da integração" terminar, o resultado combinado será repassado a David, que realizará testes manuais e automáticos adicionais. Esse período também leva muito tempo, porque é David quem pode aprovar ou bloquear a liberação, dependendo de quantos erros críticos são encontrados. Todo mundo está observando David de perto enquanto ele faz sua parte, pois o teste pode revelar sérios problemas que podem atrasar o lançamento do produto.
Por fim, o teste está concluído e Elizabeth anuncia com alegria que o produto de software está pronto para embalagem e envio.
Então, como as pessoas se sentem nessa história imaginária, mas muito realista?
- Os desenvolvedores Alice, Bob e Charlie estão descontentes porque sempre descobrem problemas de integração antes do lançamento. O período de integração é semelhante a um tiroteio no qual as balas chegam simultaneamente de todos os lados.
- O testador David está constantemente nervoso por causa da natureza de "contração" de seu trabalho - há períodos calmos em que ele apenas espera até que os desenvolvedores terminem o trabalho nas funções, e há uma fase de teste em que ele está sobrecarregado com o trabalho e deve lidar com scripts de teste inesperados, para Além disso, neste momento, a equipe de desenvolvimento está literalmente atrás dele.
- Elizabeth, como gerente de projetos, também está infeliz. A fase de integração é um elo crítico no projeto. Esse é um período movimentado, pois qualquer problema inesperado empurra a liberação do produto. Elizabeth sonha com um lançamento de software sem surpresas, mas na prática isso nunca acontece. O "sucesso" da fase de integração na linha do tempo planejada do projeto é sempre um jogo de adivinhação.
Em geral, todos os membros da equipe estão descontentes. A propósito, se sua empresa ainda estiver desenvolvendo esse software, tente entender que esse processo de desenvolvimento é prejudicial ao moral de sua equipe.
Portanto, aqui o único e principal problema é a fase de integração, que ocorre em todas as versões do produto de software. Esse é um ponto problemático no fluxo de trabalho que não permite que uma equipe de programadores se liberte da situação estressante associada à liberação do programa.
Adicionando continuidade à integração
Agora que vimos o que significa "integração", é muito fácil entender o que significa "integração contínua". Como diz o ditado, "se algo causa dor, faça-o com mais frequência". A integração contínua é, em essência, uma repetição da etapa de integração com alta frequência, a fim de aliviar a “dor” que ela causa.
A maneira mais óbvia de tornar o processo menos doloroso é integrar-se com mais frequência após cada mesclagem, em vez de aguardar o lançamento oficial.
Quando uma equipe pratica integração contínua, então:
- Todos os objetos são mesclados diretamente na ramificação principal.
- Os desenvolvedores trabalham juntos, não isoladamente. Todas as funções são desenvolvidas a partir da linha principal.
- Uma função é considerada desenvolvida se a linha principal estiver totalmente operacional e funcionar em qualquer máquina, e não apenas em uma estação de trabalho separada.
- O teste ocorre automaticamente no nível de elementos individuais ou objetos de código e no nível da linha principal.
Essa é a essência da integração contínua. Claro, existem outras nuances dessa metodologia, há um livro inteiro sobre esse tópico, mas o principal é que, em vez de um único período estressante de integração, quando tudo é mesclado e testado ao mesmo tempo, a integração ocorre o tempo todo de maneira contínua.
A integração contínua no processo de desenvolvimento de software é superior à integração convencional porque:
- Reduz o número de surpresas que aparecem ao mesclar objetos de código.
- Resolve o problema "o programa só funciona na minha máquina".
- Ele divide o período de teste em vários períodos, onde cada objeto de código se funde gradualmente com a linha principal, em vez de mesclar todos os objetos de uma só vez.
Como resultado, a equipe que usa o IC não se sente como uma montanha-russa quando períodos calmos de desenvolvimento são intercalados com lançamentos estressantes. Além disso, ela tem a oportunidade de avaliar sobriamente a proximidade do projeto, em vez de adivinhar as datas de lançamento. O uso de CI é um dos pilares do desenvolvimento moderno de software. Hoje, esse método está muito bem documentado e bem conhecido. Portanto, não há justificativa para o fato de sua empresa ainda não praticar IC no desenvolvimento de projetos de software.
Entrega de software em tempos difíceis
Agora que examinamos o histórico da integração regular e como a integração contínua funciona, podemos levar isso para o próximo nível do processo de desenvolvimento - entrega contínua. Se voltarmos à nossa história original, veremos uma imagem semelhante ao processo de integração normal:
O lançamento do produto foi essencialmente um evento semelhante ao Big Bang. Depois que o software foi considerado testado, alguém teve que concluir o processo de minimizar e implantar o software a partir de contêineres. A implantação de software na produção também foi um período muito movimentado e tradicionalmente incluía muitas etapas manuais e procedimentos de acompanhamento. As implantações eram muito raras e ainda hoje existem empresas que executam esse procedimento não mais que uma vez a cada seis meses. Somente em casos extremos, a implantação ocorreu por vez - ao usar o modelo em cascata de desenvolvimento de software (cascata).
A entrega do software somente após atingir o prazo cria os mesmos problemas que as integrações regulares e pouco frequentes:
- O ambiente de produção geralmente é diferente do ambiente de teste, que requer configuração adicional no último minuto.
- As funções que funcionavam normalmente em um ambiente de teste são interrompidas no ambiente de trabalho.
- As funções que não estavam prontas no momento do lançamento ou nunca são fornecidas aos clientes, ou o aprimoramento delas aprimora ainda mais o lançamento.
- Nesse sentido, os lançamentos criam tensão entre desenvolvedores que desejam adicionar novos recursos para expandir a funcionalidade do software e operadores que desejam estabilidade e não desejam implantar muitas novas funções ao mesmo tempo.
A solução para esse problema é o mesmo modelo que no caso de integração. Se pudermos aliviar a dor do processo de integração, tornando-o mais frequente, podemos fazer o mesmo no processo de entrega do software.
Adicionar continuidade à entrega
Entrega contínua é a prática de empacotar em contêineres e preparar o software como se estivesse sendo enviado à produção o mais rápido possível. E o método de entrega mais extremo é após cada mesclagem.
Dessa forma, o CD leva o CI um passo adiante. Depois de mesclar cada função com a ramificação da linha principal, o aplicativo não apenas é verificado quanto à correção, mas também é empacotado e implantado em um ambiente de teste que combina perfeitamente com o ambiente de trabalho. Tudo isso acontece de modo totalmente automático - preste atenção à ausência na figura dos homenzinhos que indicam procedimentos manuais.
Lembre-se também de que cada novo recurso é um potencial candidato a lançamento na produção. Na prática, nem todos os candidatos são enviados para produção. Dependendo da organização do processo, a decisão de implantar na produção às vezes requer a intervenção de uma pessoa responsável que decide liberar ou não o release em produção, mas não participa pessoalmente da preparação do release. Neste ponto, a versão já está empacotada, testada e implantada em um ambiente de teste.
A entrega contínua (CD) é um pouco mais complicada do que a integração contínua (IC). O motivo é que, como cada candidato a lançamento pode alcançar potencialmente a produção, o ciclo de vida completo deve ser automatizado:
- As montagens devem ser repetíveis e determinísticas.
- Todas as etapas devem ser automatizadas, o que é bastante difícil de colocar em prática.
- Todas as configurações e arquivos relacionados devem existir no sistema de controle de versão, e não apenas no código-fonte.
- Cada recurso / release deve ser testado em seu próprio ambiente de teste criado e destruído dinamicamente.
- Todos os conjuntos de testes devem ser automatizados e relativamente rápidos, o que também não é uma tarefa fácil.
Embora uma “nuvem” possa certamente ajudar a cumprir todos esses requisitos, uma equipe de programadores, desenvolvedores e operadores, precisa de um certo nível de disciplina que realmente garanta o processo de entrega contínua de software.
Após a introdução dos lançamentos de CD, torna-se uma rotina, como se fosse realizada com um simples clique de um botão. Cada membro da equipe, não apenas o gerente do projeto, pode ver o candidato à versão atual. Esse candidato pode não ter algumas funções necessárias ou pode não satisfazer totalmente todos os requisitos, mas isso não é absolutamente importante até que afete o próprio processo de liberação.
O fato importante é que a versão é totalmente testada, empacotada e pronta para ser enviada à produção, se necessário. Ao mesmo tempo, qualquer participante do projeto deve poder dar uma luz verde e liberar imediatamente o software para produção.
Se você usar um CD, o ciclo de vida do software pode ser representado da seguinte maneira:
Cada candidato a liberação é sempre preparado com antecedência. A pessoa decide se o candidato a lançamento também será indicado para produção. Os candidatos a liberação que não atingem a produção continuam a ser armazenados como artefatos, caso precisem ser utilizados no futuro.
Para sua informação, sobre entrega contínua, bem como sobre integração contínua, também foi escrito um livro inteiro, a partir do qual você pode descobrir os detalhes dessa metodologia.
Bônus: Implantação Contínua
A letra "D" no CD pode significar implantação de implantação, não entrega de entrega. Essa abordagem do processo de desenvolvimento é baseada na entrega contínua e essencialmente elimina a intervenção humana. Qualquer candidato à liberação, que passará em todos os testes e verificações de qualidade e será reconhecido como pronto, é imediatamente enviado para produção.
É certo que apenas um número muito pequeno de empresas é capaz de operar dessa maneira. A promoção à produção sem o envolvimento humano não deve ser tomada de ânimo leve, pois no momento em que escrevemos este artigo, muitas empresas nem praticam entrega contínua, sem mencionar a implantação contínua.
Você deve entender que cada abordagem subsequente ao processo de desenvolvimento se baseia na implementação da abordagem anterior.
Antes de avançar no caminho da melhoria, sua empresa deve garantir que cada uma das bases do processo seja realmente sólida. Na Codefresh, vimos muitas empresas que pretendiam mudar para tecnologias em nuvem, tentando converter suas tecnologias otimizadas para uso em data centers em pipelines de CI / CD, sem perceber que algumas dessas tecnologias estão desatualizadas hoje. Tentar implantar a implantação contínua sem adotar totalmente a entrega contínua está fadado ao fracasso.
A figura a seguir mostra quais estágios do processo de desenvolvimento e implementação de software de Alice, Bob, Charlie, David e Elizabeth cobrem CD e CI.
Certifique-se de abordar cada paradigma de desenvolvimento de software na ordem correta. Acredite que a introdução da entrega contínua é um objetivo muito realista, para o qual existem todas as ferramentas necessárias.
Um pouco de publicidade :)
Obrigado por ficar conosco. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando aos seus amigos o
VPS na nuvem para desenvolvedores a partir de US $ 4,99 , um
desconto de 30% para os usuários do Habr em um analógico exclusivo de servidores de nível básico que inventamos para você: Toda a verdade sobre o VPS (KVM) E5-2650 v4 (6) Núcleos) 10GB DDR4 240GB SSD 1Gbps de US $ 20 ou como compartilhar um servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).
Dell R730xd 2 vezes mais barato? Somente temos
2 TVs Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV a partir de US $ 199 na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US $ 99! Leia sobre
Como criar um prédio de infraestrutura. classe usando servidores Dell R730xd E5-2650 v4 custando 9.000 euros por um centavo?