build-process - リリースプロセスの改善

Question

新しいビルドを作成して本番環境にリリースするプロセスは、SDLCの重要なステップですが、多くの場合、後付けとして残され、会社ごとに大きく異なります。

私は、人々が組織内でこのプロセスに対して行った改善を共有し、私たち全員が「痛みを軽減する」ための措置を講じることができるようになることを望んでいます。

ですから、問題は、リリースプロセスの苦痛で時間のかかる部分を1つ特定し、それを改善するために何をしたかということです。

私の例：以前の雇用主では、すべての開発者が1つの一般的な開発データベースでデータベースを変更しました。次に、リリース時期になると、RedgateのSQL Compareを使用して、DevデータベースとQAデータベースの違いから巨大なスクリプトを生成しました。

これはかなりうまく機能しますが、このアプローチの問題は次のとおりです。

1. Devデータベースのすべての変更が含まれ、そのうちのいくつかはまだ「進行中」である可能性があります。
2. 開発者が競合する変更を行うことがありました（リリースが本番環境に入るまで気付かれませんでした）
3. スクリプトを作成して検証するのは、時間のかかる手動のプロセスでした（つまり、検証するということは、問題1や2などの問題を取り除くことを試みてください）。
4. スクリプトに問題があった場合（たとえば、スクリプト内にあるがまだ実行されていない外部キーレコードに依存するレコードの作成など、実行の順序）、スクリプトを「微調整」してスムーズに実行するのに時間がかかりました。 。
5. これは、継続的インテグレーションにとって理想的なシナリオではありません。

したがって、解決策は次のとおりです。-

1. データベースへのすべての変更のポリシーを適用するには、スクリプトを作成する必要があります。
2. スクリプトの正しい実行順序を確保するには、命名規則が重要でした。
3. ツールを作成/使用して、リリース時にスクリプトを実行します。
4. 開発者は、データベースの独自のコピーを開発しました（したがって、「お互いに足を踏み入れる」ことはもうありませんでした）

このプロセスを開始した後の次のリリースは、問題が少なく、はるかに高速でした。実際、見つかった問題は、スクリプトを作成しないなど、人々が「ルールを破った」ことによるものだけでした。

QAへのリリースに関する問題が修正された後、本番環境へのリリースの時期になると、非常にスムーズになりました。

他のいくつかの変更（CIの導入など）を適用しましたが、これが最も重要であり、全体として、リリース時間を約3時間から最大10〜15分に短縮しました。

Answer 1

ビルドプロセスを改善するために、過去1年ほどでいくつかのことを行いました。

1. 完全に自動化された完全なビルド。私たちは常に毎晩「ビルド」を行ってきましたが、ビルドを構成するものにはさまざまな定義があることがわかりました。コンパイルすると考える人もいますが、通常は単体テストが含まれ、場合によっては他のものも含まれます。自動ビルドは、ソース管理から顧客に提供するものに至るまでに必要なすべてを文字通り実行することを社内で明確にしました。さまざまなパーツを自動化すればするほど、プロセスが改善され、リリース時に手動で行う必要が少なくなります（そして、何かを忘れる心配が少なくなります）。たとえば、ビルドバージョンはすべてにsvnリビジョン番号をスタンプし、いくつかの異なる言語で実行されたさまざまなアプリケーションパーツをコンパイルし、単体テストを実行し、コンパイル出力を適切なディレクトリにコピーしてインストーラーを作成します。

2. コードが完了してからリリースされるまでの遅延。時間の経過とともに、特定のリリースのコーディングが終了してからそのリリースが顧客に届くまでの遅延の量を徐々に増やしてきました。これにより、テスターがあまり変更されていない製品をテストするためのより多くの専用時間が提供され、より安定した製品リリースが生成されます。ここではソース管理のブランチ/マージが非常に重要であるため、テスターが最後のリリースで作業している間に、開発チームが次のバージョンで作業できます。

3. 支店の所有者。コードを分岐してリリースブランチを作成し、次のリリースのトランクで作業を続けたら、ブランチに適用されたすべての修正の検証を担当する単一のローテーションリリースブランチの所有者を割り当てます。サイズに関係なく、すべてのチェックインは2人の開発者がレビューする必要があります。

Answer 2

