Integração contínua, ou CI, é uma prática de desenvolvimento de software onde o código é continuamente integrado (ao menos uma vez por dia, por desenvolvedor), e de forma automatizada. CI também diz respeito a verificar se o novo código que você escreveu quebrou ou não o que já estava funcionando, uma vez que testes automatizados e outras tarefas automatizadas (tais como verificações de sintaxe) são executadas quando integrando o código.
Utilizar tal abordagem permite que times de desenvolvimento de software tenham feedback rápido sobre as mudanças que estão fazendo em uma aplicação específica, além de ser uma maneira mais barata para correção de problemas quando estes são encontrados, visto que o código modificado ainda está fresco na memória dos desenvolvedores.
CI também é uma das práticas da disciplina de programação eXtrema, criada por Kent Beck e Ron Jeffries, em 1997. Após utilizarem CI (e outras práticas da XP) e terem bons resultados nos projetos nos quais trabalhavam, eles decidiram escrever a respeito, como uma forma de compartilhar tal conhecimento com o resto do mundo, para então, termos melhores softwares. Software que importa!
Um dos pontos cruciais ao utilizar CI é sobre a diminuição de conflitos quando integrando código. Uma vez que o código é frequentemente integrado (de um ramos específico para o ramo principal), ele tem menos chances de quebrar o que já existia. E mesmo que ele quebre algo que já funcionava, é mais fácil de resolver.
Outra questão importante quando se fala de CI é que tal prática precisa ser suportada por uma suite de testes automatizados (não apenas testes de unidade, mas também testes de integração, e ainda melhor, se possível, por testes end-to-end). Portanto, se você já está fazendo testes automatizados e ainda não está fazendo CI, te recomendo começar a pensar nisso como seu próximo passo.
Além disso, para ser competitivo no mercado, é muito bom quando você pode lançar novas funcionalidades que importam aos usuários mais rápido que seus concorrentes. Com isso, você tem vantagem competitiva e melhor time to market. Portanto, CI lhe permite praticar também outra tarefa muito importante nos dias de hoje, chamada entrega contínua.
Se você ficou interessado no assunto, recomendo que leia este artigo do Martin Fowler, onde ele explica integração contínua de maneira muito mais detalhada, e também melhor do que eu. =D
Espero que tenha gostado do post e aguardo teu feedback.
TALKING ABOUT TESTING 
Fala Walmyr !
Grande post! Sobre testes funcionais automatizados no seu processo de build. Você acaba colocando ele no processou ou deixa isso para rodar em separado?
Abraço!
Opa, atualmente estamos rodando estes testes junto com todos os outros. Ou seja, a cada pull request, mas isso porque o número de testes não é muito grande, portanto o custo de tempo de execução não prejudica o tempo do build.
Mas acho interessante pensar em um pipelines, onde se pode rodar um smoke test de testes de aceitação primeiro e então se estes passam, daí então rodar uma suite de testes de regressão, em um ambiente de staging, por exemplo. Isso pode ser importante quando a suite de testes de regressão é muito grande, e custosa com relação ao tempo de execução.