Diary

@ssig33

CircleCI (Performance Plan) vs. Github Actions

結論: CircleCI を買おう

現在ユビレジでは CI は CircleCI (Performance Plan)と TravisCI を使っていて、

  • CircleCI:
    • サーバーサイド(いろんな言語がある)
    • Web フロントエンド(Rails アプリのなかで webpack が動いていたり、 create-react-app で作られたペラっとしたものがあったりいろいろある)
  • TravisCI:
    • iOS アプリ

というような感じで使い分けている。 Performance Plan なんだから iOS のも Travis から引っ越せばいいんじゃねえの?と思わんでもないのだが、

  • Travis の annual 課金がまだ残ってる
  • iOS の CI と TravisCI と CircleCI に全部詳しいかつやる気がある人はいない

という事情があり、このようになっている。

ここで CircleCI の Performance Plan について簡単に説明すると

  • 課金体系は従量課金
    • 使ってる人数*月15ドルの固定課金
    • 使ったインスタンスの時間あたりの課金
  • 並列数は無制限
    • 昔は UI 上 200 並列が上限であるように見えてたけど実際どうなのかは不明。この表示自体はシステムを従来プランと使い回していた故のように思える
    • 200 並列にまだ頭ぶつけたことないので実際どうなのかは知らない、気になる人は営業に問い合わせてみましょう
  • 開始時に営業に問い合わせが必要
    • 日本ブランチはあるので日本語でやり取り可能です

といった特徴があります。簡単に言うと安くて便利。というわけで CircleCI Performance Plan でテストを回していたプロダクトの一つで Github Actions を使ってみることにしました。

Github Actions はだいたい以下のような特徴があります

  • リポジトリごとに 20 並列までいける
  • OSS なら無料、 Private は 11 月から有料化
    • プランはまだ未発表
  • 裏側には Azure Pipelines というものが使われている

今回何故か Beta 開始日から我々の組織では Actions (CI)を使うことができたので、今回僕が面倒(?)をみているプロダクトの一つで Github Actions を使用してみました。 create-react-app で開始した SPA で(現在では eject 済み)、純粋に Web フロントエンドだけが存在しているリポジトリです。テストは全て E2E テストで、 jest-puppeteer を使っています。あんまり関係ない話ですがどうも Web フロントエンド界隈ではコンポーネントのユニットテストと型でアプリを守るという思想が流行っているようですが、これらは全て無意味だと僕は思っています。型は VSCode の補完で便利という程度に捉えておくほうがよいと思う。ユニットテストはクソ。

リポジトリごとに 20 並列という制限は、大規模なモノリスがあり多くの従業員がそこで作業をしているという場合簡単に頭をぶつけることになるでしょう。ただし今回僕が Actions を仮投入してみたプロダクトは開発者が 3 名しかいないプロダクトでしたのでそこが問題になることはありませんでした。

プランについては発表しようにも評価のしようがありません。

裏側である Azure Pipelines というか CI の実行部分については、これはもう悲惨としか言いようがない水準です。

今回 CircleCI と平行するかたちで Github Actions の利用をはじめ、落ち着いてきたら Actions のほうだけに統一みたいなつもりでいたのですが、一向に落ち着くことはなかったので 8/13 に使用しはじめた Github Actions ですが 9/4 で使用を中止し CircleCI だけに戻しました。

あまりにもサービスの品質に問題を感じるため、周囲のエンジニアにインタビューをとってみましたが、 Azure Pipelines 自体が悲惨な品質で、リリース以来あまり改善されてこなかったという話をいくつか聞くことができました。

なお、今回のプロダクトでは CI で実行するあれこれの処理を Makefile に記述し、 CI の設定ファイル内では make hogehoge みたいのだけを書くようにしていたこともあり、 Github Actions の利用開始自体は 30 分もかからずに行なうことができました。このあたり一切面倒なところはありません。

全体として、 Github Actions は非常にストレスフルなプロダクトで、仕事としてやっているプロダクトで金銭的な出費が許される場合には CircleCI の Performance プランを使用することを強くオススメします。11 月に発表される料金がかなり安かったとしてもそれはそうで、出費を節約した結果 CI の不可解な挙動でエンジニアの生産性が落ちるようでは話になりません。

Azure Pipelines の改善が進まなかったことには、そもそもサービスのユーザーが多くなくメトリクスなりユーザーの意見なりを十分に収集できていなかったという可能性はあります。今後 Actions 経由でこれを利用する開発者が増えれば改善されていく可能性はあります。ただし、僕はこれまで Azure のマネージドサービスについて多くの場合において品質面での問題を感じていました。今回だけまともになることあるかなあ、、、

来年の夏ぐらいにまた検証してみたい。

17 Sep 2019 Tue 05:01 (UTC)