Mitos sobre os Métodos Ágeis - Continuous Integration /ou: Quem realmente integra?

Para quem não conhece, Continuous Integration (CI) é o processo automático de compilar e testar (usando os seus unit tests) seu software, este vindo do seu source control. O resultado, um monte de bolinhas vermelha e verde, é divulgado para a equipe de desenv para que eles possam identificar onde o código de um programador está dando pau na chamada no método do outro, por exemplo. Assim, os problemas de integração entre os componentes do sistema são identificados o mais rápido possível. Teoricamente...

CI é uma ferramenta extremamente útil e vale cada segundo gasto para por em prática e dizer que a CI não cumpre seu papel de identificar problemas na integração entre os programadores é injustiça. Mas o problema é que é preciso ir além da identificação de um bug e identificar onde esta realmente o problema. Começando na linha de código e terminando na arquitetura. E isso não é papel do programador. Não deixe que os programadores discutam o porquê as classes não se falam e como elas deveriam conversar. Não é o papel deles. Se os componentes não se comunicam, é porque o arquiteto não falou (documentou, escreveu, expressou, etc.) a intenção de forma correta, logo o problema pode ser maior do que um simples vermelhinho no report da CI.

Existem outras coisas que podem não colaborar com que a CI cumpra seu papel, apesar de não serem mitos propriamente. Primeiro, tem sempre o cara que não sobe as alterações dele para o source control e deixa para fazê-lo nos 45 do segundo tempo. A pratica de subir código (check-in) deve ser diária. Mas ai sempre vem a pergunta: “Mas e se eu não tiver terminado?” Terminado o que? Uma classe ou um método? Geralmente um método dá pra terminar no prazo de um dia, seja qual for o tamanho do método, e é isso que me interessa. O relatório enviado pelo servidor de CI não precisa mostrar tudo verde e sim ir mostrando verdes conforme a evolução do sistema, ou seja, deixar tudo para ultima hora não bem uma integração "continua".

Um outro problema chato, que chegamos a enfrentar, é que nosso ambiente era “quase” padronizado. Todos tinham a mesma estrutura de diretórios para os projetos, mas cada programador colocava essa estrutura em um drive ou diretório da sua escolha. Infelizmente, as ferramentas que usamos (VS2005, LLBLGen, etc.) sempre guardam algum tipo de caminho fixo. Ao subir esses arquivos para o source control, o servidor de CI (no nosso caso o CruiseControl.NET) pode não encontrar o caminho dos arquivos a serem compilados. Dica: padronize TOTALMENTE seu ambiente o mais rápido possível se você quiser usar CI.