Integração contínua

A fim de compreender a importância da integração contínua, é útil discutir algumas questões problemáticas que surgem com frequência pela falta dela. Sem a integração contínua, os desenvolvedores precisam coordenar e comunicar à mão quando estão contribuindo com código para o produto final. Esta coordenação vai além das equipes de desenvolvimento até operações, bem como o restante da organização. As equipes de produto devem coordenar quando recursos e correções vão ser lançados em sequência e quais membros da equipe vão ser os responsáveis.

A comunicação excessiva em um ambiente sem integração contínua pode se tornar uma tarefa de sincronização complexa e intricada, que acrescenta custos burocráticos desnecessários ao projeto. Assim as versões de códigos ficam mais lentas e com maiores taxas de falha, pois requer que os desenvolvedores sejam sensíveis e cuidadosos com relação às integrações. Esses riscos crescem muito conforme o tamanho da equipe de engenharia e da base de código aumenta.

Sem um pipeline de integração contínua robusto, pode haver uma desconexão entre a equipe de engenharia e o restante da organização. A comunicação entre o produto e a engenharia pode ser complicada. A engenharia se tornar a caixa preta na qual o restante da equipe insere requerimentos e recursos e, talvez, obtenha os resultados esperados. Assim vai ser mais difícil para a engenharia estimar o tempo de entrega das solicitações, pois o tempo para integrar as novas alterações acaba sendo um risco desconhecido.

A IC ajuda a dimensionar a contagem de pessoas e a entrega de resultado das equipes de engenharia. A introdução da IC no cenário mencionado acima permite que os desenvolvedores de software trabalhem com autonomia nos recursos em paralelo. Quando estão prontos para mesclar esses recursos em um produto final, podem fazer isso com rapidez e autonomia. A IC é uma prática valiosa e bem estabelecida em organizações modernas de engenharia de software de alto desempenho.

A integração contínua costuma ser usada com o fluxo de trabalho de desenvolvimento de software ágil. Uma organização vai compilar uma lista de tarefas que contém um roteiro do produto. Essas tarefas são então distribuídas entre os membros da equipe de engenharia de software para a entrega. O uso da integração contínua permite que essas tarefas de desenvolvimento de software sejam desenvolvidas com autonomia e em paralelo entre os desenvolvedores atribuídos. Uma vez que essas tarefas são concluídas, um desenvolvedor vai inserir o novo trabalho no sistema de integração contínua para que seja integrado com o restante do projeto.

A integração, a implementação e a entrega contínuas são as três fases de um pipeline de versão de software automatizado, incluindo um pipeline de DevOps. Essas três fases conduzem o software desde a concepção até a entrega ao usuário final. A fase de integração é o primeiro passo no processo. A integração contínua abrange o processo de vários desenvolvedores na tentativa de fazer o merge das alterações de código com o repositório de código principal de um projeto.

A entrega contínua é a próxima extensão da integração contínua. A fase da entrega é responsável por preparar um artefato a ser entregue aos usuários finais. Esta fase executa ferramentas de criação automatizadas para gerar o artefato. Essa fase de criação é mantida "verde", que significa que o artefato deve estar pronto para ser implementado aos usuários a qualquer momento.

A implementação contínua é a fase final do pipeline. A fase de implementação se ocupa do lançamento e do oferecimento automáticos do artefato de software aos usuários finais. No momento da implementação, o artefato passou pelas fases de integração e de entrega. Agora é a vez de implementar ou distribuir o artefato a partir de programação. Essa etapa vai acontecer por meio de ferramentas e scripts programados que movem o artefato aos servidores públicos ou a qualquer mecanismo de distribuição, como uma loja de aplicativos.

A Integração contínua é um aspecto essencial do DevOps e das equipes de software de alto desempenho. Os benefícios da integração contínua não são limitados à equipe de engenharia, mas beneficia muito a organização como um todo. A integração contínua permite melhor transparência e insight no processo de desenvolvimento e entrega do software. Esses benefícios permitem que o restante da organização planeje e execute melhor as estratégias de mercado. A seguir, alguns dos benefícios organizacionais gerais da integração contínua.

A integração contínua permite que as organizações dimensionem o tamanho das equipes de engenharia, da base de códigos e a infraestrutura. Ao minimizar o excesso de burocracia de integração de código e de comunicação, a integração contínua ajuda a criar fluxos de trabalho de DevOps e ágeis. Assim cada membro da equipe pode ser dono de uma nova alteração de código definida até o lançamento. A integração contínua permite a escalabilidade ao remover quaisquer dependências organizacionais entre o desenvolvimento de recursos individuais. A partir de agora, os desenvolvedores podem trabalhar nos recursos em um silo isolado e ter a certeza de que os códigos vão ser integrados com perfeição ao restante da base de códigos, que é um processo central de DevOps.

