継続的インテグレーション ツールとその利点に関する調査を行っています。私の研究では、次のツールを見ています。
今、私はすべての要件と利点であなたを悩ませることはありません. しかし、これまでのところ、これらを除いてツール間の違いはそれほど多くありません。
継続的インテグレーション ツールを選択しなければならなかった一部の人々が、そこでの経験とそのツールを選択した理由を共有できるかどうか、また、カバーしなかったものを選択する前に検討する価値のある特定の違いがあるかどうかを知りたいと思っていました。
ファンイン ファンアウトのサポートと継続的デリバリー パイプラインの視覚化により、現在 GoCD に傾倒しています。このツールの問題をサポートした経験のある人はいますか?
よろしくお願いします。
免責事項: 私は前の秋まで GoCD に積極的に貢献していました。私は GitLab CI を使用したことがないので、それについては説明しません :) また、過去 1 年間、これらのツールを使用していません。
TeamCity は優れた CI ツールだと思います。いくつかの障害をデバッグしたい場合、IDE と非常によく統合されます。テストレポートは素晴らしいです。しかし、私はそれらが CD スペースでそれほど進んでいるとは思いません。私の意見では、両方が必要です。しかし、CI だけに興味がある場合は、見てみるとよいでしょう。ただし、以下で説明した GoCD の優れた機能の一部を見逃してしまうことになります。
Jenkins には巨大なコミュニティがありますが、Jenkins には独自の欠点があります。たとえば、互換性の問題などで、別のプラグインが原因で 1 つのプラグインが機能しないことがよくあります。
GoCD には、多くの不要なビルドを回避するファンイン/ファンアウト サポートがあり、ビルド時間とリソースを大幅に節約できます。バリュー ストリーム マップは直感的で、開発者、QA、さらには配信マネージャーの視点からビルド ステージをよりよく把握するのに役立ちます。GoCD のパイプライン モデリングも非常に優れています。Jez Humble と David Farley の継続的デリバリーに関する本を読むと、このようなビルド設計の背後にある力がわかります。
さて、あなたの2番目の質問に：
ファンイン ファンアウトのサポートと継続的デリバリー パイプラインの視覚化により、現在 GoCD に傾倒しています。このツールの問題をサポートした経験のある人はいますか?
それを聞いてうれしいです：PIはGoCDが大好きです。サポートは良好です。オープン ソースの方法を選択した場合、メーリング リストは非常に活発です。1 日か 2 日以内に GoCD チームからの返信が期待できます。もちろん、質問は誠実で具体的でなければなりません。質問を投稿する前にフォーラムに目を通すと役立ちます:)
また、ThoughtWorks から GoCD のサポートを購入することもできます。以前は複数のサポート層を提供していましたが、現在のサポート モデルは不明です。問題に直面するのは、DB が大きくなりすぎたとき (~5 ～ 7 GB) で、ThoughtWorks の独自の Postgres DB サポートが必要な場合があります。そのDBサイズを持つGoCDのユーザーはほとんどいません。
Teamcity で多くの経験があり、Gocd でいくつかの経験があります。ファンイン/ファンアウトに興味がある場合は、Teamcity で同じことを行うこともできます。これはBuild Chainsと呼ばれます。また、公式ブログにこのトピックに関する良い投稿があります。選べるとしたら、Teamcity の方がいいと思います。企業環境での使用に適した、より成熟した機能豊富な製品です。