免責事項
これは、ネット上での最初の出版物の1つです。 私は議論される分野の専門家であるふりをしません、そして、決して私は記事を行動へのガイドとして位置づけません。 私は自分の小さな経験をまとめようとしましたが、自分の考えをhabrasocietyと共有したいと思います。
問題
製品が小さい限り、すべてが問題ありません。 小さなチームであり、誰もがお互いを直接知っています。 しかし、製品が数十個のモジュールに成長すると、各モジュールは個別の開発チームによって占有され、個別のQAチームでさえ最も重要なモジュールに割り当てられるとすぐに、すべてが非常に悲しくなります。 開発では、スクラムなどの方法論が適用され始めています。 製品のインストーラーは、別のチームの開発を開始します。 製品自体の重量は2GBを超え、コンパイルには約3時間かかります。 多くのカスタマイザーがメインストリームに含まれていない個人的な機能またはパッチを持ち、メイン製品モジュールの開発は完全に独立して行われるため、エンドユーザー向けの製品配布の組み立ては長い間些細な作業でなくなりました。 この時までに、あなたはこの製品をつぼみに覚えている人を見つけることはまずないでしょう。 それについて何かをする時、つまり新しいチームを作る時です。 Build Factoryと呼びましょう。
ビルドファクトリー
このチームは何ができますか？ 開発によって。 製品自体ではなく、インストーラーではなく、いわゆるBuild Frameworkです。 ドキュメントの保持を開始し、ルールを作成し、どのモジュールをどのモジュールに収集し、それを後でインストーラーにパックするかを考えます。 さて、それに応じて、プロセス全体を自動化します。 これは継続的インテグレーションと呼ばれます。 さらに詳しく考えてみましょう。
責任
Build Factoryは、次の責任を負います。
- ビルドスクリプト
事実上の標準として、Ant、Maven、CMakeなどの特別なツールをアセンブリに使用することが長い間行われていることは周知の事実です。 今後、Build Factoryはスクリプトの作成とサポートを行うことができます。 これにより、時間の経過とともに、モジュールを相互に統合するプロセスを完全に制御し始めます。以前は、各チームがそのモジュール用に独自のスクリプトを作成したとき、すべてが特に統一されておらず、モジュール間のモジュール統合が複雑でした。
- SCMサポート
製品ブランチの制御、そして実際には、製品のバージョン管理の制御は、Build Factoryがうまく実行できるタスクです。 繰り返しますが、異なる製品モジュールのバージョン管理は統一されているように見えるため、モジュール間の統合が容易になります。
- 継続的な統合
これは、Build Factoryの大部分の作業です。 開発者は、SCMでコードをコミットするだけで、それ以上はしないという考え方です。 他のすべてはビルドサーバーによって自動的に行われます。 Jenkins \ Hudson、ElectriCommander、Cruise Controlなど、優れたCIシステムがあります。これらはすべて、本質的に、Webインターフェイス、クラスター化機能、およびその他の機能を備えた1つの大きなクロスプラットフォームスケジューラーです。 誰かが興味を持っているなら、とりあえずシードについては次のように言うだけです。 ポイント1と2を完了した後、CIシステムをセットアップすると、開発プロセスは次のようになります。 開発者はコードをコミットし、スケジュールまたはトリガーに従ってCIシステム（たとえば、前回の正常なビルド以降にSCMに新しいコミットがある場合）ユニットテストを実行し、モジュールアセンブリスクリプトを実行します（プロジェクトアーキテクチャで許可されている場合は並行して実行可能）、結果を待機し、それらをパックしますインストーラーに送信し、インストーラーサーバーにアップロードします。 いくつかのテスト環境で正常にアセンブリした後、QAチームが親切に提供する自動テストを実行できます。また、手動テスト用に製品を準備できます（たとえば、Java Webアプリケーションの場合、テストTomcatに製品をインストールし、データベースにテストを入力します）データやそのようなもの）。 選択した開発方法論のフレームワーク内で必要な場合は、CIシステムを使用できます。 たとえば、QEは1つの大きなボタン「BUILD IT！」を押して、待機し、テストサーバーでテストするための製品の準備を整えることができます。 このように、一連の操作の後、製品を元の状態にリセットすることが非常に便利な場合があります。
- 犯人を検索
ビルドがクラッシュした場合、致命的なコミットを行った人をすばやく見つけることができるのはビルドファクトリです（ポイント3が正しく実行されている場合）。 これにより、通常の製品ライフサイクルを修正および復元するプロセスが高速化されます。
- 開発者サポート
すべての開発者が会社で使用されているSCMを正確に知っているわけではないことは秘密ではありません。 Build Factoryは、そのような人々をサポートするとともに、彼らのためのトレーニングを組織することができます。
- 製品リリース
開発方法に応じて、原則として、成功したビルドはリリースビルドと呼ばれます。 ただし、何らかの理由でこれが発生しない場合は、Build Factoryが特別なリリースビルド（および配布）の作成に関与している可能性があります。
ビルドマネージャーが知っておくべきこと
もちろん、それはすべてプロジェクトの仕様、言語、選択された開発方法論、スタッフの規模、チームの互いの地理的距離、および多くの要因に依存します。 それでも、共通の機能があります。
- 選択した方法論の枠組み内で開発プロセスがどのように行われるかを理解します。
- アセンブリ用のスクリプトを作成できます。
- CIシステムで作業できるようにします。
- ビルドスクリプトまたはCIシステムを使用してすべてのタスクを実行できるわけではないため、スクリプト言語または（さらに優れた）ネイティブ言語の知識を歓迎します。
- あなたは多くのコミュニケーションをとる必要があります。コミュニケーションスキルは非常に重要です。 想像してみてください。AntからMavenに、またはSVNからGitにすぐに切り替えるように複数のチームを説得する必要があるかもしれません。
結論
このアプローチにより、開発速度が大幅に向上します。 別々に組み立てられた製品モジュールの代わりに、単一のビルドフレームワークが各モジュールを統一された方法でビルドします。 また、CIの助けを借りて、QAチームは可能な限り迅速に新バージョンの製品を自由に入手できます。 言い換えれば、Build Factoryは、開発チームとQAチームの共通言語を見つけるのに役立ちます。