Construções automatizadas, ferramentas de construção e sistemas embarcados

Para software incorporado, a Integração Contínua pode ser útil

• se você tiver testes (unitários) que possam ser executados em um ambiente de simulação ou
• se você tiver meios para executar atualizações automáticas do dispositivo de destino e ativar os testes automaticamente (incluindo os estímulos necessários).

No primeiro caso, você pode configurar um servidor de IC que cria periodicamente uma compilação para o destino da simulação e executa os testes nesse destino simulado automaticamente. No segundo caso, você precisaria conectar um destino real ao servidor de IC e depois criar periodicamente uma compilação e testá-lo.

A vantagem em ambos os casos é que você obtém testes automatizados, autônomos e de regressão que lhe dirão se você acidentalmente quebrou alguma coisa, mesmo que isso esteja em uma parte aparentemente não relacionada do software (que você não teria tocado com o seu testes manuais).

Há um zilhão de bons motivos para usar o CI em uma equipe incorporada (se você estiver trabalhando sozinho em seu IDE, as vantagens do CI são menos óbvias, eu no CI é integração e você não está se integrando a ninguém quando está trabalhando sozinho)

• Obriga você a ter um processo de criação automatizado, com script e repetitivo. A saída do seu sistema de CI é a saída que é testada e será consistente. Não importa o que os desenvolvedores possam instalar em suas máquinas, a construção não será afetada.

• A grande vantagem do CI é a capacidade de executar testes de unidade automatizados. Esses testes podem ser compilados na plataforma da máquina do CI. Isso tem o efeito colateral arquitetônico de desacoplar sua lógica dependente de hardware do restante, facilitando uma eventual porta para outra plataforma e facilitando a reutilização de código independente de plataforma para outro projeto.

• Ele fará com que o que todos se comprometerem com o controle de origem seja desenvolvido, e rapidamente fornecerá feedback quando isso não acontecer. Isso realmente acelera as coisas para saber qual commit quebrou a compilação.

• Isso dará à equipe de testes um lugar comum para obter a versão mais recente sem sobrecarregar a equipe de desenvolvimento. Ou para rapidamente bissectar um bug recém-descoberto que apareceu desde 2 semanas atrás ...

• Inspeção automatizada de código, métricas e ferramentas de análise podem acionar o aviso no código que foi verificado.

Normalmente, o fluxo de trabalho normalmente tem os produtos de construção disponíveis no servidor a serem exibidos na placa. No seu desenvolvimento diário, você usa o fluxo de trabalho de construção / flash do seu IDE. Eu não sei sobre o seu projeto, mas também é possível ter um script automatizado para fazer o flash do novo firmware na placa e então iniciar / parar os testes automaticamente na placa através de uma interface serial, por exemplo.