11

メジャー リリースでコードが出荷 (または展開) される前に、他のチームがどのような標準を整備しているのか、私は興味があります。

それぞれに対する特定の答えを探しているわけではありませんが、ここで私が理解しようとしていることのアイデアを示します。

  • サーバーベースのアプリの場合、監視が実施されていることを確認していますか? どの程度... ping に応答するか、任意の時点ですべての依存関係をヒットできるか、アプリが実際にサービスを提供するロジックが適切であるか (たとえば、2+2 を計算するサービスが実際に「4 を返す」 "）
  • コードをリリースする前に、自動化されたビルド スクリプトが必要ですか? つまり、開発者は誰でも新しいボックスに足を踏み入れ、ソース管理から何かをヤンクして開発を開始できますか? もちろん、OSやIDEなどを考えると。
  • サーバーベースのアプリ用の自動展開スクリプトはどうですか?
  • プロジェクトを「完了する」ためには、どのレベルのドキュメントが必要ですか?
  • システムがサーバーベースの場合、システムのすべての主要コンポーネントに対して本格的なバックアップ計画を立てていますか?
  • コードの品質基準を実施していますか? .NET または循環的複雑度評価の StyleCop を考えてみてください。
  • 単体テスト？統合テスト？パフォーマンス負荷テスト?
  • アプリケーションのエラー ログの処理方法に関する基準はありますか? エラー通知はどうですか？

繰り返しますが、必ずしも上記の何かに対する回答の行ごとのパンチリストを探しているわけではありません。要するに、コード リリースがチームにとって正式に「完了」したと見なされる前に、コード リリースが完了している必要がある非コーディング項目は何ですか?

4

8 に答える 8

5

最小:

  1. 単体テスト作業
  2. 統合テストが機能する
  3. テストステージにデプロイOK
  4. テストステージでの手動ショートチェック

より良い：

  1. 単体テスト作業
  2. チェックスタイルOK
  3. 統合テストが機能する
  4. jmeterやテスト カバレッジなどの指標が合格しました
  5. テストステージにデプロイOK
  6. テスト段階でのいくつかの手動テスト

最終的に本番ステージにデプロイ

すべての単体テストと統合テストは自動的に機能し、antまたはmavenによって実行されるCruiseControlのような継続的統合サーバーで最適です。Web サービスを開発する場合、soapuiを使用したテストは正常に機能します。

データベースが使用されている場合、デプロイ前に ( liquibaseなどを使用して) 自動アップグレードが行われます。外部サービスを使用する場合は、URL が正常であることを確認するために、追加の構成テストが必要です (アプリケーションからの head 要求、データベース接続、wsdl get など)。webpps を開発する場合、一部のページでの HTML検証が役立ちます。レイアウトを手動でチェックする (たとえば、ブラウザショットを使用する) と便利です。

(Java 開発用のすべてのリンク例)

そして最後に (大事なことを言い忘れましたが): すべての受け入れテストはまだ合格していますか? その商品はオーナー様の求めるものですか？先に進む前に、テスト システムで彼とライブ レビューを行ってください。

于 2009-05-20T19:02:43.460 に答える
4

プロジェクトはそれぞれ異なりますが、経験則として、コードを公開する前に私がやろうとしている重要なことを以下に示します。

順不同：

1) 後でユーザーが見つけられる場所にあるバージョン ID。これは、このリリースに固有のものでなければなりません。（非常に一般的には、配布可能ファイル、ライブラリと実行可能ファイル、または「about」ダイアログから表示されるユーザーに関連付けられた「バージョン番号」。既知のレジスタまたはファームウェアのオフセットの番号である可能性があります）

2) リリースの作成に使用された正確なコードのスナップショット。(SCM システムのリリースのラベルまたはブランチがこれに適しています)

3) ソースを再作成するために必要なすべてのツールを記録し、アーカイブする必要があります (ステップ 2 のソースは、これがないと使用が制限されます)。

4) 実際のリリースのアーカイブ (リリースされた正確なインストーラーのコピー。7 年後にはツールでビルドできなくなる可能性があることを知っていますが、少なくともソース コードと、調査目的でインストール可能なものを手元に置いています。 ）。

5) このリリース バージョンと以前のリリース ノートの間の一連の文書化された変更 (リリース ノートとも呼ばれます) (ユーザーがすべてのリリース変更を 1 か所で利用できるように、リストに追加するスタイルを使用するのが好きです)。

6) 候補リリース テスト サイクルが完了しました。配布可能な作成された負荷を使用し、完全な/精査されたテスト計画を使用してテストして、コア機能が動作していることを確認します。すべての新機能が存在し、意図したとおりに動作します。

7) 欠陥の追跡により、すべての未解決の項目に a) 修正済み b) 欠陥ではなく c) 保留のフラグが付けられていることが示されます。