Outro efeito colateral poderoso da integração contínua é o feedback mais rápido sobre decisões de negócios. As equipes de produto podem testar ideias e iterar os desenhos de produtos com mais rapidez com uma plataforma de integração contínua otimizada. As alterações podem ser enviadas e avaliadas com rapidez para obter êxito. Bugs e outros problemas podem ser analisados e solucionados com rapidez.

A integração contínua melhora a comunicação geral de engenharia e a prestação de contas, o que permite uma maior colaboração entre desenvolvimento e operações em uma equipe de DevOps. Ao inserir os fluxos de trabalho da solicitação pull vinculados à integração contínua, os desenvolvedores ganham compartilhamento de conhecimento passivo. As solicitações pull permitem que os desenvolvedores observem e comentem sobre código de outros membros da equipe. Os desenvolvedores podem agora visualizar e colaborar nas ramificações do recurso com outros desenvolvedores enquanto os recursos progridem pelo pipeline da integração contínua. A integração contínua também pode ser usada para ajudar no controle de qualidade do gasto do recurso. Um pipeline de integração contínua eficiente. com cobertura de teste automatizado de alta confiança, vai proteger contra regressões e garantir que os novos recursos correspondam a uma especificação. Antes que o novo código seja mesclado, ele precisa passar pelo suíte de asserção de testes de integração contínua, que vai prevenir quaisquer regressões novas.

Os benefícios da integração contínua superam de longe quaisquer desafios na adoção. Dito isto, é importante estar ciente dos desafios da integração contínua. Os desafios reais da integração contínua surgem ao passar uma forma de projeto sem integração contínua para integração contínua. A maioria dos projetos de software modernos vão adotar a integração contínua desde os estágios iniciais e amenizar os desafios de uma adoção posterior.

Os desafios da integração contínua estão, em grande parte, em torno da equipe de adoção e da instalação técnica inicial. Se, no momento, uma equipe não tem uma solução de IC em uso, pode ser um pouco difícil escolher uma solução e começar com ela. Sendo assim, são necessárias algumas considerações acerca da infraestrutura de engenharia existente ao instalar um pipeline de IC.

A funcionalidade da integração contínua vem com uma lista de tecnologias de suporte que podem ser investimentos de curva de aprendizagem a encargo da equipe. Essas tecnologias são sistemas de controle de versão, infraestrutura de hospedagem e tecnologias de orquestração.

Assim que um projeto estabelece um pipeline de IC com cobertura de teste automático, a prática recomendada é desenvolver e melhorar sempre a cobertura de teste. Cada novo recurso que segue pelo pipeline de IC deve ser acompanhado de um conjunto de testes para assegurar que o novo código se comporte como o esperado.

O Test Driven Development (Desenvolvimento orientado por teste, TDD) é uma prática de escrever o código de teste e os casos de teste antes de fazer qualquer código de recurso real. O TDD puro pode ter o envolvimento próximo da equipe de produto para ajudar a construir uma especificação de comportamento de negócios esperado, que pode ser então transformada em casos de teste. Em um cenário de TDD puro, os desenvolvedores e a equipe de produto podem se reunir e discutir sobre uma especificação ou uma lista de requerimentos. A lista de requerimentos pode então ser convertida em uma lista de verificação de asserções de código. Então, os desenvolvedores vão escrever o código que corresponda a essas asserções.

A maioria das equipes de desenvolvimento de software modernas praticam um fluxo de trabalho de análise de código e de solicitação pull. As solicitações pull são uma prática essencial para uma integração contínua eficaz. Uma solicitação pull é criada quando um desenvolvedor está pronto para mesclar um novo código à base de códigos principal. A solicitação pull notifica os outros desenvolvedores sobre o novo conjunto de alterações que estão prontas para integração.

As solicitações pull são o momento certo para o início do pipeline de integração contínua e da execução do conjunto de passos de aprovação automatizadas. Além disso, é comum o acréscimo de um passo de aprovação manual no momento da solicitação pull, durante o qual um engenheiro de parte não interessada executa uma análise de código do recurso. Assim é possível ter um novo olhar na análise o novo código e a funcionalidade. A parte não interessada vai fazer sugestões de edição e aprovar ou negar a solicitação pull.

