あなたのチームは、メジャー バージョンのコードの展開に対してどのような基準を適用していますか?

StackOverflow https://stackoverflow.com/questions/700833

  •  22-08-2019
  •  | 
  •  

質問

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

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

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

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

役に立ちましたか？

解決

最小値:

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

より良い：

  1. 単体テストが機能する
  2. チェックスタイル わかりました
  3. 統合テストが機能する
  4. のようなメトリクス jメーター テストカバレッジに合格しました
  5. テストステージにデプロイOK
  6. テストステージでのいくつかの手動テスト

ついに実稼働ステージにデプロイ

すべての単体テストと統合テストは自動的に機能し、次のような継続的統合サーバーで最適です。 クルーズコントロール によって行われ 蟻 または メイブン. 。Webサービスを開発するときは、 ソープイ 正常に動作します。

データベースが使用されている場合、自動アップグレードが実行されます ( リキベース 例) 導入前。外部サービスを使用する場合は、URL が適切であることを確認するために追加の構成テストが必要です (アプリケーションからのヘッド リクエスト、データベース接続、wsdl get など)。WebPP を開発する場合、HTML 検証 いくつかのページでは役に立つでしょう。レイアウトの手動チェック (使用 ブラウザショット たとえば) 便利です。

(Java 開発用のすべてのサンプル リンク)

そして最後に（重要なことですが）：すべての受け入れテストはまだ合格していますか?その商品はオーナーの望むものですか？次に進む前に、テスト システムで彼とライブ レビューを行ってください。

他のヒント

私は主に Web 開発を行っているため、私の項目はあなたのものと異なる可能性があります。頭のてっぺんから...

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

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

それぞれ、すべてのプロジェクトが異なっている、しかし、ここでは経験則として、私は前のコードは野生に出かけせるに行っているしようとするコアのものがあります。

順不同で：

それは、後にユーザによって見つけることができる場所に、

1）バージョンID、これは、このリリースに固有でなければなりません。 （非常に一般的に「約」ダイアログから配布、ライブラリや実行可能ファイル、または可視ユーザに関連した「バージョン番号」。よく知られたレジスタで数であるか、またはファームウェアにオフセットできる）

2）正確なコードのスナップショットは、放出を生成するために使用されます。 （ラベルやSCMシステムでのリリースのブランチは、このために良いです）

3）ソースを再作成するために必要なすべてのツールが注目およびアーカイブされなければならない（ステップ2からのソースが、このことなく、限られた用途でなる）

4）を知っている実際のリリース（解放正確なインストーラのコピー、アーカイブの7年間で、あなたのツールは、それを構築することができないかもしれないが、今、少なくとも、あなたは、ソースコードとあなたの側でインストールを持っています調査の目的のために）。

5）は、このリリースバージョンと以前の別名リリースノート（私はすべてのリリースの変更は、ユーザーのために一つの場所で利用できるように、リストに追加のスタイルを使用したい）との間で文書化された一連の変更を。

6）候補放出試験サイクル完了。コア機能が動作していることを確認するため、フル/吟味テスト計画を使用して配布作成したロードおよびテストを使用して、すべての新機能が存在し、意図したとおりに動作します。

7）欠陥追跡はすべての未処理の項目がA）固定b）のない欠陥c）は遅延としてフラグ付けされているを示します。

あなたは、ドメインや開発スタイルに応じて、他の多くの段階に振りかけることができますが、私はほとんどのソフトウェアは、それぞれの上記の手順を実行し、すべての解放「されなければならない」と述べているでしょう。 YMMVます。

城を襲撃楽しみを持っています。

  • コードスタイル (自動)
  • 自動テスト (単体テストと統合テスト)
  • 手動テスト (テスト段階とベータ段階を含む)
  • ホワイトボックスペネトレーションテストツール（自動）
  • ブラックボックス侵入テストツール（自動）
  • ロールアウト前のテスト/ベータ段階での手動例外/ログ監視
  • いつでも前のバージョンに戻す機能
  • コードレビューと「不正なチェックイン」

ウェブ/内部アプリケーションのために他の提案に加えて、1つの事ます。

あなたは、彼らが（要件を押して、人々がすでに持っていると仮定していない）を持つ複数のサーバーを必要とするソフトウェアを提供していないので、OPS /展開チームが関与していることを確認します。

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

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

  1. リリース候補者はテスト チームに参加します。遊ぶには少なくとも数日は必要です。私たちが重大な問題とみなすバグが見つかった場合、リリースは中止されます。これは、テスト チームがあることを前提としています。リリース候補は、ビルド日から少なくとも 1 週間が経過した場合にのみクリアされます。

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

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

  4. 広報資料を準備する必要があります (私たちの場合は、Web ページの更新と電子メール ニュースレター)。再販業者は、リリースが数週間前に行われることを通知されるため、資材を準備することもできます。これはほとんどプログラマが懸念することではありませんが、私たちはマーケティング上の主張が正確であるかどうかをチェックします。

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

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

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

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

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

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

  1. 目に見えるバグはありませんか？わかりました
  2. 単体テストの仕事？オーケー（一部無視）はははははははははははははははははははははははははははははははははははははは無視
  3. セットアップは確かに。わかりました
  4. エラーログ?もちろん ！:-) これが必要です！バグを修正するために！
  5. すべては Cruisecontrol.net にあります。
ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top