イベントレポート: CI/CD Test Night #3に参加しました

こんにちは。エンジニアの中川です。

“Speed up your Business”を旗印に数々のソフトウェアの高速化に取り組んでいるフィックスターズでは、ソフトウェア開発そのものを高速に、効率的にするためのSaaSプロダクトを開発中です。その開発には継続的インテグレーション(CI: Continuous Integration)や継続的デリバリー（CD: Continuous Delivery）を導入しています。これはソフトウェアの開発中に、プログラムのビルド（組み立て）、正常に動作しているかの試験を自動的に行い、品質が担保されたソフトウェアを迅速にリリースするための仕組みです。このCI/CDを活用することにより、安全で効率的、そして高速なプロダクトリリースができる体制を構築しています。

そんなCI/CD技術の勉強会である、CI/CD Test Night #3に参加しましたので、レポートを掲載します。

今回の会場はDeNA本社（＠渋谷ヒカリエ）でした。大きなセミナールームでの開催でしたが、ほぼ満員でした。LT前にソフトドリンク、ビールなどが配布されました。私は用事があったので参加できなかったのですが、発表終了後の懇親会では🍣がでたようです。

fastlaneとBitriseで構築するiOSのCI/CDレシピ

ミクシィで家族アルバム みてねのiOSアプリ開発を担当しているrockname（@rockname）さんによる発表。これまで社内で自主運用していたCI/CD（Jenkins + Hubot）から、モバイルアプリに特化したクラウドCIであるBitriseと、モバイルアプリ開発向けのタスクランナーであるfastlaneを組み合わせた環境に移行した話でした。

Pull Requestに対応してビルド・テストするのはCI/CDのメインの話ですが、依存ライブラリのアップデートを監視して、最新版が出ていれば、それを取り込んだPRを自動生成するみたいなアイデアは新鮮でした。（このテクニックは他の発表でも話題になったので、定石なのかもしれません）。他にもCI/CDを使ってビルド時間を毎晩計測する、などの話題も興味深かったです。

Automate All the Things

GMOペパボでminneの開発を担当されているjkaplanさんの発表。「自動化が好きだ」と自己紹介されていた通り、ビルド・デプロイに限らず、開発に関わる様々なタスクの自動化を紹介されていました。

個人的に面白かったのは「コミット時にコード中をスペルチェックする」です。「間違った英語を使うと検索性が落ちる」という観点は今まで持っていなかったので新鮮でした。他にもビルドキャッシュなどのテクニックを用いたCI高速化の話も興味深かったです。

10分でわかるGitHub Actions

GitHubのソリューションエンジニアであるikeike443（@ikeike443）さんの発表。最近GitHubでbetaテスト中のワークフローツールGitHub Actionsについての発表でした。

GitHubのイベントをWebhookでキャッチして外部サービスの処理にアクションを起こすのはよく行われていますが、それと同等のことをgithubの中だけで簡潔できるような仕組みのようです。おもしろいのは、一般的に必要そうな道具（定番のクラウドプラットフォームの操作、コマンドラインツール）が標準で豊富に用意されていたり、作成したworkflowを公開するためのマーケットプレイスも準備されているところです。

Jenkinsのつらみを軽減した話

DeNAの社内で、開発生産性と品質向上をミッションとしているSWETで活動されているtheoden9014（@theoden9014）さんの発表。

「ゲームアプリのビルドは重いので、クラウドCI (Travis CI)ではなく、リッチな計算機オンプレでJenkinsを使わざるをえない（ことが多い）」というのはなるほどです。発表では、各所で乱立するJenkinsクラスタをクラウド + Ansibleで自動構築する方法や、そのAnsibleのPlaybookを自動検証する手法、Jenkins Pipelineの活用などが主な内容でした。

CIをGASで継続的に改善したら幸せになった

pixivでiOSアプリの開発を担当しているkwzr（@_kwzr_）さんの発表。アプリのCI環境をJenkinsからモバイルアプリに特化したクラウドCIであるBitriseに移行した話でした。

技術的な話もおもしろかったですが、Bitriseの契約プラン（どのぐらいの性能、並列数でビルドできるか変わる）を決めるために、GAS (Google Apps Script)を使って 定量的にデータを集めて検証した、という話題が面白かったです。「デベロッパのヘイトを減らすためにCIサービスの契約をアップグレードする」というくだりに感銘を受けました。

CI/CDと継続的ワークフロー改善

Nest EggでiOSアプリの開発をされているgaussbeam（@gaussbeam）さんのLightning Talk (LT)。

前回のCI/CD Test Nightに触発されてCI/CDの導入を進められた、とのことでした。ビルドとデプロイの自動化からスタートし、いまではライブラリの更新チェック（rocknameさんの発表で言及したものと同じと思われる）、iOSアプリのAppStoreでの処理を半自動化などに使っているそうです。「せっかくCI/CDを作っても対象者に使って貰わなければ意味がない、CI/CD環境とヒト（体制・風土）は両輪」という話は、我々のCI/CD環境でも意識しよう、と感じました。

GitHubと連携するCIを作る

duck8823（@duck8823）さんのLT。既存のCIシステムに問題を感じているので、自分でCIシステムを作ったという発表でした。

GitHubのWebhookを利用して実行タイミングを取り、Dockerで構築した環境でCIを実行、結果をGitHubのCommit Statusに表示する、という仕組みです。CIの設定ファイルの学習コストが大きいときは、こういう選択もアリですね。発表で解説した独自CIサーバはhttps://github.com/duck8823/duciで公開されています。

社内の遊休PCをAzure PipelineでCI/CDに活用しよう

nakasho（@nakasho_dev）さんの発表。Azule Pipelineを利用して、クラウド上の計算リソースに加えて、社内の遊休PCをCI/CDのRunnerとして利用している、という内容でした。

Azule Pipelineでは、クラウド上で利用できるRunnerに加えて、クライアントをインストールした任意のPCをRunnerにできる仕組みがあるそうです。これにより、Azure Pipelineの無料枠ではカバーできないようなタスクもその枠内で実行することができます。CIのコントロールをクラウドに任せているので、独自でCIシステムを作るケースと比較して、CIステータスを社内、社外問わずに共有できるなどのメリットもあります。

おわりに

発表全体を通して感じたのは、「こういう使い方もあるのか！」という驚きでした。これまでは、CI/CDに関してソフトウェアのビルド、テスト、デプロイの自動化しか念頭にありませんでしたが、ライブラリの更新検出、プログラム中のスペルチェックなど様々な応用は目からウロコでした。私達のプロダクト開発でもうまく利用して、価値のあるソフトウェアをタイムリーに提供していきたいです。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。