Integração Contínua - Reduzindo Riscos

Há chances de que algo dê errado em um projeto. Ao praticar CI de maneira eficaz, você descobre o que acontece em cada etapa ao longo do caminho, e não mais tarde, quando o projeto está no ciclo de desenvolvimento. A CI ajuda a identificar e mitigar riscos quando eles ocorrem, tornando mais fácil avaliar e relatar sobre a integridade do projeto com base em evidências concretas.

Esta seção se concentrará nos riscos que podem ser evitados usando a Integração Contínua.

Em qualquer projeto, existem muitos riscos que precisam ser gerenciados. Ao eliminar os riscos no início do ciclo de vida de desenvolvimento, há menos chances de esses riscos se transformarem em problemas mais tarde, quando o sistema realmente entrar em operação.

Risco 1 - Falta de software implantável

“It works on my machine but does not work on another”- Esta é provavelmente uma das frases mais comuns encontradas em qualquer organização de software. Por causa do número de alterações feitas nas compilações de software diariamente, às vezes há pouca confiança se a compilação do software realmente funciona ou não. Essa preocupação tem os seguintes três efeitos colaterais.

Pouca ou nenhuma confiança se poderíamos construir o software.
Longas fases de integração antes de entregar o software internamente (ou seja, equipe de teste) ou externamente (ou seja, cliente), durante as quais nada mais é feito.
Incapacidade de produzir e reproduzir compilações testáveis.

Solução

Eliminando o acoplamento estreito entre o IDE e os processos de construção. Use uma máquina separada exclusivamente para integrar o software. Certifique-se de que tudo o que você precisa para construir o software está contido no repositório de controle de versão. Finalmente, crie um sistema de Integração Contínua.

O servidor de Integração Contínua pode observar as alterações no repositório de controle de versão e executar o script de construção do projeto quando detectar uma alteração no repositório. A capacidade do sistema de Integração Contínua pode ser aumentada para incluir a execução do build por meio de testes, realização de inspeções e implantação do software nos ambientes de desenvolvimento e teste; assim você sempre tem um software funcionando.

“Inability to synchronize with the database”- Às vezes, os desenvolvedores não conseguem recriar o banco de dados rapidamente durante o desenvolvimento e, portanto, têm dificuldade para fazer alterações. Freqüentemente, isso ocorre devido à separação entre a equipe de banco de dados e a equipe de desenvolvimento. Cada equipe estará focada em suas próprias responsabilidades e terá pouca colaboração entre si. Essa preocupação tem os seguintes três efeitos colaterais -

Medo de fazer alterações ou refatorar o banco de dados ou o código-fonte.
Dificuldade em preencher o banco de dados com diferentes conjuntos de dados de teste.
Dificuldade em manter ambientes de desenvolvimento e teste (por exemplo, Desenvolvimento, Integração, QA e Teste).

Solução

A solução para o problema acima é garantir que a colocação de todos os artefatos do banco de dados no repositório de controle de versão seja realizada. Isso significa tudo o que é necessário para recriar o esquema e os dados do banco de dados: scripts de criação de banco de dados, scripts de manipulação de dados, procedimentos armazenados, acionadores e quaisquer outros ativos de banco de dados são necessários.

Reconstrua o banco de dados e os dados de seu script de construção, eliminando e recriando seu banco de dados e tabelas. Em seguida, aplique os procedimentos armazenados e gatilhos e, finalmente, insira os dados de teste.

Teste (e inspecione) seu banco de dados. Normalmente, você usará os testes de componentes para testar o banco de dados e os dados. Em alguns casos, você precisará escrever testes específicos do banco de dados.

Risco 2 - Descoberta de defeitos mais tarde no ciclo de vida

Uma vez que há tantas mudanças que acontecem com frequência por vários desenvolvedores no código-fonte, sempre há chances de que um defeito possa ser introduzido no código que só poderia ser detectado em um estágio posterior. Nesses casos, isso pode causar um grande impacto, pois quanto mais tarde o defeito for detectado no software, mais caro se torna a remoção do defeito.

Solução

Regression Testing- Este é o aspecto mais importante de qualquer ciclo de desenvolvimento de software, teste e teste novamente. Se houver alguma alteração importante no código do software, é absolutamente obrigatório garantir que todos os testes sejam executados. E isso pode ser automatizado com a ajuda do servidor de Integração Contínua.

Test Coverage- Não faz sentido testar se os casos de teste não cobrem toda a funcionalidade do código. É importante garantir que os casos de teste criados para testar o aplicativo sejam completos e que todos os caminhos de código sejam testados.

Por exemplo, se você tem uma tela de login que precisa ser testada, você simplesmente não pode ter um caso de teste que tem o cenário de um login bem-sucedido. Você precisa ter um caso de teste negativo em que um usuário insere uma combinação diferente de nomes de usuário e senhas e, em seguida, é necessário ver o que acontece em tais cenários.

Risco 3 - Falta de Visibilidade do Projeto

Os mecanismos de comunicação manual requerem muita coordenação para garantir a disseminação das informações do projeto às pessoas certas em tempo hábil. Inclinar-se para o desenvolvedor próximo a você e informá-lo de que a compilação mais recente está no drive compartilhado é bastante eficaz, mas não é muito escalável.

E se houver outros desenvolvedores que precisam dessas informações e eles estão em uma pausa ou indisponíveis? Se um servidor cair, como você é notificado? Alguns acreditam que podem atenuar esse risco enviando manualmente um e-mail. No entanto, isso não pode garantir que as informações sejam comunicadas às pessoas certas no momento certo, porque você pode, acidentalmente, deixar de fora as partes interessadas, e algumas podem não ter acesso ao e-mail no momento.

Solução

A solução para esse problema é novamente o servidor de integração contínua. Todos os servidores de CI têm a facilidade de ter e-mails automatizados para serem disparados sempre que as compilações falharem. Por meio desta notificação automática a todos os principais interessados, também é garantido que todos estão a bordo sobre o estado atual do software.

Risco 4 - Software de baixa qualidade

Existem defeitos e, em seguida, defeitos potenciais. Você pode ter defeitos potenciais quando seu software não é bem projetado ou se não está seguindo os padrões do projeto, ou é complexo de manter. Às vezes, as pessoas se referem a isso como código ou cheiro de design - “um sintoma de que algo pode estar errado”.

Alguns acreditam que software de qualidade inferior é apenas um custo de projeto diferido (após a entrega). Pode ser um custo de projeto adiado, mas também leva a muitos outros problemas antes de você entregar o software aos usuários. Código excessivamente complexo, código que não segue a arquitetura e código duplicado - todos geralmente levam a defeitos no software. Encontrar esses odores de código e design antes que se manifestem em defeitos pode economizar tempo e dinheiro e pode levar a software de alta qualidade.

Solução

Existem componentes de software para realizar uma verificação da qualidade do código que podem ser integrados ao software CI. Isso pode ser executado depois que o código é construído para garantir que o código realmente está em conformidade com as diretrizes de codificação adequadas.