Quais são as vantagens dos scripts de construção?

Automação.

Quando você estiver desenvolvendo, apenas nos projetos mais simples, o botão padrão "build" fará tudo que você precisa fazer; talvez seja necessário criar WS de APIs, gerar documentos, vincular-se a recursos externos, implantar as alterações em um servidor, etc. Alguns IDEs permitem personalizar o processo de compilação adicionando etapas ou construtores adicionais, mas isso significa apenas que você está gerando seu script de construção através das mercadorias do IDE.

Mas desenvolver um sistema não é apenas escrever código. Existem várias etapas envolvidas. Um script independente de IDE pode ser executado automaticamente, significando que:

• Quando você faz uma alteração no controle de versão, uma nova compilação pode ser iniciada automaticamente pelo servidor. Isso garantirá que você não tenha esquecido de enviar nada necessário para a compilação.

• Da mesma forma, depois que a compilação é feita, os testes podem ser executados automaticamente para ver se você quebrou alguma coisa.

• Agora, o restante da organização (QA, sysadmins) tem um produto criado que

  a) é perfeitamente reproduzível apenas a partir da versão de controle.

  b) é comum a todos eles.

Mesmo quando estou trabalhando como um homem, usei scripts para esse propósito; quando eu tivesse desenvolvido a correção, eu iria me comprometer com o SVN, exportar o SVN de volta para outro diretório e usar o script de construção para gerar a solução, que iria para os sistemas de pré-produção e depois para a produção. Se algumas semanas mais tarde (com a minha base de código local já mudada) alguém reclamasse de um bug, eu saberia exatamente qual revisão do SVN eu teria que fazer o checkout para depurar o sistema corretamente.

Como o código, um script de construção é executado pelo computador. Computadores são excepcionalmente bons seguindo um conjunto de instruções. De fato, (fora do código de auto-modificação), os computadores executarão a mesma sequência de instruções exatamente da mesma maneira, dada a mesma entrada. Isso oferece um nível de consistência que, bem, somente um computador pode corresponder.

Por outro lado, nós, polpa cheia de água, são simplesmente desprezíveis quando se trata de seguir os passos. Aquele cérebro analítico tem uma tendência a questionar tudo o que se encontra. "Ah ... eu não preciso disso", ou "Eu realmente uso essa bandeira? Eh ... eu vou ignorar isso." Além disso, temos uma tendência a sermos complacentes. Uma vez que fizemos algo algumas vezes, começamos a acreditar que conhecemos as instruções e não precisamos olhar para a folha de instruções.

De "O programador pragmático":

In addition, we want to ensure consistency and repeatability on the project. Manual procedures leave consistency up to change; repeatability isn't guaranteed, especially if aspects of the procedure are open to interpretation by different people.

Além disso, somos HILARIOSAMENTE lentos na execução de instruções (em comparação a um computador). Em um projeto grande, com centenas de arquivos e configurações, levaria anos para executar manualmente todas as etapas de um processo de criação.

Eu vou te dar um exemplo do mundo real. Eu estava trabalhando em alguns softwares incorporados, nos quais a maior parte do código era compartilhada em algumas plataformas de hardware diferentes. Cada plataforma tinha hardware diferente, mas a maioria do software era o mesmo. Mas havia pequenas peças específicas para cada hardware. Idealmente, as peças comuns seriam colocadas em uma biblioteca e vinculadas a cada versão. No entanto, as partes comuns não puderam ser compiladas em uma biblioteca compartilhada. Tinha que ser compilado com todas as configurações diferentes.

Inicialmente, eu compilei cada configuração manualmente. Levou apenas alguns segundos para alternar entre as configurações, e não foi tão grande de dor. Perto do final do projeto, um defeito crítico foi descoberto na parte compartilhada do código, onde um dispositivo essencialmente assumiria o barramento de comunicação. Isso foi ruim! Muito ruim. Eu encontrei o bug no código, consertei e recompilei todas as versões. Excepto um. Durante o processo de construção, me distraí e esqueci de um. Os binários foram liberados, a máquina foi construída e, um dia depois, recebi um telefonema dizendo que a máquina parou de responder. Eu verifiquei e descobri que um dispositivo havia bloqueado o ônibus. "Mas eu consertei esse bug!".

Eu posso tê-lo consertado, mas ele nunca chegou até aquele quadro. Por quê? Porque eu não tinha um processo de criação automatizado que criava todas as versões com um clique.

