Se você estiver realizando um projeto solo - usaria ferramentas de CI para criar a partir de um repositório? Eu usei o Hudson e o Cruise Control em um ambiente de equipe, onde é essencial criar assim que alguém fizer o check-in.
Eu acho que o valor do controle de versão ainda é óbvio, mas preciso construir após cada confirmação, já que eu teria construído apenas na minha máquina local e ninguém mais está comprometendo?
Respostas:
Bem, estou planejando usar uma ferramenta de integração contínua em um projeto e sou o desenvolvedor exclusivo. A necessidade vem porque
Além da preparação entre plataformas e trabalho em equipe, não vejo a necessidade. O principal é ter algum tipo de software de controle de origem e ter vários repositórios para manter os backups. Isso o ajudará a configurar as ferramentas de construção em torno dele, quando necessário.
Sobre o tempo de compilação, estou usando o Mercurial e configurando um repositório de integração que não é o repositório de trabalho em equipe. Portanto, faça alterações no repositório de trabalho em equipe até que chegue a hora de fazer o sistema de integração tentar construir. Depois, passo do repositório de trabalho em equipe para o repositório de integração e isso acionará a compilação. Também adiciono um script que puxará o repositório de trabalho em equipe no repositório de integração uma vez por dia.
Aqui, estou assumindo que trabalho quase todos os dias no meu projeto, mas nem sempre é verdade. Você deve definir um tempo de construção que seja relativo à frequência com que você precisa de construções. Em uma empresa de jogos em que trabalhei anteriormente, usamos o CruiseControle e ele criava uma compilação completa a cada hora. Também poderíamos forçar uma construção sempre que quiséssemos, se necessário.
Para um projeto doméstico, uma vez por dia já pode ser "frequentemente". O principal requisito seria permitir facilmente que o usuário force o lançamento de uma compilação.
Após uma breve contemplação, eu sugeriria que poderia ser ainda mais importante para um desenvolvedor solo do que para uma equipe.
No nível mais básico, um servidor de IC demonstra que você pode criar seu aplicativo a partir do zero a partir da origem confirmada - combinado com um conjunto decente de testes, deve demonstrar que é possível criar e executar a partir do zero.
Como uma das coisas que tento fazer é garantir que minha compilação inclua um pacote implantável, você também saiba que pode obter algo para implantar (limpo e com um estado / versão conhecido).
De fato, agora, ao fazer o File | New Project, você provavelmente deve incluir a criação ou a adição ao seu repositório e a configuração do script de construção do CI e a configuração de implantação (mesmo que isso seja apenas para compactar um monte de coisas para a implantação do xcopy)
Adendo (2016) - hoje em dia meu sistema de IC também fará parte integrante do meu processo de implantação, por isso seu valor aumentou e eu absolutamente não executarei nenhum projeto de entrega sem ele. A implantação automatizada de botões de pressão elimina muito o processo e, de alguma forma, molda ou forma um servidor de compilação é essencial para isso.
Quando eu sou o único que está cometendo, eu apenas construo e testo antes de realmente confirmar. Eu costumo usar um destino makefile como:
make sense
Isso configura, constrói, executa todos os testes (ciente do valgrind), executa fiapos etc. Como eu sei que serei o único a pressionar, eu realmente não preciso do poder de algo como Hudson.
Além disso, em um ambiente em que você tem várias ramificações alimentando um repositório principal, se todos seguirem o comando sempre antes de confirmar ou enviar, o servidor de IC pode estar um pouco exagerado. Uma regra bem escrita de que o autor de tudo o que quebrou a última compilação compra pizza na sexta-feira geralmente mantém as coisas funcionando muito bem :)
Se ocorrer uma situação em que um projeto esteja claramente dividido em subsistemas com seus próprios líderes, você realmente precisará considerar o uso de algo como Hudson. Alguém pode testar localmente, perder uma corrida com outro subsistema e acabar empurrando algo tóxico.
Além disso, se você estiver mantendo um garfo de um projeto em movimento rápido (por exemplo, seu próprio conjunto de correções no kernel do Linux), considere realmente usar algo como o Hudson, mesmo estando 'solo' nesse projeto. Isto é especialmente verdade se você ramificar / re-basear diretamente da linha principal.
make: don't know how to make sense. Stop. Argh!
Eu não diria que isso é apenas um bônus, eu diria que é vital para a engenharia de software de alta qualidade para nós artistas solos por aí. A maioria de nós deixará os padrões de qualidade caírem um pouco, se tiverem pressa de achar que é fácil corrigi-lo mais tarde. Se você confirmar o software nesse estado, basicamente terá uma base de código sem valor armazenada em seu controle de origem.
Se respeitado adequadamente (ou seja, você não pula os testes e garante que ele seja compilado toda vez que efetua o commit), o CI obriga a aderir a um padrão de qualidade mais alto do que você faria se o fizesse de qualquer maneira.
É importante se você deseja reduzir o tempo de espera para ver se tudo ainda está indo bem. Embora você possa fazer com que o seu IDE compile coisas para você assim que salvar, ele não executa automaticamente os testes de unidade; portanto, meu servidor de CI executa os testes de unidade e os relatórios de cobertura de casos de teste e outras análises de qualidade do meu código assim que o salvar. Eu empurro isso.
O único gatilho que preciso fazer é enviar minhas alterações atuais para o controle de versão e posso voltar à codificação. E, enquanto penso em codificação, o sistema de IC está ocupado produzindo os longos relatórios de qualidade, que examinarei de vez em quando quando meu cérebro parar de funcionar.
Eu tenho uma máquina VMWare separada no mesmo laptop que constrói o código que forneço. Para fazer isso, basta obter uma imagem do Turnkey Linux VMWare e instalar os jenkins usando o apt-get e fazer algumas pequenas alterações na configuração.