Este é o ambiente errado para o CI?

5

Plano de fundo

Tamanho da equipe / projeto

Atualmente na nossa empresa, temos uma equipe de três desenvolvedores. Cada um de nós tem nossos próprios projetos em que trabalhamos. Portanto, nunca temos mais de uma pessoa trabalhando em um projeto de desenvolvimento de software ao mesmo tempo. De vez em quando, podemos pedir a um desenvolvedor que modifique o projeto de outro desenvolvedor (meses ou anos no futuro).

Gerenciamento de projetos

Nós seguimos a metodologia da cascata de perto, e isso funciona bem para nós. Recebemos um conjunto de especificações de design de software que permanecem as mesmas por 30 anos (ou mais). De vez em quando pode ter havido um erro de digitação ou erro na especificação do projeto e os requisitos podem mudar um pouco, mas isso quase nunca acontece.

Acompanhamento de problemas

Recebemos bugs no nosso software, mas estes são normalmente reportados rapidamente pela nossa pequena base de usuários (10 - 15 pessoas) e corrigidos imediatamente. Em seguida, lançamos uma nova versão do software com as alterações integradas muito rapidamente e nunca mais precisaremos fazer nada por anos.

Controle de versão

Temos repositórios Git na unidade compartilhada da nossa empresa que usamos para manter as versões do software e acompanhar as alterações.

Pergunta

Eu trouxe a ideia de usar uma integração contínua com algo como Jenkins e foi dito que não seria necessário. Dado nosso ambiente, deveríamos estar usando CI?

Além disso, gostaria de saber como isso me afetará pessoalmente se eu nunca aprender CI.

    
por Snoop 11.04.2016 / 13:26
fonte

2 respostas

4

Escolha - Jenkins é uma ótima opção para o servidor de CI, é fácil de configurar e trabalhar. Não é preciso muito recurso do servidor.

O que a CI oferece é uma 'pessoa de compilação' computadorizada que pode pegar seu código de um repositório e compilá-lo sem sua ajuda. Se você sair ou for atropelado por um ônibus, isso significa que seu código ainda será utilizável sem os bits que você possa ter no seu computador que você esqueceu que tinha. Se você puder construí-lo no servidor de IC, será uma boa compilação reproduzível.

Este é o ponto principal para um servidor de IC. Claro, ele pode fazer mais do que isso, como executar testes ou criar compilações com as quais várias pessoas contribuíram, mas elas são secundárias ao objetivo principal de garantir que sua compilação possa ser criada por outra pessoa. Isso também significa que o que é necessário para que a sua construção funcione, ou seja, se você instalar alguma ferramenta e esquecer que ela está lá, o servidor de construção falhará ao ser lembrado e instalado (e esperamos que ele seja documentado) no servidor também. Seu servidor de compilação se torna um ambiente padrão ouro para a criação de seus produtos. Se você contratar um cara novo, ele poderá se atualizar apenas copiando as especificações do servidor de compilação.

Então: consiga um novo servidor (ou PC antigo por aí). Instale o Jenkins e todas as suas ferramentas de construção. Configure um trabalho Jenkins para cada um dos seus produtos para fazer o checkout do master e do build. Em seguida, observe o bonito painel da web que diz que cada produto foi criado com sucesso.

Se você quiser se interessar a partir desse ponto, poderá implantar em uma área de preparo para que seus produtos sempre sejam entregues consistentemente para oferecer suporte, adicionar análise estática, testes e outros itens interessantes. Sua apenas acrescentou qualidade e garantia de que tudo está funcionando corretamente. Você não vai olhar para trás.

    
por 11.04.2016 / 14:20
fonte
4

Eu acho que é um excelente mecanismo para usar. Você será capaz de confirmar que suas próprias construções (se ninguém mais) funcionarão em um ambiente isolado e reproduzível. Ele verifica se você se esquece de comprometer o trabalho em seu sistema SCM e se todos os builds e testes funcionam em um ambiente controlado, independentemente do seu ambiente pessoal. Se os testes demorarem a ser executados, ele descarregará o trabalho em outra máquina (supondo que você tenha um ambiente de CI separado) para que você possa continuar a trabalhar enquanto eles estão em execução, e você terá um histórico de suas compilações você pode identificar regressões e amarrá-las a commits.

Se sua empresa realmente não quiser fazer isso (e parecer muito míope), por que não apenas configurar seu próprio sistema de CI pessoal (em outra caixa, ou talvez como um ID de usuário diferente em sua caixa de desenvolvimento? ). Mesmo se os outros não quiserem se beneficiar do que foi dito acima, você pode.

    
por 11.04.2016 / 13:31
fonte