Buddyを触ってみた

[![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/107221/fb728c6c-43ec-bf49-fca1-686f2b69681f.png)](https://buddy.works?utm_source=qiita_matsu4ki&utm_medium=refferal&utm_campaign=content_jp_bz)
今回、BuddyというCI/CDサービスを教えてもらったので、少し使ってみました。筆者のCI/CD経験はGitHub-Actions、TravisCIを少し触ったことがある程度です。

CI/CDがよくわかってない方は、[CI/CDの基本](https://qiita.com/Hiroyama-Yutaka/items/75322f52eee163abf76c)がわかりやすかったのでオススメです。

# Budyとは？

SaaS型のCI/CDツールです。
[Buddy公式のHP](https://buddy.works/)を確認すると、

- 導入時間の速さ
- 100以上の連携アクション
- CI/CDの速さ

が売りのようです。

# Buddyを実際に使ってみる

OJT用に作ったアプリがあったので、このアプリのビルド確認とNetlifyへのドキュメント展開のパイプラインを作成してみました。

1. ログインすると、プロジェクトを作ってみようと言われるので、Create new projectを選択します。
![Screen Shot 2020-08-25 at 1.05.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/107221/0cf0c38e-c91e-9007-7d5a-0ef46f445561.png)

1. リポジトリを選択すると、プロジェクトが作成されます。
1. パイプラインを作成していきます。トリガーのタイミング、どのブランチで実行するかなどを聞かれるので、設定しします。
1. PipeLineの設定をします。リポジトリ内で利用されていると思われるツールが提案されるので、最初に実行するものを選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/107221/85b47720-d0a9-2332-11c4-b5111e52abe1.png)

1. アクションを追加すると、PRIMARY ACTIONSに先程追加したものが表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/107221/129e6dc2-0027-294e-4c0c-c778ef0f3f1a.png)

1. 後は、上下の+を押して、必要に応じた処理を追加していく形です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/107221/8973b2a5-6b85-62d9-6f0e-0b973425bb16.png)

処理が失敗したときや、失敗した処理が正常に戻ったときに通知を行うことも可能です。
自分の場合はDiscordに通知が飛ぶようにしてみました。WebHookのURLを登録するだけです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/107221/927ec4c0-3696-3a2b-d0ee-f008257828b3.png)

わざと落としてみたら、こんな感じで届きました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/107221/472d197a-82e9-8de6-33a5-11da8cade4d5.png)



# 使ってみて

パイプラインの流れ、環境変数の設定、キックする条件やアプリ間の連携などが全てGUIベースで行えるので、ポチポチしているだけでかんたんに設定ができました。パイプラインがビジュアル化されているため、CI/CDに疎く、普段yamlファイルを読まない方でも始めやすいです。
公式ドキュメントについては、図が多く、英語のテキストも手順や箇条書きベースでかかれておりました。なので、英語が苦手な方でも比較的簡単に始められそうです。

## メリット

- taskの関係はビジュアル化されているので、フローを理解しやすい
- yamlファイルを書かなくて良い(yamlファイルで書くことも可能)
- 言語やツールに合わせたタスクが用意されているので、基本的にビルドコマンドを書くだけで動く
- [公式ドキュメント](https://buddy.works/docs)が親切
- GUIでも、勝手にバージョニングしてくれている
    - [New feature: Version History for Pipelines | Buddy: The DevOps Automation Platform](https://buddy.works/blog/pipeline-version-history)

## デメリット

- 前のバージョンに戻す作業は大変そう(詳細未調査)
- 無料版だと5プロジェクトの制限がある
- 日本語の情報が少ない

# 料金

細かく比較するのは大変なので、とりあえず最初に触る無料枠と有料での最安プランで比較します。
ここでは、主に金銭面と性能制限の観点から見ています。

## 無料枠

|無料枠|リポジトリ数|パイプライン/Job<br>並列実行|パイプライン/Job使用制限|サーバーOS|サーバースペック|
|:---:|:---:|:---:|:---:|:---:|:---:|
|Buddy|5|1|120回のパイプライン処理/月|Linux<br>(他見つけられず)|CPU:2<br>キャッシュ:512MB<br>RAM:1GB
|TravisCI|無制限<br>(OSSのみ)|5ジョブ並列実行|無制限|Linux/OSX/Windows|[OSによって差あり](https://docs.travis-ci.com/user/reference/overview/#virtualisation-environment-vs-operating-system)|
|GitHub-Actions|無制限|並列処理の記述なし|GitHub-Actions利用時間2000分/月<br>GitHub Package利用500MB/月|Linux/OSX/Windows|CPU:2<br>RAM:7GB<br>SSD:14GB|
|Circle-CI|無制限<br>(記述なし)|1|2500クレジット/週|Linux/Windows|クレジットの仕様上、可変になる|

無料枠だと、やはりGitHub-Actionsが良さそうです。
OSSであれば、Travis-CIでも良いかも。

## 有料枠最安値

|有料最安値|お値段|リポジトリ数|パイプライン/Job<br>並列実行|パイプライン/Job使用制限|サーバーOS|サーバースペック|
|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
|Buddy|$75/月|20|1|無制限|Linux<br>(他見つけられず)|CPU:2<br>キャッシュ:10GB<br>RAM:3GB
|TravisCI|$69/月<br>$63/月(年契約)|無制限|1|無制限|Linux/OSX/Windows|[OSによって差あり](https://docs.travis-ci.com/user/reference/overview/#virtualisation-environment-vs-operating-system)|
|GitHub-Actions|$4 1ユーザー/月|無制限|並列処理の記述なし|GitHub-Actions利用時間3000分/月<br>GitHub Package利用2GB/月|Linux/OSX/Windows|CPU:2<br>RAM:7GB<br>SSD:14GB|
|Circle-CI|$30~|無制限<br>(記述なし)|必要に応じてスケール|クレジット次第？|Linux/OSX/Windows|クレジットの仕様上、可変になる|

課金を前提としてなら、Circle-CIが良さそうですが、
金額が固定ではないので、固定金額にしたいのであれば、BuddyやTravis-CIは考慮しても良いと思います。

# まとめ

連携できるアプリも多く、使用感も悪くないのでCI/CDの入門やyamlファイルに書いていくのが苦手な人、手軽にCI/CD環境を用意したい人には良いサービスだと思います。
日本語の情報がほぼないのがしんどいですが、仕組みやドキュメント自体は良いと感じました。
どうしても英語は無理！という方以外なら、使ってみても良いと思います。