ドメインまたは開発スタイルに応じて、他の多くの手順を散りばめることもできますが、ほとんどのソフトウェアは、リリースごとに上記の手順を実行する「必要がある」と述べています。YMMV。

城を襲撃して楽しんでください。

于 2009-05-23T21:49:53.257 に答える
4

私は主に Web 開発を行っているため、私のアイテムはあなたのものとは異なる場合があります。頭のてっぺんから...

  • すべての Web サービスが最新であることを確認する
  • すべてのデータベース スクリプト/変更/移行が既に運用サーバーにデプロイされていることを確認します。
  • すべての js ファイルと css ファイルを最小化します。
  • すべてのユニット/機能/統合/Selenium テストに合格していることを確認します (開発中に 95% 以上のテスト カバレッジを目指しているため、これらは通常、問題を特定する上でかなり正確です)。

他にもあることは知っていますが、今は思いつきません。

于 2009-03-31T13:15:35.387 に答える
1
  • チェックリストを確認します。バージョンで計画されているすべての新機能、変更要求、バグ修正が完了していることを確認します。
  • ビルド（ビルドマシン内）は、リリースモードで警告やエラーなしでコンパイルされます。
  • すべての自動化された単体テストはエラーなしで実行されます。
  • すべてのメッセージと画像は製品チームによって承認されています。
  • パフォーマンスチェックは、以前のバージョンよりも悪くはありません。
  • 完全な（手動の）テスト計画は、エラーなしでテストチームによってチェックされました。
    • アプリケーションは、考えられる多くのシナリオ（さまざまなOS、データベースエンジン、構成、およびサードパーティアプリケーション）でテストされます。
    • アプリケーションのすべての機能がテストされます。機能の変更により、関係のない別の機能が壊れたことが何度も発生しました。たわごとが発生するため、最小限に抑える必要があります。
    • セットアップまたは展開は、すべてのシナリオで機能します
    • セットアップは以前のバージョンをアップグレードできます
于 2009-05-25T19:07:43.967 に答える
1

最近メジャーリリースを行ったので、これはまだかなり新鮮です。バイナリ実行可能ファイルをリリースするGUIを使用してWindowsアプリケーションを作成するため、私のリストは必然的にWebのみのリリースのリストとは大幅に異なります。

  1. リリース候補はテストチームに出かけます。彼らはそれで遊ぶために少なくとも数日を必要とします。ショーストッパーと見なされるバグが見つかった場合、リリースは中止されます。これは、テストチームがいることを前提としています。リリース候補をクリアするのは、ビルド日から少なくとも1週間が経過した場合のみです。

  2. すべての自動テストは機能し、合格する必要があります。自動テストは、ライブテスターの補足と見なされます。

  3. 「ブロッカー」としてマークされたバグは、最終ビルドで解決する必要があります。

  4. 広報資料を用意する必要があります（この場合、Webページの更新と電子メールのニュースレター）。再販業者は、資料を準備できるように、リリースが数週間前に行われることを警告されます。これはほとんどプログラマーの関心事ではありませんが、マーケティングの主張が正確かどうかをチェックします。

  5. 使用しているコピー防止機能を反映するように、ライセンスを更新する必要があります。ベータ版とリリース版では異なるライセンスモデルが使用されており、この変更にはプログラミング作業が必要です。

  6. インストーラーと使用許諾契約を更新する必要があります。ベータ版にはインストーラーがあるため、これは通常、単なるテキストの変更ですが、実際にインストールスクリプトを更新するのはプログラマーの責任です。

  7. ベータ版への参照は、アプリケーション自体から削除する必要があります。恥ずかしいことに、これらのいくつかを見逃しました。

  8. ヘルプファイルとマニュアルはリリースパッケージの一部であるため、完全に最新の状態にして校正する必要がありました。

  9. 時間内に修正できないバグがあった場合は、少なくとも被害を軽減しようとします。たとえば、そのようなバグが発生していることを検出し、謝罪のエラーメッセージを表示して操作を中止します。これは、知覚される製品の安定性に大きく貢献します。

遠く離れて、メジャーリリースの難しさはプログラミングの問題ではなく、管理/マーケティングの問題でした。これらの多くは、プログラマーの注意を必要としました。インストーラーの支援、機能リストの校正による意味のないことの確認、マニュアルの技術セクションの校正、ライセンスの更新などです。主な技術的な違いは、バグ修正からバグ軽減へ。

于 2009-05-26T10:20:28.833 に答える
1

Web / 内部アプリの場合、他の提案に加えて 1 つのことがあります。

運用/展開チームを必ず関与させて、必要以上のサーバーを必要とするソフトウェアを提供しないようにしてください (要件を推進する人々が既に持っていると想定しないでください)。

于 2009-05-25T12:53:09.317 に答える