4

私は 7 人の開発者と一緒に Web プロジェクトに取り組んでいます。新しいコードをステージングに渡す前にテストできるように、ベータ ボックス (debian) をセットアップします。

ベータ ボックスで Jenkins をセットアップし、マージ/テスト プロセスを自動化したいと考えています。また、何らかの方法で結び付けたいテストスイートもあります。

SVN / Jenkins を使用して Python Web プロジェクトをテストおよび実行するにはどうすればよいですか?

良いワークフローを策定しようとしています。現在、各開発者はフィーチャー ブランチで作業しています。ブランチでコードを実行し、問題がなければマージします。

開発者にベータ ジェンキンスにログインしてもらい、フィーチャー ブランチからビルドするように指示してもらいたいです。ジェンキンスが何をするかについての私の計画は次のとおりです。

  1. 機能ブランチがトランクからリベースされていることを確認してください
  2. ベータ ブランチがトランクと同一であることを確認します (マージされたフィーチャー ブランチを上書きします)。
  3. フィーチャー ブランチをベータ ブランチにマージする
  4. 実行中のサーバーを強制終了します
  5. サーバーを起動するnohup python app.py &
  6. テスト スイートを実行するpython test.py
  7. テスト データを Jenkins の開発者ビューに出力する
  8. いずれかのテストが失敗した場合は、ブランチがマージされる前の状態に戻します

マージの競合を処理する方法がわかりません。また、上記はおそらく悪いと間違っています。アドバイスをいただければ幸いです。

4

2 に答える 2

3

いくつかあります：

  • barracel が示唆したように - いくつかの DVCS を使用する方がはるかに便利です - そのような git は、複数のブランチで動作する準備が整っています。
  • マージの IMHO プロセスは、自動化したくないものです (これについては、「マージの競合を処理する方法」を参照して書いています)。私が以前働いていたワークフローでは、マージは常に人間によって処理され、時には何らかのコードレビューが行われていました (「見た目が良ければ」とはどういう意味かわかりません - 機能のみを検証しますか、それともどのように実装されたかを検証しますか)オリエンテーションを受けるには？
  • 単体テストのほかに、いくつかの機能テスト (Selenium) とパフォーマンス テスト (jmeter または tsung) をベータ ブランチへのマージごとに開始します。そのようにして、アプリケーションが開発に伴ってどのように変化するかを追跡します (また、時間内に反応する可能性があります)。たとえば、ログインページでパフォーマンスの低下に気付いた場合などです。
  • 些細なことですが、別々のブランチで作業している間は、情報の流れを確認して、異なるブランチで同じ部分を開発したり、使用されているソリューション/パターン/ライブラリで矛盾が大きくなったりしないようにしてください。何が役立つか-失敗したメールを（失敗した開発者に）送信し、トランクへのマージが成功した後にすべての人に送信する-したがって、全員に通知されます（ただし、開発者にスパムを送信していないことを確認してください-彼らはそれを読むのをやめます;）
  • マージの競合が本当に多い場合は、フローを再考し、ブランチの数を最小限に抑える時期かもしれません。 -branching-and-merging/または Branch By Abstraction http://paulhammant.com/blog/branch_by_abstraction.html/
  • 開発者が頻繁にトランクをプルしてブランチにマージしていることを確認してください。競合を減らすのにも役立つはずです。
  • トランクからマージした後、開発者ブランチで直接テストしてみませんか? このようなマージされたコードは、再びトランクにマージするのが簡単なはずです
于 2013-02-13T10:16:15.133 に答える
3

この質問は、簡単な投稿で答えるには少し大きすぎるので、私の個人的な見解からわかる限り、いくつかのヒントと参考文献を提供しようと思います。

いくつかの簡単なヒント:

  • 開発者をブランチに分けるというアイデアは気に入っていますが、機能ブランチでテストを行い、機能がテストに合格した場合にのみベータ ブランチにマージします。この方法では、テストされるまでベータには何も入りません!
  • 統合手順を Jenkins の外部のスクリプトに入れます。ソースコードの一部にします。このようにして、Jenkins の外部でスクリプト自体をすばやくテストできます。
  • 最も使い慣れたビルドシステムまたはスクリプト言語を使用してください。ほとんどの手順は、任意のプログラミング言語で簡単に実行できます。
  • スクリプトが成功または失敗を返すようにして、Jenkins がビルドに失敗のフラグを立てることができるようにします。
  • マージの問題については、2 つの可能性があります。
    • 開発者が統合のためにブランチを送信する前に、ブランチを手動でリベースする必要があります。スクリプトをチェックインし、リベースが必要な場合は失敗します。この方法では、マージ エラーは発生しません。ブランチがリベースされていない場合、ビルドは単に失敗します。
    • リベースされていないマージを許可する場合は、マージ エラーでビルドを失敗させて、開発者が問題を手動で解決できるようにする必要があります (再度送信する前にブランチをリベースすることにより)。

この分野で役立つと思われる本をいくつか紹介します。

  • Google がソフトウェアをテストする方法、James A. Whittaker、Jason Arbon、Jeff Carollo 著
  • 継続的デリバリー: Jez Humble によるビルド、テスト、デプロイの自動化による信頼性の高いソフトウェア リリース

コメントで、追加したいコンテンツをお知らせください。

于 2013-02-12T08:58:35.560 に答える