Se tudo o que você deseja fazer é <compiler> **/*.<extension> , os scripts de construção têm pouco propósito (embora seja possível argumentar que, se você vir um Makefile no projeto, sabe que pode construir com make ). A coisa é - projetos não-triviais geralmente requerem mais do que isso - no mínimo, você geralmente precisará adicionar bibliotecas e (conforme o projeto amadurece) configurar parâmetros de construção.

IDEs geralmente são pelo menos os configuráveis - mas agora o processo de compilação depende de opções específicas do IDE. Se você está usando o Eclipse , Alice prefere NetBeans , e Bob deseja usar o IntelliJ IDEA , você não pode compartilhar o configuração, e quando um de vocês pressiona uma mudança no controle de origem, eles precisam editar manualmente os arquivos de configuração criados pelo IDE dos outros desenvolvedores ou notificar os outros desenvolvedores para que eles façam eles mesmos (o que significa que haverá confirma onde a configuração do IDE está errada para alguns dos IDEs ...).

Você também precisa descobrir como fazer essa mudança em cada um dos IDEs usados pela equipe, e se um deles não for compatível com essa configuração específica ...

Agora, esse problema depende da cultura - seus desenvolvedores podem achar aceitável não escolher os IDEs. Mas os desenvolvedores que têm experiência com um IDE geralmente são mais felizes e eficientes ao usá-lo, e os usuários de editor de texto tendem a ser religiosamente fanáticos sobre suas ferramentas favoritas, então esse é um dos lugares onde você quer dar liberdade aos desenvolvedores - e construir sistemas permitem que você faça exatamente isso. Algumas pessoas podem ter uma preferência de sistema de compilação, mas não é tão fanática quanto as preferências de IDE / editor ...

Mesmo se você conseguir que todos os desenvolvedores usem o mesmo IDE - boa sorte para convencer o servidor de compilação a usá-lo ...

Agora, para as personalizações simples do processo de construção, os IDEs tendem a fornecer uma boa GUI. Se você quer coisas mais complexas - como arquivos de código de pré-processamento / geração automática antes da compilação - você normalmente terá que escrever um script de pré-construção em alguma área de texto básica dentro da configuração do IDE. Quais sistemas de compilação você ainda teria que codificar essa parte, mas você pode fazê-lo no próprio editor em que você escreve o código, e mais importante: a própria estrutura do sistema de compilação geralmente fornece algum suporte para organizar esses scripts.

Por fim, os sistemas de compilação são bons para mais do que apenas construir o projeto - você pode programá-los para executar outras tarefas que todos da equipe precisem executar. Em Ruby on Rails , por exemplo, há tarefas de sistema de compilação para executar migrações de banco de dados, para limpeza de arquivos temporários, etc. Colocar essas tarefas no sistema de compilação garante que todos na equipe possam realizá-las de forma consistente.

Muitos IDEs simplesmente empacotam os comandos usados para construir algo e depois geram um script e o chamam!

Por exemplo, no Visual Studio, você pode ver os parâmetros da linha de comando para uma compilação C ++ na caixa 'linha de comando'. Se você observar atentamente a saída da compilação, verá o arquivo temporário que contém o script de compilação que foi usado para executar a compilação.

Atualmente, é tudo MSBuild , mas ainda é executado diretamente pelo IDE.

Portanto, o motivo pelo qual você usa a linha de comando é que você está indo direto para a origem e ignorando o intermediário, um intermediário que pode ter sido atualizado ou exigir muitas dependências que você simplesmente não quer ou precisa servidor sem cabeçalho que atua como seu servidor integração contínua (CI).

Além disso, seus scripts fazem mais do que as etapas usuais orientadas ao desenvolvedor para as quais foram projetados. Por exemplo, após uma compilação, você pode querer que seus binários sejam empacotados e copiados para um local especial, ou um pacote de instalação criado ou uma ferramenta de documentação executada neles. Muitas tarefas diferentes são executadas por um servidor de CI que são inúteis em uma máquina de desenvolvedor, portanto, embora você possa criar um projeto IDE que execute todas essas etapas, será necessário manter duas delas - um projeto para desenvolvedores e outro para construções. Algumas tarefas de compilação (análise estática, por exemplo) podem demorar muito para que você não queira projetos de desenvolvedor.

Em suma, é apenas mais fácil - crie um script para fazer tudo o que você quer e é rápido e simples dar o pontapé inicial na linha de comando ou em uma configuração de servidor de compilação.

make

é muito mais fácil de lembrar e digitar do que

gcc -o myapp -I/include/this/dir -I/include/here/as/well -I/dont/forget/this/one src/myapp.c src/myapp.h src/things/*.c src/things/*.h

E os projetos podem ter comandos de compilação muito complexos. Um script de construção também tem a capacidade de apenas recompilar as coisas que foram alteradas. Se você quiser fazer uma compilação limpa,

make clean

é mais fácil e mais confiável, uma vez configurado corretamente, do que tentar lembrar de todos os lugares que um arquivo intermediário pode ter sido produzido.

É claro que, se você usar um IDE, também é fácil clicar em um botão de compilação ou limpeza. No entanto, é muito mais difícil automatizar a movimentação do cursor para um local específico na tela, especialmente quando esse local pode se mover se a janela se mover, do que automatizar um simples comando de texto.

De que outra forma você faria isso? A única outra maneira é especificar um longo comando de linha de comando.

Outra razão é que os makefiles permitem compilação incremental, o que acelera muito o tempo de compilação.

Makefiles também podem criar uma plataforma cruzada de processo de criação. O CMake gera scripts de construção diferentes com base na plataforma.

Editar:

Com um IDE, você está preso a um modo particular de fazer as coisas. Muitas pessoas usam o vim ou o emacs, embora não tenham muitos recursos semelhantes ao IDE. Eles fazem isso porque querem o poder que esses editores fornecem. Os scripts de construção são necessários para aqueles que não usam um IDE.

Mesmo para aqueles que usam um IDE, você pode querer realmente saber o que está acontecendo, portanto, o script de construção oferece os detalhes mais baixos de implementação que uma abordagem de GUI não tem.

Os próprios IDEs costumam usar scripts internamente também; o botão de execução é apenas outra maneira de executar o comando make.

As respostas acima cobrem um bom terreno, mas um exemplo do mundo real que eu gostaria de adicionar (que não posso adicionar como um comentário devido a nenhum karma) é da programação do Android.

Sou um desenvolvedor profissional de Android / iOS / Windows Phone e uso as APIs de serviços do Google (principalmente o Google Maps) como um lote .

No Android, esses serviços exigem que eu adicione um keystore , ou um tipo de arquivo de ID de desenvolvedor que informa ao Google que sou quem sou, para um console de desenvolvedor. Se meu aplicativo for compilado com um keystore diferente, a seção do Google Maps do aplicativo não funcionará.

Em vez de adicionar e gerenciar uma dúzia de keystores no console do desenvolvedor, apenas um deles pode ser usado para atualizar o aplicativo, incluo este keystore em nosso repositório seguro e uso o Gradle para informar ao Android Studio exatamente qual keystore usar ao construir para "debug" ou "release". Agora, só preciso adicionar dois keystores ao meu console de desenvolvedor do Google, um para "depuração" e outro para "release", e todos os membros da minha equipe podem clonar o repositório e desenvolver corretamente sem precisar entrar no dev console e adicionar o hash SHA do seu keystore particular, ou pior, fazendo-me gerenciá-los . Isso tem o benefício adicional de dar a cada membro da equipe uma cópia do keystore de assinatura, o que significa que, se eu estiver fora do escritório e uma atualização estiver agendada, um membro da equipe precisará seguir apenas uma pequena lista de instruções. atualização.

Construir automação como essa mantém os consistentes e reduz a dívida técnica reduzindo o tempo de configuração quando obtemos um novo desenvolvedor, uma nova máquina ou quando temos que refazer a imagem de uma máquina.

Construa vantagens de script:

• as alterações parecem com código (por exemplo, em um comando git diff), não como diferentes opções marcadas em um diálogo

• criando mais resultados do que uma compilação simples

Em alguns dos meus projetos anteriores, usei os scripts de construção para:

• gera a documentação do projeto (baseada em doxygen)
• compilação
• executar testes de unidade
• gera relatórios de cobertura de teste de unidade
• empacotar binários em um arquivo de versões
• gera notas de lançamento internas (com base em mensagens "git log")
• testes automatizados

Geralmente você pode chamar o botão "build" de maneira automatizada (o Visual Studio aceita argumentos de linha de comando, por exemplo). As pessoas escrevem scripts de construção assim que precisam de algo que o botão de compilação não pode fornecer.

Por exemplo, a maioria dos IDEs permite que você crie apenas uma plataforma por vez. Ou apenas uma linguagem por vez. Depois, há o que você faz com as saídas construídas: seu IDE pode transformá-las em um pacote de instalação?