2019/06/20 CICDTestNight #4 行ってきた

=====

2019/06/20(木)
19:00 〜 22:00
@渋谷ヒカリエ21F DeNA

ハッシュタグ #cicd_test_night

地味なテーマ（司会者談）ながら、回を重ねるごとに参加者数が伸びている、らしい。私は初参加。

先に所感

• 『パイプラインファースト』広めたい
  • 『至高のCI/CDパイプラインを実現する5つの約束』は皆様読んで欲しい
• モバイルアプリ界隈の話題が多かった、勉強にはなった
  • Bitrise とかMacOSビルドとか
• SETやSREの人ばかりが登壇
  • 総人口は多くないにせよ、アピールしてくるなぁ（いいなぁ、羨ましいなぁ）
• TEKTON ちょっと気になる

hisa9chi：「MacStadium使ってみた」

DeNA SWETグループ所属の井口恒志さん
CircleCI Japan Usesr Group コミュニティリーダー

• 課題
  • 物理リソース
    • 物理マシンの設置スペース
    • 電源容量問題
  • 調達速度
    • 開発者の手元に届くまで約1ヶ月待つこともあり
      • ハイスペック・カスタム時
  • 管理コスト
    • OS/SWのアップデート
    • 定期的な停電対応
• そこで
  • オンプレの物理マシンではなく、クラウドサービスの活用
  • MacStadium 使えるのでは？
• MacStadium
  • macOS物理マシンのホスティングサービス
    • 物理マシンお払い出し
  • 特徴
    • 他の類似サービスに比べ、ハイスペックマシンもOK！
    • マシン管理はWebUIのみ
    • サポートは２４ｘ７
  • 料金体系
    • 1マシンあたり1ヶ月定額（前払い）
    • 1台単位での月定額制
      • 追加したマシンを返却→追加すると2台分かかる
  • データセンター
    • 場所による料金の変動なし
  • Add-Ons
    • 追加IPやファイアウォールも可能
  • サポート
    • 電話
    • Live Chat
    • 問い合わせチケット
• 基本操作
  • マシンの払い出し
  • ログイン：パスワードは払い出し時に生成されるチケットに記載される
  • WebUI上から、Macの起動停止ができる
  • 利用料金の確認
  • ユーザの追加・ロールの設定
• Jenkins Slave環境構築CI
  • SWETでは、社内的にJenkinsのつらみを軽減する施策を実施中
  • MacStudioでJenkinsスレーブ用環境構築用のマシンを調達
  • アクセス制御
    • plistを使った（ファイアウォールのお金を今回はケチった）
  • アクセスはVNC or SSH
  • OpenVPNでMacStudioからGHEにアクセス
    • AWS上にVPNサーバを用意、ふむふむ
  • 動作速度は（ハイスペックなので）快適だった
• まとめ
  • 試してみただけ、なので実運用に耐えるかは引き続き評価

Macのホスティングサービスというのも出てきているんですね。今回はMacOS系のビルドサーバ用途ということでしたが、弊社でもニーズがあるのでしょうか？
社外からのGHEアクセスは事例は興味深いものがありました。セキュアに、そういった利便性を確保していきたいですね。

manabusakai：「CI/CD パイプラインを最速で組み立てるための 4 つのポイント」

• freee のSREの人
• 資料
  • TBD
• 昨年のリリース数　278件（ほぼ毎営業日）
• 「パイプラインファースト」をやっているか？
  • まずはアプリを作り始める前に、パイプラインを組み立てる
  • Web TBD
• 今回はCircleCI前提
  • ポイント１：いきなりCIサービス上で試そうとしない
    • ローカル環境の circleci コマンドで動作確認／デバッグできる
    • 詳細はQiitaに記事がある
  • ポイント２：依存関係のインストールは事前に済ませる
    • パイプラインの中で依存関係のインストールをしない
    • キャッシュなど、設定ファイルが複雑化する
    • ビルドの依存関係をすべてインストール済みのDockerイメージを用意して pull するだけ
  • ポイント３：車輪の再発明やコピペを避ける
    • 既存の設定ファイルのコピペが散乱
    • CircleCI Orbsを活用する（共通機能がパッケージとして提供される）
  • ポイント４：CIとCDを適切に分離する
    • CIの延長線上でCDパイプラインを構築しがち、複雑化
    • 迅速にRevertするのが難しい
    • CIサービスに強力な権限を付与しないといけない
    • CIからのWebhookをトリガーにCDをキックする
      • Kubernetes環境なら GitOps
• まとめ
  • （ポイントの列挙）

『パイプラインファースト』という言葉があるんですね。言わんとしているところは激しく同意です。クリーンビルド＆デプロイができる環境が整ってからアプリ開発を始めようぜ、と。
プレゼン内で紹介されている 至高のCI/CDパイプラインを実現する5つの約束 も、ぜひ社内に広めていきたい考え。

TaiheiMishima：「Voicy iOSのCI環境をゼロから整えた話」

• Voicy「音声ｘテクノロジー」の会社
• CI環境を整備した経緯
  • iOSアプリの開発をしていたが、CI環境がなかった...
  • 壮絶な手作業によるリリース
  • 新規開発が迫ってくるヤバイ
  • CI環境を作るぞ
• やったこと
  • 順番めちゃくちゃ、1.5ヶ月くらいかかった（CI素人だったので）
