Artigos Canal Mais Integração Contínua em .NET – Parte 2
Demais posts desta série:
Integração Contínua em .NET – Parte 1
Integração Contínua em .NET: Implementação – Parte 3

Artigo no estilo: Curso

Por que eu devo ler este artigo:A integração contínua (CI) é uma prática que vem se disseminando nas empresas como um todo, trazendo vantagens importantes como a automatização da parte repetitiva do trabalho do desenvolvedor, permitindo que se concentrem no que realmente importa: o desenvolvimento dos softwares.

Como vimos na primeira parte dessa série, a implementação da CI pode trazer alguns problemas, muitas vezes devido a erros nessa implementação. Nessa segunda parte iremos exemplificar alguns desses erros e mostrar como eles podem ser evitados e/ou resolvidos.

A integração contínua traz grandes vantagens para as empresas no que diz respeito a integração das diferentes partes do software sendo criado em equipe. Quem trabalha em equipe, sabe que um dos principais gargalos de tempo dentro do projeto é a integração de todas as partes, ao final.

Muitas vezes, todas essas partes, que funcionam perfeitamente individualmente, quando juntas acabam não trabalhando da mesma forma. Tal problema traz um atraso bastante grande, porque um ou mais membros da equipe precisam entender o que está acontecendo e corrigir esses problemas para que o sistema completo possa ser dado como concluído.

É daí que vem talvez a principal vantagem da integração contínua. Ela traz uma ideia na qual as partes são integradas constantemente durante o desenvolvimento.

Esse tipo de ação faz com que, quando o software é dado como concluído, ele funcione como um todo, e não apenas como partes. Essa atitude evita esse gargalo de tempo ao final do projeto, aumentando a produtividade e diminuindo o tempo de projeto, um ponto que todas as empresas procuram.

Porém, a CI não traz apenas benefícios e, ao longo desse artigo, iremos exibir alguns dos principais problemas que podem acontecer durante e depois da implementação desses processos. Veremos que todos eles podem ser evitados ou ao menos corrigidos, no caso de uma implementação correta.

Alguns deles, inclusive, existem apenas por uma falta de entendimento do que é e como funciona profundamente a integração contínua, e como aplicá-la adequadamente dentro da empresa.

Na primeira parte dessa série trouxemos alguns elementos básicos sobre a integração contínua e alguns passos de como implementá-la corretamente dentro das empresas.

Reparamos que a integração contínua consiste de uma série de fatores que precisam ser levados em conta, desde o estilo de trabalho da equipe de desenvolvimento até o hardware utilizado.

Além disso, trouxemos informações a respeito dos processos de desenvolvimento para integração contínua, bem como os tipos de construção (build) utilizados (contínuo, diário/noturno, semanal, QA (BOX 1), staging/pré-produção, release).

BOX 1. QA (Quality Assurance)

Essa sigla representa uma série de atividades que tem como objetivo final garantir a qualidade do software que está sendo avaliado. Como sabemos, a qualidade de um software não é medida apenas pelo fato de que ele faz o trabalho bem feito, e são medidos fatores para garantir que o software vá de encontro aos requerimentos do projeto.

Esse tipo de teste é aplicado para garantir que as funcionalidades estejam funcionando corretamente, que não haja nenhum tipo de bug dentro do sistema. Essas atividades são aplicadas no software antes da produção final.

A QA é baseada em alguns princípios que irão estabelecer a qualidade do software, dependendo do que está sendo medido. Alguns deles são a verificação se o produto está dentro dos parâmetros requeridos para o seu propósito e outra, obviamente, é se o software está totalmente livre de erros. Esses dois princípios são aplicados em virtualmente todos os softwares que passam por QA.

Outro ponto importante apresentado na primeira parte dessa série foram os passos para implementação da CI dentro da empresa. Vimos que a implementação da integração contínua é baseada em sete ciclos, e é muito importante que esses ciclos sejam respeitados para que haja uma implementação gradual no dia-a-dia da empresa. Esses ciclos são resumidos a seguir:

1º) Ciclo inicial, onde não há um servidor de build disponível para a empresa, fazendo com que todos os passos de construção e integração do software sejam realizados manualmente.

2º) O time dispõe de um servidor de build, sendo que a construção é automatizada para períodos regulares, em momentos que o fluxo de trabalho é baixo.

3º) O servidor já é capaz de aplicar alguns testes ao código, além de o build contínuo já estar sendo aplicado (toda vez que o código é comitado no SCM).

4º) Aplicação da verificação de qualidade de código (QA).

5º) O time está mais organizado e a integração contínua já começa a se encaixar às práticas de teste (TDD).

6º) A maioria dos principais testes já estão incluídas na CI, bem como ferramentas de relatórios e comunicação entre os membros da equipe.

7º) A integração contínua está integralmente implementada dentro da rotina da empresa, com tudo que se espera dela.

Agora que temos uma ideia mais clara sobre a integração contínua, vamos entender o que pode acontecer quando alguns dos passos são realizados de forma errada dentro das empresas. Além disso, vamos entender que, em um processo bem organizado e implementado, as vantagens da integração contínua são muito maiores do que eventuais distúrbios que ela possa trazer.

Objetivos e Vantagens da Integração Contínua

Conforme foi comentado, a integração contínua, uma vez implementada no dia-a-dia da empresa pode trazer inúmeros benefícios. Ao conhecer trabalhos de grandes companhias, temos uma ideia melhor do quão bom pode ser essa ferramenta para o andamento ...

Quer ler esse conteúdo completo? Tenha acesso completo