7

誰かが一方と他方についてコメントを持っていますか？

単体テストの実行、コードレビューの実施、UATから本番環境へのビルドのプッシュを許可されているユーザーへのアクセス許可の適用など、開発からテスト、UAT、本番環境へのリリースプロセスの自動化を検討しています。

4

4 に答える 4

4

免責事項：私はBambooのプロダクトマネージャーです

@バーナード：あなたのプロセスについてもう少し詳しく教えていただけますか？

  • UATテストは手動テストですか？
  • あなたの場合、本番環境への移行とはどういう意味ですか？
  • デプロイメントの最後に単一のビルド結果を期待しますか？

Bamboo 2.7は、ビルドをさまざまなステージに分割し、ステージ内でジョブを並行して実行できるようにする最初のリリースです。これにより、ビルドの全体的な所要時間を大幅に改善できます。現在、アーティファクトの受け渡しに取り組んでいます。これにより、異なるステージ間でビルドアーティファクトを渡すことができます。繰り返しになりますが、これにより全体的なビルド時間が短縮され、継続的デプロイプロセスに向けたもう1つの重要なステップになります。

残念ながら、現在、ビルドの特定の部分に権限を適用するための適切な「すぐに使用できる」方法はありません。繰り返しますが、プラグインを使用して、特定の方法でビルドを設定することにより、これを回避する方法があります。しかし、あなたのプロセスをより詳細に知らずに提案を提供することは困難です。プロセスの詳細を私たちと共有したい場合は、直接お話ししたいと思います（atlassian dot comのjens）。

@jgritty：あなたが指摘している問題は、Perforce統合に関する既知の問題であり、未知のバグのようです。support。@atlassian.comでサポートリクエストを作成するか、jira.atlassian.comでバグレポートを作成してください。

Perforceは（CVSやSVNと比較して）Bambooユーザーの間であまり一般的に使用されていないため、通常、Perforceに関するフィードバックは少なく、既存の問題についてはあまり耳にしません。問題を直接私たちに提起してください。今後のリリースの1つで問題を修正するために最善を尽くします。

乾杯、

イェンスシューマッハ

于 2010-12-02T07:07:37.260 に答える
3

Goのことは聞いたことがありませんが、Bambooにはいくつかの深刻な癖があると言えます。ソース管理システムに応じて、マイレージは異なる場合があります。

フックするすべてのSCMを処理するには、最小公分母のアプローチが必要です。そのため、PERFORCEを使用する場合、無料で入手できるものを失うことになります。

まだ修正されていない厄介なことがいくつかあります。

特定のクライアントを使用するようにビルドエージェントを設定します（もちろん、grrはすでに存在している必要があります）。ここで、クライアントがc：\buildareaをルートとしているとします。c：\ buildareaフォルダーを手動で作成する必要があります。そうしないと、エージェントはファイルをクライアントルートに抽出できないというばかげたエラーを表示します。明らかに、「p4 sync -c YOURCLIENT」はそれを行いますが、Bambooは何か面倒なことをします。

それができないもう一つのことは、既存のラベルから適切に構築することです。クロスプラットフォームビルドがあり、LinuxとWindowsの両方を同じ正確なチェンジリスト/ラベルからビルドしたい場合、Bambooでそれを行う簡単な方法はありません。ビルドを同時に発射して祈ることができます。一方のファイルをもう一方のファイルと同期させることはできますが、ラベルを使用してビルドする方法はありません。

最後に少し馬鹿げている（しかしひどいわけではない）のは、「タグ付け」が構築される方法で誰もがCVSを使用することを想定している方法です。ビルドに多数のチェンジリストが含まれている場合、それを単にチェンジリストと呼んで1回番号を付けるのではなく、チェンジリスト内のすべてのファイルの「バージョン番号」をリストします。明らかに、ディールブレーカーではなく、p4ユーザーにとっては少し奇妙です。

全体として、これらの問題のどれも私たちを殺しませんでした、そして私たちはそれを1日あたり数百のビルドに使用し、いつでも200のビルドプランのオーダーがアクティブになっています。他の問題も考えられると思いますが、多くのことが解決されています。

于 2010-12-01T23:01:32.227 に答える
3

@Bernard：私はThoughtWorksで働いており、BambooよりもGo（Cruise）の使用経験が豊富なので、Goがクエリに対応するようになりました。

  1. 「開発からテスト、uat、本番へのリリースプロセスの自動化を検討しています」：デプロイパイプラインによるリリースプロセス全体のモデリングと自動化はGoによって概念化されており、以前のバージョン（以前はクルーズ）。デプロイメントパイプラインは、複雑なビルドを一連のステージに分割します。一連のステージは、それ自体がジョブのコレクションです。ステージは手動または自動でトリガーできます。また、パイプラインダッシュボードUI自体から環境全体に伝播する変更のフローを表示し、制御することも非常に簡単です。UATに自動的にデプロイする詳細な例を次に示します（http://www.thoughtworks-studios.com/go/2.0/help/rm_deploy_to_environment.html）。
  2. 「単体テストの実行、コードレビューの実行を含む」： Goを使用すると、テストスイートを分割して並行して実行できます。また、失敗したジョブ、失敗したテスト、テストに失敗したチェックインなどの詳細な証跡、および選択したビルドイベントの電子メールアラートを含む包括的なレポートを取得します。Goはアーティファクトも自動公開し、これらはレポート自体から表示できます。これは、ビルドをスニッフィングするときに非常に便利です。Goでは、ラチェット（http://skizz.biz/blog/2008/03/11/fixing-broken-windows-with-ratcheting/）を実装するのは非常に簡単なので、コーディングに適合しないビルドに失敗する可能性があります標準のしきい値。
  3. 「ビルドをUATから本番環境にプッシュできるユーザーにアクセス許可を適用する」：パイプラインをグループ化することで、表示と操作の両方のアクセス許可を使用してプロジェクトと環境へのアクセスを制御できます。さらに、ビルドのトリガーを許可されているユーザーをロックダウンできます。

市場に出回っている多くのツールとは異なり、Goは、トリガーされたビルド、環境モデリング、並列ビルドからの結果の集約、アーティファクトの自動公開の容易さ、ビルドエージェントの自動更新の間の関係を可視化します。

@jgritty： GoはThoughtWorksStudiosのCruiseの後継です。

于 2010-12-03T04:01:52.797 に答える
2

私はBamboo/TeamCity / Jenkins / etcを使用し、ThoughtWorksGoを標準のCIサーバーに対して最近レビューしました。

彼らがチームの管理とリリースの問題を解決したかどうかを確認することに本当に興味がありました。私は個人的にTeamCityが一番好きですが、Goを試してみました。正直なところ、私は少しがっかりしました。純粋なビルドサーバーとして、TeamCity/Bambooほど高度なものではありません。主要なSCMとビルドツールのサポートが不足していました。また、ほとんどのビルドサーバーは、FindBugs / PMD / Emma / Clover / etcなどのサードパーティツールを多くサポートしていますが、Goはサポートしていません。

市場に出回っている他の製品と異なる点の1つは、環境の概念と、さまざまな環境を移動する機能です。しかし、それはコンセプトの非常に原始的なバージョンでした。

Thoughtworksのスタッフは世界でも有​​数であり、開発チームで豊富な経験を持っています。ソフトウェア開発プロセスに関するいくつかの重要な問題に実際に対処し始めるツールのリリースが増えることを期待しています。

私の簡単なレビューはここにあります

http://diarmuidmoloney.wordpress.com/2011/11/24/thoughtworks-go/

于 2011-11-27T19:47:13.323 に答える