• まずはここから整えよう
  • テスト配信/プロダクション配信の自動化
    • PM/QAに対して、開発者ローカルで動作確認をする必要があったので優先
    • 簡単に使える Bitrise を使った
  • ビルドコンフィグ系
  • 証明書まわり
    • iOSの設定まわりは面倒くさい
    • 証明書の更新とかとか
  • 静的解析
    • SwiftLint / Danger
• まとめ
  • ↓の順番でやるべき
  • ミスをしちゃだめなところ
  • 工数が大きいところ
  • コミュニケーションコストがかかるところ

この後のプレゼンでも度々出てくる Bitrise - Mobile Continuous Integration and Delivery は全然知りませんでしたが、モバイルアプリ向けのCI/CDツールとして定評があるみたい。
モバイルアプリ界隈の知見はほとんど持っていないので、ふむふむ、な内容が大半。

ikesyo：「Travis CIのBuild Matrixを活用して、Swift製ライブラリをLinux対応させる」

• はてな　の人
  • Swiftコミッター
• Swift のライブラリ作成
• Swift Package Manager(SwiftPM)
• Server-Side Swift
  • Swift on Linux
    • Swiftは実はLinuxで動く
    • 普通のSwiftプログラマーは macOS + Xcodeで開発してる
    • ローカル開発はDocker
      • swift-docker
    • 複数のSwiftバージョンでテスト
      • 手動ではやってられないのでCI
  • Travis CI
    • Build Matrix
      • 2x2x2 の8通りのOSバージョン／Swiftバージョン／環境でテストする、みたいな
    • ビルド環境にLinuxだけじゃなくmacOSも使える
    • バージョンマネージャ（swiftenv）
      • Travis CIのジョブでDockerを使うのは結構面倒だから使ってる
• Bitrise
• CircleCI
• Azule Pipeline
  • でも使えるよ

SwiftはLinux上でも動くんだ、ふ〜ん。Travis CIのBuild Matrix的な仕組みは、昨今どのCIサービスでも似た機能が実装されているので、多様な環境でのビルドテストが必要な場合に重宝しそう。

ShuheiKitagawa：「5分でわかった気になるTEKTON」

• freeeの人、SRE
• CD.FOUNDATION
  • にホストされることになったプロジェクト　TEKTON
• TEKTON
  • Knativeのサブプロジェクト、Knative Build pipeline
• Tekton Pipeline
  • k8sのネイティブリソースを用いたCI/CDコンポーネント
  • Pipelineを既存のPipelineの実行エンジンとして使える
    • パイプライン実行部分の標準化（CIサービスごとの際を無くしたい）
• 現在
  • v0.4
  • 2019年中には v1.0
  • 今はまだ機能が不足しており、実務で使うには時期尚早
  • 今なら開発者として参加するのがおすすめ

資料が公開されていませんが、気になったセッション。まだ実用化に足る段階ではないものの、CI/CDパイプラインのエンジン部分を標準化しちゃおうぜ、というもの。これが実現できると、どのCI/CDサービスを使っていても同じ定義で実現できるようになるので、利用者としては嬉しい一方で、サービスの差別化も難しくなってきそうだな、と。

• Tekton  |  Google Cloud
• Tekton - GitHub

Yuki Tamazawa：「ソフトウェア品質を支えるE2Eテストのビルドパイプライン作り」

• JapanTaxi の人, SET
• SETは3名体制（社員）
• JapanTaxiの紹介
• やっていること
  • QA体制の構築
    • テストプロセスの確率・運用・改善サイクル
    • 組織横断・複数プロダクト
    • シフトレフト
  • E2Eテストの自動化
    • メインシナリオが正しく動くことを常にチェック
• 実現したいこと
  • ビルドは bitrise
  • E2Eテストの実行環境は、社内のMac
  • テストしたら結果をSlack通知
    • URLからテスト結果の詳細を確認
• 行灯ラボ（Blog）をよろしく

ここでも出てきた Bitrise。そして TestRail、これはテスト管理ツールだそう。以前、弊社内でCATを試して花咲かなかったことがあったようですが、Excelでテスト仕様書を書くのはよいとしても、テスト管理はWeb化リアルタイム自動化したいところなので、これも検討してみてもいいかもしれない。

ikuma_hayasaka：「老後必要資金2000万円時代に送る、Azure Pipelinesによる継続的テスト」

• SET @ Sony Interactive Entertainment
• こんな時代にCI/CDにお金を払っている場合なのか
  • Privateリポジトリ運用はCIビルドにお金がかかる
• そこでAzule Pipelines
  • Microsoftの優しさ
• 個人開発者が無料枠で試してみた
  • 試験対象は個人開発のiOSアプリ
  • pipeline は yml ファイルで書く
    • 実際はGUIエディタでもできる
  • テストは失敗しがち、デバッグしづらい
    • テスト実行中の録画ができるAPIがある
  • Azule Pipelineなら無料で結構できる！

やはりモバイルアプリ開発なみなさまはmacosでビルドしたくてBitriseなんだなーとしみじみ。Azule Pipelineを推している人は、他の登壇者でもいたので、今後ぐぐっと勢力を広げてくるかも、ですね。

mats：「expoアプリ開発におけるCI/CD」

（残念ながら登壇者が欠席）