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 “construir” fará tudo o que você precisa fazer; você pode precisar criar WS fora de APIs, gerar documentos, vincular a recursos externos, implantar as mudanças em um servidor, etc. Alguns IDEs permitem que você personalize o processo de construção adicionando etapas extras ou construtores, mas isso significa apenas que você está gerando seu script de construção por meio das commodities IDE.

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

• Quando você confirma uma alteração no controle de versão, um novo build pode ser iniciado automaticamente pelo servidor. Isso garantirá que você não se esqueça de comprometer nada necessário para a construção.

• Da mesma forma, após a conclusão da construção, os testes podem ser executados automaticamente para ver se você quebrou algo.

• Agora, o resto da organização (QA, administradores de sistemas) tem um produto integrado que

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

  b) é comum a todos eles.

Mesmo quando tenho trabalhado como uma equipe de um homem só, usei scripts para esse propósito; ao desenvolver a correção, eu me comprometeria com o SVN, exportaria o SVN de volta para outro diretório e usaria o script de construção para gerar a solução, que iria então para os sistemas de Pré-produção e depois para a Produção. Se algumas semanas depois (com minha base de código local já alterada) alguém reclamasse de um bug, eu saberia exatamente qual revisão de SVN teria que verificar para depurar o sistema adequadamente.

Comentários

• Esta é a melhor resposta IMHO. Todo mundo está certo com sua ideia, mas este realmente mostra porque você deseja criar scripts. Porque eles suportam automação que está avançando conforme seu projeto se expande, você economizará muito tempo.
• @Alexus Não apenas tempo, mas erros estúpidos também. 😉 ” A repetição leva ao tédio. O tédio leva a erros terríveis. Erros horríveis levam a: ‘ Eu gostaria de ainda estar entediado.’ ” (Você também poderia medir erros idiotas a tempo, mas ‘ s importante perceber que ‘ está economizando seu tempo devido a várias causas.)
• Mesmo para projetos individuais, executar um servidor Jenkins local para automatizar o ” construir em um diretório separado ” pode ajudar. Eu ‘ estou trabalhando em algo no Windows que preciso confirmar também compilações cruzadas, então ter Jenkins construindo e executando testes e, em seguida, construindo a versão compilada cruzada me deixa muito mais confiante ( e eficiente, é claro!) quando eu precisar lançar correções de bugs.
• Eu não ‘ não concordo com o argumento de compilações reproduzíveis. Existem tantas variáveis não controladas nos sistemas de compilação de hoje que é muito difícil obter compilações reproduzíveis. Seu argumento parece que você vai conseguir isso fora da caixa, o que não é totalmente verdade.
• @JonasGr ö ger Automation remove um dos maiores variáveis: humanos.

Como o código, um script de construção é executado pelo computador. Os computadores são excepcionalmente bons em seguir um conjunto de instruções. Na verdade, (fora do código de automodificação), os computadores executarão a mesma sequência de instruções exatamente da mesma maneira, com a mesma entrada. Isso oferece um nível de consistência que, bem, apenas um computador pode igualar.

Por outro lado, nós, sacos de carne cheios de água, somos simplesmente desprezíveis quando se trata de seguir as etapas. Esse incômodo cérebro analítico tende a questionar tudo o que encontra. “Oh … eu não preciso disso”, ou “Devo realmente usar este sinalizador? Eh … vou simplesmente ignorar isso. Além disso, temos tendência a ser complacentes. Depois de fazer algo algumas vezes, começamos a acreditar que conhecemos as instruções e não precisamos olhar a folha de instruções.

De “The Pragmatic Programmer”:

Além disso, queremos garantir consistência e repetibilidade no projeto. Os procedimentos manuais permitem que a consistência seja alterada; a repetibilidade não é garantida, especialmente se os aspectos do procedimento estão abertos à interpretação por pessoas diferentes.

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

Vou dar um exemplo do mundo real. Eu estava trabalhando com um software embarcado, onde a maior parte do código era compartilhado em algumas plataformas de hardware diferentes. Cada plataforma tinha um hardware diferente, mas a maior parte 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 podiam ser compiladas em uma biblioteca compartilhada. Tinha que ser compilado com cada configuração diferente.