単体テストを含むビルドを行うために、すでにTeamCity（優れた継続的インテグレーションツール）を使用していました。言及されていた3つの大きな改善がありました：

1）キットとワンクリックUAT展開をインストールします

NSISを使用してアプリをインストールキットとしてパッケージ化しました（MSIではありません。MSIは非常に複雑で、ニーズには不要でした）。このインストールキットは、IISの停止、ファイルのコピー、構成ファイルの適切な場所への配置、IISの再起動など、必要なすべてを実行しました。次に、psexecを使用してテストサーバー上でそのインストールキットをリモートで実行するTeamCityビルド構成を作成しました。

これにより、データベースの変更が含まれていない限り、テスターはUATの展開を自分で行うことができましたが、コードの変更よりもはるかにまれでした。

もちろん、本番環境への展開はより複雑で、それほど自動化することはできませんでしたが、同じインストールキットを使用したため、UATと本番環境の一貫性が確保されました。何かが足りないか、適切な場所にコピーされていない場合、通常はUATで取得されます。

2）データベース展開の自動化

データベースの変更を展開することも大きな問題でした。すでにすべてのDB変更のスクリプトを作成していましたが、どのスクリプトがすでに実行され、どのスクリプトを実行する必要があり、どの順序で実行する必要があるかを知るにはまだ問題がありました。このためのいくつかのツールを検討しましたが、最終的には独自のツールを使用することになりました。

DBスクリプトは、リリース番号ごとにディレクトリ構造に編成されていました。スクリプトに加えて、開発者はスクリプトのファイル名をテキストファイルに追加する必要がありました。1行に1つのファイル名で、正しい順序が指定されています。このファイルを処理し、特定のDBに対してスクリプトを実行するコマンドラインツールを作成しました。また、実行したスクリプト（およびいつ）をDBの特別なテーブルに記録し、次回はそれらを再度実行しませんでした。つまり、開発者はDBスクリプトを追加し、その名前をテキストファイルに追加して、最後に実行したスクリプトを他の人に尋ねることなく、UATDBに対してツールを実行できます。本番環境では同じツールを使用しましたが、もちろん、リリースごとに1回だけ実行されました。

これを実際にうまく機能させた追加の手順は、ビルドの一部としてDBデプロイメントを実行することです。私たちの単体テストは、実際のDB（データが最小限の非常に小さいDB）に対して実行されました。ビルドスクリプトは、以前のリリースからDBのバックアップを復元してから、現在のリリースのすべてのスクリプトを実行して、新しいバックアップを作成します。（実際には、パッチリリースもあり、バックアップはフルリリースに対してのみ実行されたため、少し複雑でしたが、ツールはそれを処理するのに十分スマートでした。）これにより、すべてのビルドでDBスクリプトが一緒にテストされ、開発者が競合するスキーマ変更を行った場合、それはすぐに検出されます。

手動の手順はリリース時のみでした。ビルドサーバーでリリース番号を増やし、「現在のDB」バックアップをコピーして「最後のリリース」バックアップにしました。それを除けば、ビルドで使用されるDBについて心配する必要がなくなりました。UATデータベースをバックアップから復元する必要がある場合もありましたが（たとえば、システムが削除されたDBスクリプトの変更を元に戻すことができなかったため）、それはかなりまれでした。

3）リリースのための分岐

それは基本的なことのように聞こえ、言及する価値はほとんどありませんが、そもそもこれを行っていませんでした。変更を元に戻すのは確かに苦痛ですが、今日のリリースと来月のリリースで単一のコードベースを使用するほどの苦痛ではありません。また、リリースブランチに最も多くの変更を加えた人にマージを行わせました。これは、リリースブランチのコミットを最小限に抑えるように全員に思い出させるのに役立ちました。

Answer 3

可能な限り、リリースプロセスを自動化します。

他の人が示唆しているように、ビルドの「深さ」のレベルを変えてください。たとえば、開発者ビルドは、リポジトリから直接、開発マシンで製品を実行するためのすべてのバイナリを作成できますが、インストーラービルドは、新しいマシンにインストールするためにすべてをアセンブルできます。

これには以下が含まれる可能性があります

• バイナリ、
• JAR / WARアーカイブ、
• デフォルトの構成ファイル、
• データベーススキームインストールスクリプト、
• データベース移行スクリプト、
• OS構成スクリプト、
• man / hlpページ、
• HTMLドキュメント、
• PDFドキュメント

