開発者スクリプトを管理する正しい方法は何ですか？

開発者は、作業を支援するスクリプトを作成します。たとえば、特定のパラメーターでMavenを実行したり、開発中に不要になったバックグラウンドタスクを削除したり、特定のサーバーに接続したりします。スクリプトはコアビルドスクリプトではなく、継続的インテグレーションサーバーでも使用されません。

それらを管理する最良の方法は何ですか？それらをディレクトリ（おそらく /scripts）に入れてGitにチェックインするには？いくつかのファイルサーバーでそれらを個別に維持するには？

それらをソースコードとして扱うための議論は、それらがソースであり、変更できるということです。それを行わないという議論は、それらが単なる補助ツールであり、すべての開発者が特定のスクリプト（たとえば、一部の開発者がWindowsで作業するLinux固有のスクリプト）を必要としないということです。

通常、これらのスクリプトはバージョン管理の項目（ファイルパスなど）にも依存するため、開発者スクリプトもバージョン管理に入ります。

これらのスクリプトがバージョン管理されている場合、すべての開発者が独自のスクリプトセットを作成することを避けるために、すべての開発者に対して機能するはずです。

さらに、これらのスクリプトのバグ修正または改善は、バージョン管理によってすべての開発者に自動的に展開されます。

@simonの答えに加えて。

ソフトウェアエンジニアリングのすべてがプログラミング、設計、またはモデリングに関するものではありません。仕事中に継続的に実行するタスクは無数にあります。IDEの外部でプロジェクトを構築するということについては既に言及しましたが、さらに多くのことがあります。

経験豊富なプロアクティブな開発者は、これらのタスクを自動化する傾向があります。いくつかは、これらのタスクがSDLCの一部になり、手作業で行うのが面倒で、エラーが発生しやすい場合にツールを構築することもあります。プログラムは、どんなに面倒でも、繰り返しの仕事をするのが得意です。私たち- 人間 -はそれほど良くありません。

これらのツール/スクリプトには他にもプラスの副作用があります

1. 生産性
2. 知識の移転
3. 自治権（新人向け）

したがって、はい、スクリプトはSCMにあり、開発者のツールボックスにあるもう1つのツールである必要があります。

フォルダに関しては/scripts、それは重要ではないと言うでしょう。簡単にするために、スクリプトで宣言されたすべてのルートがプロジェクトのフォルダーに関連するように、プロジェクトのルートディレクトリにそれらを残します。外部フォルダーまたはファイルにアクセスする必要がある場合は、ソフトリンクを作成します。

スクリプトをSCMにチェックインする前に考慮すべき事項。

• セキュリティのために、スクリプトにハードコードされた資格情報がないことを確認してください - 理想的には、スクリプトは十分にパラメータ化されるべきです -

• たとえば、元に戻せないコマンド（最も一般的なrm -rf）を実行するなど、スクリプトがシステムに対して奇妙なことをしないようにしてください。

• これらはプロジェクトのソースの一部になるため、ドキュメントを高く評価しています。

• スクリプトはロケット科学ではありません。スクリプトを簡潔にします。それらをすべて支配する代わりに...そして暗闇の中でそれらを縛り、より小さく、簡潔にする。SRPを適用しているかのように。

もう少し否定的な意見を申し上げます。一方で、一般的で効果的で有用な開発者スクリプトは、もちろん他の開発者と共有する必要があります。そのための最良の方法は、同じリポジトリ内のコードと一緒に配置することです。

ただし、スクリプトをコミットするためのエントリに高いバーを設定します。スクリプトは、ソフトウェア自体と同様にコードです。つまり、他のコードと同様に扱う必要があります。

• コードレビューを通過する
• 可能であればテストと自動化
• コードベースを変更する際に考慮します（具体的には、多くの開発者がスクリプトを使用している場合、スクリプトを壊すような変更を加えると多くの問題が発生します）
• 維持（必要なものすべて-優先順位付け、時間、文書など）。

ソフトウェア自体よりもスクリプトにより多く適用される、さらに多くの考慮事項があります。

• 何よりもまず、自分の組織や利害関係者に、開発者の生活を楽にするスクリプトの維持に投資するよう説得することははるかに困難です。つまり、上記の基準を満たす時間を確保するのは難しくなります。環境で動作するスクリプトを簡単に作成できますが、パラメータ化、安定化、ドキュメント化にはより多くの時間がかかります。これは、開発者がスクリプトを最新に保つことを正当化できない限り、スクリプトがデッドコードになる可能性があることを意味します。
• 複数の開発者がそれを維持するための複雑なスクリプトに十分に精通していることや、複数の開発者がコードの所有権を感じていることはほとんどありません。元の開発者が去るとき、所有権を取得する他の人を見つけることは困難です（そして、スクリプトがどのように機能するかを学ぶ時間を見つけて正当化することはさらに難しくなります）。
• スクリプトが開発者のマシンと相互作用し、何らかの方法で環境を構築する可能性がはるかに高くなります。また、複数の異なる環境を持つ複数の開発者がいる可能性が非常に高くなります。スクリプトが適切に維持されなかったため、またはコーナーケースが考慮されなかったために環境を台無しにした場合、ソフトウェアのナイトリービルドを壊すだけでなく、開発者に1日以上のコストをかけて潜在的に通常の環境に戻ります。これは、血液の不均衡と信頼の喪失を引き起こす可能性があります。
• 多くの場合、スクリプトはソフトウェア自体の外部にあるため、スクリプトを維持することは難しい場合があります。スクリプトが自動化によって実行されない場合、スクリプトが古くなったり忘れられたりするのは簡単です。その時点で、それらはデッドコードになり、誰かがクリーンアップするために時間をかける必要があるだけの技術的負債になります。

要約すると、スクリプトは個々の開発者にとって非常に役立ちますが、その場合、コードベース自体の一部として共有することははるかに困難なタスクとなり、解決されるよりも多くの問題を引き起こす可能性があります。