No início, eu compilei manualmente cada configuração. Levou apenas alguns segundos para alternar entre configurações e não foi tão grande de uma dor. Perto do final do projeto, um defeito crítico foi descoberto na parte compartilhada do código, onde um dispositivo basicamente assumiria o barramento de comunicação. Isso foi RUIM! Muito ruim. Encontrei o bug no código, consertei-o e recompilei todas as versões. Excepto um. Durante o processo de construção, me distraí e esqueci um. Os binários foram lançados, a máquina foi construída e, um dia depois, recebo uma ligação dizendo que a máquina parou de responder. Eu verifiquei e descobri que um dispositivo havia bloqueado o ônibus. “Mas eu consertei aquele bug!”.

Posso ter consertado, mas ele nunca encontrou o caminho para aquele painel. Porque? Porque eu não tinha um processo de compilação automatizado que construía todas as versões com 1 clique.

Comentários

• E você pode ir tomar um café enquanto o script de compilação está em execução!

Se tudo o que você quer fazer é <compiler> **/*.<extension>, os scripts de construção têm pouca utilidade (embora se possa argumentar que se você vir um Makefile no projeto, sabe que pode construí-lo com make). A questão é – projetos não triviais geralmente exigem mais do que isso – no mínimo, você geralmente precisará adicionar bibliotecas e (conforme o projeto amadurece) configurar parâmetros de construção.

IDEs são geralmente pelo menos configuráveis – mas agora o processo de construção depende de opções específicas do IDE.Se você estiver usando o Eclipse , Alice prefere o NetBeans e Bob deseja usar o IntelliJ IDEA , você não pode “compartilhar a configuração, e quando um de vocês empurra uma mudança para o controle de origem, eles precisam editar manualmente os arquivos de configuração criados pelo IDE de os outros desenvolvedores, ou notificar os outros desenvolvedores para que eles próprios façam isso (o que significa que haverá commits 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 em particular …

Agora, esse problema depende da cultura – seus desenvolvedores podem achar aceitável não ter a escolha de IDEs. Mas os desenvolvedores que têm experiência com um IDE geralmente ficam mais felizes e mais eficientes ao usá-lo, e os usuários de editores de texto tendem a se tornar religiosamente fanáticos por seus favoritos para ols, então este é um dos lugares onde você deseja dar liberdade aos desenvolvedores – e construir sistemas permite que você faça exatamente isso. Algumas pessoas podem ter uma preferência de sistema de construção, mas não é tão fanático quanto as preferências de IDE / editor …

Mesmo se você fizer com que todos os desenvolvedores usem o mesmo IDE – boa sorte para convencer a construção servidor para usá-lo …

Agora, isso é para as personalizações do processo de construção simples, para as quais os IDEs tendem a fornecer uma interface gráfica agradável. Se você quiser coisas mais complexas – como pré-processamento / geração automática de arquivos de origem 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 para codificar essa parte, mas pode fazê-lo no próprio editor em que escreve o código e, mais importante: a própria estrutura do sistema de compilação geralmente fornece algum suporte para organizar esses scripts.

Finalmente – sistemas de construção são bons para mais do que apenas construir o projeto – você pode programá-los para fazer outras tarefas que todos na equipe possam precisar realizar. Em Ruby on Rails , por exemplo, existem tarefas do sistema de construção para executar migrações de banco de dados, para limpar os arquivos temporários, etc. Colocar essas tarefas no sistema de construção garante que todos na equipe possam realizá-las de forma consistente.

Comentários

• Isso ‘ não é apenas uma questão de IDEs diferentes. Alguns desenvolvedores odeiam e odeiam IDEs de todos os tipos.
• @DavidHammen Eu ‘ sou um desses desenvolvedores (embora eu ‘ tenha configurado meu Vim tão difícil é ‘ é possível que eu o tenha transformado em um IDE …), e enquanto escrevia aquele parágrafo, estava escrevendo automaticamente ” editores ” e tive que corrigi-lo no IDE, porque acho que o acessório em IDEs é uma parte importante da minha resposta. O autor da pergunta claramente vem do mundo dos IDEs, e a questão fala sobre o desenvolvimento sem IDE como algo que você é forçado a fazer quando não há um IDE adequado disponível. O objetivo desta resposta é mostrar como os sistemas de construção são benéficos até mesmo para equipes compostas exclusivamente de usuários de IDE.
• Eu também sou um desses desenvolvedores. Não ‘ não quero que meus dedos tenham que deixar o teclado. Fazer isso interrompe meus processos de pensamento.
• Eu discordo. Eu prefiro IDEs. Eles permitem que eu não me importe com nomes, pesquisas fáceis, refatoração, interface de usuário agradável. Quer dizer, se um IDE pode fazer algo por mim que eu faria com o sed ack etc, eu uso isso.
• O ponto é que com scripts de construção, cada desenvolvedor da equipe pode usar o que preferir, enquanto com a funcionalidade de compilação do IDE ‘ s, você está forçando todos não apenas a usar um IDE, mas também o IDE muito específico para o qual o projeto está configurado (a menos que você o tenha configurado para múltiplos IDEs e boa sorte para sincronizar isso …)

Muitos IDEs simplesmente empacotam os comandos usados para construir algo e, em seguida, gerar um script e chamá-lo!

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ê olhar atentamente para 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.

Hoje em dia, é tudo MSBuild , mas ainda é executado diretamente pelo IDE.

Portanto, a razão de usar a linha de comando é que você está indo direto para o código-fonte e pulando o intermediário, um intermediário que pode ter sido atualizado ou exigir um monte de dependências que você simplesmente não quer ou precisa em um servidor sem comando que atua como sua integração contínua (CI) servidor.

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 construçã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ê pudesse criar um projeto IDE que executasse todas essas etapas, você teria que manter duas delas – um projeto para desenvolvedores e outro para compilações. Algumas tarefas de construção (análise estática, por exemplo) podem levar muito tempo que você não gostaria para projetos de desenvolvedor.

Em suma, é apenas mais fácil – crie um script para fazer todas as coisas que você deseja e é rápido e simples iniciar isso 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 recompilar apenas as coisas que mudaram. 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 cada e todo lugar que um arquivo intermediário possa ter foi produzido.

Claro, se você usa um IDE, clicar em um botão construir ou limpar é fácil também. 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 comando de texto simples.

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

Outro motivo é que makefiles permitem compilação incremental, o que acelera muito o tempo de compilação.

Makefiles também podem fazer um processo de compilação entre plataformas. CMake gera diferentes scripts de compilação com base na plataforma.

Editar:

Com um IDE, você está vinculado a uma maneira particular de fazer as coisas. Muitas pessoas usam o vim ou emacs, embora não tenham muitos recursos semelhantes aos do IDE. Eles fazem isso porque querem o poder desses 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, então o script de construção oferece os detalhes mais baixos de implementação que uma abordagem de GUI não tem.

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

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

Sou um profissional Android / iOS / Windows Desenvolvedor de telefone, e eu uso APIs de serviços do Google (principalmente Google Maps) a 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 digo que sou, para um console de desenvolvedor. Se meu aplicativo for compilado com um armazenamento de chaves diferente, a seção do Google Maps do aplicativo não funcionará.

Em vez de adicionar e gerenciar uma dúzia de keystores para o console do desenvolvedor, apenas um dos quais pode realmente ser usado para atualizar o aplicativo de qualquer maneira, incluo este keystore em nosso repositório seguro e use o Gradle para informar ao Android Studio exatamente qual armazenamento de chaves usar ao construir para “depurar” ou “lançar”. Agora, eu só tenho que adicionar dois keystores ao meu console de desenvolvedor do Google, um para “debug” e um para “release”, e todos os membros da minha equipe podem clonar o repo e começar a desenvolver sem ter que ir para o dev console e adicione o hash SHA de seu armazenamento de chaves específico, 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 for agendada, um membro da equipe só precisa seguir uma lista muito curta de instruções para enviar um atualizar.

A automação de compilação como esta mantém as compilações consistentes e reduz o débito técnico ao reduzir o tempo de configuração quando temos um novo desenvolvedor, uma nova máquina ou quando temos que recriar uma máquina.

Vantagens do script de construção:

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

• criando mais saída do que uma construção simples

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

• gerar a documentação do projeto (baseada em doxygen)
• construir
• executar testes de unidade
• gerar relatórios de cobertura de teste de unidade
• compactar binários em um arquivo de lançamento
• gerar notas de lançamento internas (com base em mensagens “git log” )
• testes automatizados

Freqüentemente, você pode chamar o botão “construir” de forma automatizada (o Visual Studio aceita argumentos de linha de comando, por exemplo). As pessoas escrevem scripts de compilação assim que precisam de algo que o botão de compilação não pode fornecer.

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