等々。インストーラービルドは、これらすべてをインストール可能なパッケージ（InstallShield、ZIP、RPMなど）に詰め込み、物理配布用のCDISOをビルドすることもできます。

インストーラービルドの出力は、通常、テスト部門に渡されるものです。インストールパッケージ（インストールの上にパッチを適用する...）に含まれていないものはすべてバグです。障害のないインストール手順を提供するように開発者に挑戦してください。

Answer 4

自動化されたシングルステップビルド。antビルドスクリプトは、すべてのインストーラー構成ファイル、変更（バージョン管理）が必要なプログラムファイルを編集してからビルドします。介入は必要ありません。

完了時にインストーラーを生成するためのスクリプト実行はまだありますが、それを排除します。

CDアートワークは手動でバージョン管理されます。それも修正する必要があります。

Answer 5

以前のコメントに同意します。

これが私が働いている場所で進化したものです。この現在のプロセスにより、質問で説明した「落とし穴」がなくなりました。

antを使用して（タグバージョンごとに）svnからコードをプルし、依存関係をプルしてプロジェクトをビルドします（場合によっては、デプロイすることもあります）。

同じantスクリプト（paramsを渡す）が各env（dev、integration、test、prod）に使用されます。

プロジェクトプロセス

• 要件をユーザーの「ストーリー」としてキャプチャする（製品との有意義なユーザーインタラクションとして表現された場合、要件の解釈を混乱させることを回避するのに役立ちます）
• アジャイルの原則に従って、プロジェクトの各反復（2週間）で現在の機能のデモが行われ、制限されている場合はリリース可能な製品が提供されます。
• プロジェクト全体でリリースストーリーを管理して、範囲内と範囲外の内容を理解します（そして、直前の修正に伴う混乱を防ぎます）
• （前の応答の繰り返し）コードがフリーズし、テストのみ（追加機能なし）

開発プロセス

• ユニットテスト
• コードチェックイン
• スケジュールされた自動ビルド（クルーズコントロールなど）
• 統合環境へのビルド/デプロイを完了し、スモークテストを実行します
• コードにタグを付け、チームに連絡します（テストとリリース計画のため）

テストプロセス

• 機能テスト（たとえば、セレン）
• テスト計画と機能シナリオの実行

1人の担当者がリリースプロセスを管理し、全員が確実に準拠するようにします。さらに、すべてのリリースはリリースの1週間前にレビューされます。リリースは、次の場合にのみ承認されます。

リリースプロセス

• 特定の日時のリリースを承認する
• リリース/ロールバック計画を確認する
• '本番デプロイメント'パラメーターを使用してantを実行します
• DBタスクを実行します（存在する場合）（また、これらのスクリプトはバージョン化して本番用にタグ付けできます）
• 他のシステム変更/構成を実行する
• 変更を伝達する

Answer 6

SDLCを知らない、または実践していませんが、私にとって、これらのツールはスムーズなリリースを実現するために不可欠です。

• Nexusローカルリポジトリマネージャーを使用したビルド用のMaven
• 継続的インテグレーション、リリースビルド、SCMタグ付け、ビルドプロモーションのためのHudson
• 品質メトリクスのソナー。
• 開発データベーススキーマへのデータベースの変更を追跡し、DbMaintainとLiquiBaseを介してqaとリリースの更新を管理します

Answer 7

私が働いているプロジェクトでは、Doctrine（PHP ORM）の移行を使用してデータベースをアップグレードおよびダウングレードしていました。生成されたモデルがデータベーススキーマと一致しなくなり、移行が途中で完全に失敗するため、あらゆる種類の問題が発生しました。

結局、私たちは同じものの独自の超基本バージョンを書くことにしました-何も派手ではなく、SQLを実行するアップとダウンだけです。とにかくそれはうまくいきました（これまでのところ-木に触れてください）。独自の記述で車輪の再発明を少し行っていましたが、シンプルに保つことに重点が置かれているという事実は、問題がはるかに少ないことを意味します。今リリースは簡単です。

ここでの話の教訓は、正当な理由がある限り、車輪の再発明を何度かやり直してもよい場合があるということだと思います。