Qual é a maneira correta de gerenciar scripts de desenvolvedor?

Os desenvolvedores criam scripts para ajudar em seu trabalho. Por exemplo, para executar o Maven com certos parâmetros, eliminar tarefas em segundo plano desnecessárias que surgem no desenvolvimento ou conectar-se a um determinado servidor. Os scripts não são scripts de construção principais nem são usados ​​em nosso servidor de Integração Contínua.

Qual é a melhor maneira de gerenciá-los? Para colocá-los em um diretório (talvez /scripts) e verificá-los no Git? Para mantê-los separadamente em algum servidor de arquivos?

O argumento para tratá-los como código-fonte é que eles são fonte e podem mudar. O argumento para não fazer isso é que elas são apenas ferramentas auxiliares e que nem todos os desenvolvedores precisam de um determinado script (por exemplo, scripts específicos do Linux, onde alguns desenvolvedores trabalham no Windows).

Os scripts de desenvolvedor também entram no controle de versão, porque geralmente esses scripts também dependem dos itens no controle de versão, por exemplo, caminhos de arquivo.

Se esses scripts são versionados, eles também devem trabalhar para todos os desenvolvedores, para evitar que cada desenvolvedor grave seu próprio conjunto de scripts, o que se torna um inferno de manutenção.

Além disso, as correções ou melhorias desses scripts são lançadas automaticamente para todos os desenvolvedores via controle de versão.

Além da resposta do @ simon.

Nem tudo na engenharia de software é sobre programação, design ou modelagem. Há uma infinidade de tarefas que realizamos continuamente durante o dia útil. Você já mencionou um - criando o projeto fora do IDE -, mas há muitos mais.

Desenvolvedores experientes / proativos tendem a automatizar essas tarefas. Alguns até constroem ferramentas quando essas tarefas se tornam parte do SDLC e são tediosas - e propensas a erros - a serem feitas manualmente. Os programas são bons em fazer trabalhos repetitivos, por mais tediosos que sejam. Nós - humanos - não somos tão bons.

Essas ferramentas / scripts têm outros efeitos colaterais positivos

1. Produtividade
2. Transferência de conhecimento
3. Autonomia (para iniciantes)

Portanto, sim, os scripts devem estar no SCM e devem ser mais uma ferramenta na caixa de ferramentas do desenvolvedor.

Em relação à pasta, /scriptseu diria que isso não importa. Para simplificar, deixo-os no diretório raiz do projeto, para que todas as rotas declaradas nos scripts sejam relativas à pasta do projeto. Se eu precisar de acesso a pastas ou arquivos externos, crio links diretos .

Pontos a considerar antes de verificar os scripts no SCM.

• Por segurança, verifique se os scripts não têm credenciais codificadas - idealmente, os scripts devem ser bem parametrizados -

• Certifique-se de que os scripts não façam coisas estranhas no sistema, como, por exemplo, para executar comandos que não podem ser desfeitos (o mais típico rm -rf).

• Uma vez que estes se tornam parte da fonte do projeto, a documentação é muito apreciada.

• Script não é ciência do foguete. Faça scripts concisos. Em vez de alguém para governá-los todos ... e na escuridão prendê-los , faça mais, menor e conciso. Como se você estivesse aplicando SRP.

Vou oferecer uma opinião um pouco mais negativa. Por um lado, é claro que os scripts de desenvolvedor genéricos, eficazes e úteis devem ser compartilhados com outros desenvolvedores, e a melhor maneira de fazer isso é fazê-los sentar com o código no mesmo repositório.

No entanto, eu definiria um nível alto de entrada para que os scripts fossem confirmados. Scripts são códigos, assim como o próprio software. Isso significa que eles precisam ser tratados de maneira semelhante a outros trechos de código:

• Passando pela revisão de código
• Testado e automatizado, se possível
• Considerado ao fazer alterações na base de código (especificamente, se um script for usado por muitos desenvolvedores, fazer uma alteração que quebre o script causará muitos problemas)
• Mantido (com tudo o que implica - priorização, tempo, documentação etc.).

Há várias considerações adicionais que se aplicam mais aos scripts do que ao próprio software:

• Em primeiro lugar, é muito mais difícil convencer a organização e as partes interessadas a investir na manutenção de scripts que facilitam a vida dos desenvolvedores. Isso significa que é mais difícil conseguir tempo para atender aos critérios acima - é fácil escrever um script que funcione para você em seu ambiente, mas parametrizá-lo, torná-lo estável e documentar leva muito mais tempo. Isso significa que os scripts podem e se tornarão código morto, a menos que um desenvolvedor possa justificar manter o script atualizado.
• É muito menos provável que vários desenvolvedores estejam familiarizados o suficiente com um script complicado para mantê-lo, ou que vários desenvolvedores sintam propriedade do código. Quando o desenvolvedor original sai, pode ser difícil encontrar outra pessoa para se apropriar (e encontrar e justificar o tempo para aprender como o script funciona pode ser ainda mais difícil).
• É muito mais provável que um script interaja com a máquina dos desenvolvedores e construa o ambiente de alguma maneira. Também é muito provável que você tenha vários desenvolvedores com vários ambientes diferentes. Se um script atrapalha um ambiente porque não foi mantido adequadamente ou não foi considerado um caso de esquina, você não está apenas quebrando uma compilação noturna do seu software, mas provavelmente está custando a um desenvolvedor um dia ou mais de trabalho para obtê-lo. ambiente de volta ao normal. Isso pode causar sangue ruim e perda de confiança.
• Como os scripts geralmente são externos ao próprio software, mantê-los pode ser um desafio. Se os scripts não são executados através de automações, é fácil que eles fiquem obsoletos ou sejam esquecidos; nesse ponto, eles se tornaram um código morto e são apenas dívidas técnicas que alguém precisará levar tempo para limpar.

Para resumir, os scripts podem ser muito úteis para um desenvolvedor individual, mas o compartilhamento como parte da própria base de código pode ser uma tarefa muito mais difícil e potencialmente causar mais problemas do que os resolvidos.