Há um problema fundamental sobre a integração contínua (IC) que é perfeitamente espelhado na sua pergunta: as práticas de IC são difíceis de implementar e defender, porque o software do servidor de CI não é trivial para configuração, nem é trivial para colocar seus projetos em execução por um IC servidor. Com isso, torna-se difícil realmente ver onde está o ganho em adotar o IC.
Antes de tudo, o IC trata de insight e qualidade. O bom IC aproxima você do seu projeto, fornece feedback adequado sobre métricas de qualidade, documentação, conformidade com os padrões de codificação etc. Ele deve fornecer as ferramentas para visualizar facilmente tudo isso e permitir que você reconheça e veja rapidamente associe um conjunto de alterações a um instantâneo específico de todas essas métricas do projeto.
Não se trata apenas de executar testes de unidade. De modo nenhum! O que me leva à qualidade. O IC adota erros, não os evita ou os joga fora. O que ele faz é simplesmente fornecer uma ferramenta para erros no início, em vez de mais tarde. Portanto, você realmente não confirma o código testado anteriormente em um servidor de IC. Embora você deva se esforçar para confirmar um código limpo e não quebrado, você realmente usa o servidor de IC para executar automaticamente um construtor de integração automaticamente através do seu código e avaliar se tudo deu certo. Se tiver, arrumado! Se não tiver, não há problema - as boas práticas de IC afirmam que sua próxima prioridade deve ser apenas corrigir o que está quebrado. O qual, em um bom servidor de CI, deve ser facilmente apontado para você.
À medida que o tamanho de uma equipe aumenta, a integração do código de todos naturalmente se torna mais difícil. Deveria ser tarefa de um servidor de IC centralizado testar todas as partes integradas e aliviar esse fardo dos membros da equipe. Portanto, você deve ter todos comprometidos o mais cedo possível (e da maneira mais limpa possível) e monitorando o status das compilações (geralmente há notificações envolvidas). E, novamente, se algo for quebrado por causa do comprometimento de algum desenvolvedor, torna-se imediatamente sua responsabilidade corrigir isso e recuperar essas construções automatizadas de volta ao status OK imediatamente.
Então você vê, na minha opinião, todo projeto se beneficia de ser continuamente integrado. O problema é que, até agora, e devido à complexidade incompreensível de cada servidor de CI que eu conheço, as pessoas realmente se opuseram às práticas de IC em projetos menores / mais simples. Porque, vamos lá, as pessoas têm coisas melhores a fazer do que passar dias configurando um software feio, excessivamente complexo, com entrega insuficiente e inchada.
Eu tive exatamente o mesmo problema, e foi isso que me levou a desenvolver o Cintient em meu tempo livre desde cerca de um ano atrás. Minha premissa era simplificar a instalação, a configuração e o uso, além de fornecer as métricas de qualidade que todos os demais praticamente falham ou fornecem de forma insuficiente. Então, após essa longa resposta, aparece meu ponto descarado de apontar o link do GitHub para o projeto (que é gratuito e de código aberto, natch). Ele também tem algumas imagens legais, aparentemente. :-) https://github.com/matamouros/cintient
Espero ter ajudado você.
(NOTA: Editado após o comentário de Bryan Oakley, sobre o fato de que eu deveria ter levado mais tempo para criar uma resposta melhor. Também acho que ele estava certo.)