As solicitações pull e a análise de código são ferramentas poderosas para manter um compartilhamento passivo de comunicação e de conhecimento entre a equipe de engenharia. Essas ferramentas ajudam na proteção contra o débito técnico na forma de silos de conhecimento, onde engenheiros específicos são as únicas partes interessadas para certos recursos da base de códigos.

Já que o pipeline de IC será um processo central e usado com frequência, é importante otimizar a velocidade da execução. Qualquer pequeno atraso no fluxo de trabalho da IC vai comprometer muito a taxa de crescimento das versões do recurso, do tamanho da equipe e do tamanho da base de dados. A prática recomendada é medir a velocidade do pipeline da IC e otimizar conforme necessário.

Um pipeline de IC mais rápido permite um ciclo de feedback do produto mais rápido. Os desenvolvedores podem enviar as alterações com mais rapidez e experimentar novas ideias de recurso para ajudar a melhorar a experiência do usuário. Qualquer reparação de bug pode ser corrigida e resolvida com rapidez assim que for descoberta. Esse aumento na velocidade da execução pode oferecer tanto uma vantagem sobre outros concorrentes como uma experiência de qualidade superior aos clientes.

A dependência fundamental da IC é um sistema de controle de versão (VCS). Se a base de códigos alvo para uma instalação de IC não tiver VCS, o primeiro passo é instalar um VCS. É muito pouco provável que em bases de códigos modernas não exista um VCS. Alguns VCSs populares são o Git, o Mercurial e o Subversion.

Assim que o controle de versão estiver em vigor, o próximo passo é encontrar uma plataforma de hospedagem de controle de versão. As ferramentas de hospedagem de controle de versão mais modernas têm suporte e recursos incorporados para IC. Algumas plataformas de hospedagem de controle de versão populares são o Bitbucket, o Github e o Gitlab.

Após os controles de versão terem sido estabelecidos no projeto, os passos de aprovação da integração devem ser adicionados. O passo de aprovação de integração mais valioso a ser colocado em vigor são os testes automatizados. Acrescentar testes automatizados ao projeto pode ter um custo inicial excessivo. Uma estrutura de testes tem que ser instalada; a seguir, o código e os casos de teste devem ser escritos pelos desenvolvedores.

Algumas ideias para adicionar outros mecanismos de aprovação de IC mais baratos são os verificadores de sintaxe, formatadores de estilo de código ou verificadores de vulnerabilidade de dependência. Assim que tiver um sistema de controle de versão definido, com alguns passos de aprovação de mescla em vigor, você estabeleceu uma integração contínua!

A IC não é apenas um processo de negócio específico de engenharia. O restante da organização, equipes de produto, marketing e vendas, também vão se beneficiar de um pipeline de IC. As equipes de produto precisarão pensar em como tornar paralela a execução de fluxos simultâneos de desenvolvimento. Produto e engenharia vão trabalhar próximos para determinar as expectativas que qualificam a funcionalidade do negócio que vão compor o suíte de testes automatizados.

Os setores de marketing e vendas vão poder consultar o pipeline da integração contínua para coordenar os esforços de comunicação e eventos voltados para o cliente. A integração contínua dá um nível de transparência ao restante da organização sobre como a execução da engenharia está progredindo. Essa utilidade de transparência e comunicação se integra com perfeição a um fluxo de trabalho de desenvolvimento de projeto ágil.

Se sua organização se esforça para colher os benefícios de uma abordagem DevOps ou simplesmente tem uma equipe de software com vários desenvolvedores, a integração contínua é importante. Ela vai ajudar sua organização de engenharia a executar com mais rapidez e eficácia.

A IC é um acessório padrão de organizações modernas de desenvolvimento de software de alta eficiência. As melhores empresas têm pipelines de IC robustos e não pensam duas vezes sobre outros investimentos em eficiência. Os benefícios da IC não se limitam à equipe de engenharia e são aplicáveis em toda a organização.

Existem muitas ferramentas de terceiros para ajudar na gestão e instalação de integração contínua. Algumas opções populares são: Codeship, Bitbucket Pipelines, SemaphoreCI, CircleCI, Jenkins, Bamboo, TeamCity e muitas outras. Essas ferramentas têm guias próprios de configuração detalhada e documentação para ajudar a começar.

Algumas das melhores ferramentas de integração contínua são disponibilizadas pela Atlassian:

O Bitbucket Pipelines é de grande utilidade para que os projetos estejam atualizados com recursos de integração contínua modernos.

O Jira é uma das ferramentas de gestão de projeto ágil e de DevOps mais populares do mundo. O Jira tem forte integração com outros projetos de Bitbucket e, quando acompanhado por um pipeline de integração contínua, pode dar uma visão muito transparente da integridade executiva de uma empresa.