3

私はWebスタートアップで働いており、私たちの製品はついに市場性に近づいています。今日まで、すべての開発者がSVNの同じブランチで作業していて、ズボンの座席のそばを飛んでいましたが、それは問題ありませんでした。しかし、リリースが近づいており、QAを採用しようとしている今、本によって物事をさらに構造化する必要があります。そして、私はQAとリリースプロセスの設計を担当しました。ただ、自分がやるべきことを「本」とは何なのか完全にはわかりません。選択できるオプションはたくさんあることを私は知っています。私たちが持っているものに対する最も適切な解決策についてのアドバイスをStackOverflowersに頼ります。

  • データベースはMSSQLServer 2008（まもなく2012年）です。
  • RedGateのSQLDeveloperBundleのライセンスを購入する予定です。これは、1週間の評価の後、非常に便利なツールのように見えます。
  • サーバー側のコードはC＃です。
  • UIは、ASP.NETとFlex/Flashを組み合わせたものです。
  • 開発、QA、ライブに別々のサーバーを利用できます。
  • SVNによるソース管理。

私が望む結果は、すべてのQAへのワンクリックビルド＆リリースです。そして、QAがそれを承認したら、それをライブにプッシュするためにもう一度ワンクリックする必要があります。

コードブランチの管理方法から、時間とお金を節約できるサードパーティソフトウェアまで、あなたが行うことは何でもお勧めします。この段階では、費用が正当である限り、提案ややり方の変更を受け入れることができます。

ありがとう！

4

2 に答える 2

3

ただ、私が物事を行う際の「本」が何であるかは完全にはわかりません。

継続的デリバリーを確認してください テストと展開において、多くの自動化が必要になります。ツールは間違いなく必要ですが、それだけでは十分ではありません。トランク/メインラインで作業しているすべての開発者は問題ありません。存続期間の長いブランチは、後で統合の課題を増やすだけです。参照された本には、これに関する多くの良いアドバイスがあります。完全な開示: 私はこの本の著者の 1 人と同じ会社で働いています。

于 2012-07-09T04:50:30.367 に答える
2

これは、私たちが最初に直面した問題と非常によく似ています。QA チームを構築する際に築き上げた基盤は現在も存在しており、リリース プロセスの成功の鍵となっています。

ビルド リリースの構造に関するハイレベル ポイント

  • コードに何が入っているのか、そしてその理由を常に把握しておく必要があります。ある種のバグ追跡システムで変更の意図を追跡します。

  • すべてのコード チェックインは、コミットされた一連の作業を参照する必要があります。それがQOL向上であれば、誰かがチケットtリファレンスを作成します。参照されていないチェックインはありません。

  • コードは、少なくとも 1 日に 1 回はゼロから作成されます。1 日に複数回作成することが望ましいです。QAは常に最新のビルドからテストします。

  • ビルドの失敗は、最大限の緊急性をもって処理されます。すぐに修正。

  • ビルドは、何らかの長期保管場所に保管し、配送の基礎として使用する必要があります。主要なマイルストーンは、ソース管理だけでなく、長期保存マシンでもタグ付けされます。この目的のためにBuildManagerと呼ばれるマシンを使用します

  • 個人的には、展開を QA チームから分離することは考えていません。各 QA エンジニアは、アプリケーションを展開し、必要なテスト データを自分で作成する方法を知っている必要があると思います。このアプローチにはいくつかのトレードオフがあります。興味があれば、喜んで議論します。

  • コードがデプロイされたら、何らかのサニティ テストを実行する必要があります。それがシステム/構成テストであろうと、実際の機能検証であろうと、このビルドが誰の時間を無駄にしないようにするためにできることは何でもしなければなりません。コードをチェックインしてから、しっかりとしたビルドが整っていることを確認するまでの時間を短縮することは、自動化への最良の投資の 1 つです。

ここからは、QA がどのように構成され、チームの他のメンバーとどのように連携するかが、基礎で説明したのと同じくらい重要です。

于 2012-07-15T19:32:59.820 に答える