6

私は現在、アメリカ全土に分散したチームでかなり大規模なプロジェクトに取り組んでいます。開発者は定期的にコードをソース リポジトリにコミットします。次のアプリケーション ビルドがあります (すべてアプリケーションによって管理され、手動プロセスはありません)。

  1. 継続的インテグレーション: モニターは、コード リポジトリが更新されているかどうかを確認し、更新されている場合はビルドを行い、ユニット テスト スイートを実行します。エラーが発生すると、チームはメール通知を受け取ります
  2. デイリー ビルド: 開発者はこのビルドを使用して、実際のアプリケーション サーバーでバグ修正や新しいコードを検証します。「何か」が成功した場合、開発者はタスクを解決できます。
  3. 毎週のビルド: テスターは、このビルドで解決済みの問題キューを確認します。より安定したテスト環境です。
  4. 現在のリリース ビルド: 潜在的な新規ユーザー向けのデモおよびオープン テスト プラットフォームに使用されます。

ビルドごとに、関連付けられているデータベースが更新されます。これにより、データが消去され、新しいコードに伴うデータベースの変更が取り込まれていることが検証されます。テスターから聞いた懸念の 1 つは、より一般的なデータではなく、予想されるテスト データを毎週のビルド データベースに事前入力する必要があるということです。開発者が協力します。これは正当な懸念/ニーズのようであり、私たちが取り組んでいるものです.

SO コミュニティが私たちのやっていることと何かギャップがあるかどうか、または何か懸念があるかどうかを確認するために、私たちが行っていることを投げかけています。物事はうまくいっているように見えますが、もっと良くなる可能性があるように感じます。あなたの考え？

4

3 に答える 3

1

これは私たちのやり方とほとんど同じです。テスター自体のDBは、要求に応じてのみリセットされます。これを毎週自動的に更新するとしたら、

  1. バグの症状への参照が失われます。バグが見つかったが、開発者が数週間後（または単に週末の後）にそれを見るだけの場合、そのバグのすべての証拠が消えた可能性があります
  2. テスターは大きなテストケースの真っ只中にいる可能性があります（たとえば、1日以上かかる）
  3. 統合ビルドが実行されるたびに（もちろん自動的に）更新されるDBに対して実行されている単体テストがたくさんあります。

よろしく、
Stijn

于 2010-02-23T14:05:17.347 に答える
1

従う追加の手順は、リリースビルドがテスト（スモークテストなど）に合格すると、適切なビルド（ゴールデンビルドなど）として認定され、何らかのラベル付けメカニズムを使用してすべてのアーティファクトにラベルを付けることです（コード、インストールゴールデンイメージの作成に使用されたスクリプト、makefile、インストール可能など）。ゴールデンビルドは、後でリリース候補になるかどうかはわかりません。

私が観察したことを追加したとは言わないので、おそらくあなたはすでにこれを行っています。

于 2010-02-23T14:31:12.053 に答える
0

顧客が更新を確認したいときに適合する限り、優れた包括的なプロセスがあると思います。私が見ることができるギャップの1つは、テストビルドが毎週行われ、テスターが検証するための時間が必要になるため、重要な顧客のバグ修正を1週間以内に本番環境に導入できないように見えることです。修正。

別の方法で物事を考えたい場合は、継続的デプロイに関するこの記事をご覧ください。最初はこの概念を受け入れるのは少し難しいかもしれませんが、確かにある程度の可能性があります。

于 2010-02-23T15:49:28.040 に答える