15分枠(1) hisa9chi：「MacStadium使ってみた」
- 発表資料
- SWETチームの方
- 開発現場で抱えている課題
- 物理的リソース
- 物理マシンの設置スペース
- 電源容量問題
- 調達速度
- ハイスペックマシンが届くまでに1ヶ月くらいまつ
- 管理コスト
- 物理マシンのアップデート
- 拠点定期メンテによる停電対応
- オンプレではなく、クラウドサービスを活用できないかと考えた
- 物理的リソース
- MacStadiumとは
- macOSの物理マシンのホスティングサービス
- 物理マシン払い出し
- 類似サービスよりもハイスペックなマシンを提供
- マシン管理はWebUIのみ
- サポートは24時間週7日
- 料金体系
- 1マシンあたり1ヶ月定額（前払い）
- データセンターはどこでやっても同じ値段
- Add-Ons
- IP,Storage,Subnet,firewallなども追加できる
- サポート
- 24/7、電話、Live Chat、チケット発行など
- 基本操作
- マシンの追加などの流れの説明
- ログイン情報はチケットinstallationにかかれている
- マシンの起動停止もGUIで
- ハードリブート、設定によっては再起動しないので注意
- マシンの返却はCancelボタンでできる
- Add-Onsの追加もGUIで
- 利用料金の確認は1ヶ月単位で確認できる
- 全体の利用料金を確認するすべはない
- ユーザーの追加、Roleと権限を設定して追加
- Jenkins slave環境構築CI
- 構築運用コストがかかる
- 環境構築CI
- アクセス制限、Firewallは契約していないがmacOS標準機能を利用
- packat filterを利用
- GIthub Enterpriseへの接続
- VPN経由でのアクセス
- openvpnコマンドでコネクションを確立する
- slave環境構築スクリプトを実行してみた感想
- 物理マシンと変わりなく利用でき、速度も問題なかった
- データのやりとりは体感ちょっと遅いかなといった感じ
- まとめ
- ハイスペック、速い、物理マシンなのでカスタムイメージは利用不可 - サポートは24 x 7
- 料金は1マシン毎に1ヶ月前払い定額制
- マシンの起動停止はWebUIのみ
- アクセスはVNC or SSH
- 工夫次第でコストを削減できそう
- 実運用に耐えうるか評価が必要
15分枠(2) manabusakai：「CI/CD パイプラインを最速で組み立てるための 4 つのポイント」
- 発表資料
- freeeの方、2018年はほぼ毎日プロダクトをリリースしていた
- パイプラインファースト
- 理想は1発目のデプロイからパイプラインを通す
- rails newしたい気持ちを抑えて最速で組み立てるには
- 最速で組み立てるための工夫
- いきなりCIサービス上で試そうとしない
- 問題点
- CIサービス上で試しているとトライアンドエラーしずらい
- 解決策
- circleciコマンドでローカルのdockerでテストできる
- まずは愚直にシェルスクリプトを通す
- ワークフローは使えないので1つのビルドステップで試してから分割する
- .circleci/config.yml を書き始めるときは circleci コマンドを使うと効率が上がる
- 問題点
- 依存関係のインストールは事前にすませる
- 問題点
- パイプラインの中で依存関係のインストールをしない
- apt installなどはキャッシュをきかせにくい
- 外のサービスなので落ちてると一緒に落ちる
- 設定ファイルが複雑化する
- 解決策
- 全てインストール済みのdocker imageを用意しておいてpullする
- pullするだけでいいので実行時間の短縮になる -自分たちでメンテしないといけないデメリットはある
- 問題点
- 車輪の再発明やコピペを避ける
- CI/CDの知識は暗黙知かしやすい
- 設定ファイルを一から書くことはあまりない
- 既存の設定ファイルをコピペして、プロジェクト毎に進化していく
- 解決策
- CircleCi Orbsを活用する
- よく使う共通処理をパッケージとして呼び出せる機能
- CertifiedはCCiがメンテしてくれる
- docker buildしてecrにpushする処理が数行でかける
- aws cliのインストールやdocker loginすら不要
- CIとCDを適切に分離する
- 問題点
- CIパイプラインの延長線上でCDパイプラインを組みがち
- 迅速にRevertすることが難しい
- パイプラインが分離されてないと余計なステップが発生する
- CIサービスに強い権限を付与しないといけない
- 解決策
- CiとCDを疎結合にする
- CIからのWebhookをトリガーにCDをキックする
- e.g. k8sならGitOps
- 問題点
- いきなりCIサービス上で試そうとしない
- 発表資料
- @tihimsm
- CI環境を整備した経緯
- リリースを任されたが、CI環境なんかなかった
- 以前のデプロイ環境
- リリース用アカウントが入ったMacでしかリリースできない
- 属人化
- 手動でコメント切り替え
- ブランチによってコードやファイルの中身が違う
- テスト配信を別アプリとしてAppStoreConnectにアップしていた
- アプリのフルリニューアルが迫ってきた
- やったこと
- 適当な順番で優先順位がぐちゃぐちゃだった
- dSYMファイルのアップロードとかを先にやってしまった
- 証明書とか大事なとこが後になった
- 1.5ヶ月くらいかかってしまった
- 過去の自分にアドバイスするなら赤文字から先にやっていく
- まずはここから整えよう
- テスト配信の自動化
- 証明書を完全に理解している人、手上がらず
- 怖くないiOSの証明書が詳しい
- 証明書周り
- fastlaneのmatch
- 証明書やppを作成して暗号化してGithubリポジトリで管理できる
- readOnlyで上書きせずに証明書を取得できる
- リポジトリにadmin権限をつけて管理
- 複数アプリでリポジトリを分けるべき？
- SwiftLint
- 静的解析ツール
- Danger
- PRへの指摘の自動化
- fastlaneがサポートしている
- まとめ
- ミスをしてはいけないところから（リリースなど）
- 工数が大きいところ（テスト配信）
- コミュニケーションコストが大きいところ（証明書）
- イライラしがちな所（レビューや静的解析）
10分枠(2) ikesyo：「Travis CIのBuild Matrixを活用して、Swift製ライブラリをLinux対応させる」
- 発表資料
- はてなで働いています。京都から来ました。Swiftのコミッターです
- Swift製ライブラリの話
- Swift Packages
- Swift Package Manager（SwiftPM）
- 2016年から導入された
- Package.swiftというマニフェストファイル
- ここに依存関係などを定義する
- サーバーサイドswiftのものだった
- wwdc2019でiOS向けにも使えるようになりました
- Server Side Swift
- Swift on Linux
- OffiicailにはUbuntuやFedoraをサポート
- 普通のSwiftプログラマーはmacOSとXcodeで開発している
- ローカル開発
- Dockerを使う
- swift-docker
- 複数バージョンでテスト
- 複数バージョンサポート、互換性の確保にCIが有効
- Travis CI
- Build Matrix
- LinuxだけじゃなくてmacOSも使える
- OSS向けには無料で使える
- macOSの同時実行数は2まで
- 1ジョブあたりのビルド時間の上限が50分
- Buiild Matrix
- 環境の組み合わせを記述できる
- rvm2.2と2.5とか
- excludeもできる
- includeでmacとlinuxをテストする
- ymlで定義するのでymlのアンカーとaliasで重複を避ける
- swiftenv
- バージョンマネージャー
- rvm系と似たようなもの
- Travis CI上でdockerを使うのは面倒なのでこれで楽をしている
- Bitrise
- 並列実行不可
- CircleCi
- macOSは1並列（メールで連絡する必要がある）
- WorkflowsはBuild Matrixみたいに柔軟な並列実行ができる
- Azure Pipelines
- 10並列できる
- OSS向けの無料プランあり
5分枠(1) ShuheiKitagawa：「5分でわかった気になるTEKTON」
- freeeのSREの方
- CD.FOUNDATION
- TEKTONがホストされることになった
- knativeのサブプロジェクト、Knative Build Pipelineだった
- Tekton Pipelineとして独立した
- Tekton Pipeline
- k8sのカスタムリソースを用いる
- pipelineやtaskをリソースとして定義する
- リソースをk8sにapplyして実行
- k8sのymlっぽい
- 使い方
- CI/CDとして直接使う
- Pipelineの実行エンジンとして使える
- 各CI/CDベンダがpipelを独自実装している
- tektonを使うと
- pipelineの実行部分にtektonへ委譲
- pipelineが標準化されるとエコシステムが生まれる
- Circle CIが採用するとTravisでも使えるような未来
- Tekton Pipeline 2019
- webhook とか
- まだci/cdとして利用するのは時期尚早
- 開発者として参加するのは面白い時期
- Tektonはk8sベースのci/cdコンポーネント
- 発表資料
- @yukimikan88
- JapanTaxi Software Engineer in Testをしている方
- Software Engineer in Testとは？
- テストを中心としたエンジニアリングで品質に貢献する組織
- jtの説明
- 配車PF
- SETでやっていること
- QA体制の構築
- テストプロセスの確立、運用、改善サイクル
- 組織横断、複数プロダクト（年内）
- シフトレフト（下流から上流へ）
- E2Eテスト自動化環境
- メインシナリオのテスト
- QA体制の構築
- 実現したいこと
- 最新のソースをとって、apk,ipaをとる
- そしてe2eをやる
- CI
- bitrise
- 社内macでe2eを動かす
- bitrise -> s3 -> mac -> appium -> TestRail -> Slack
- s3のlatestという固定値から最新版がとれる
- マニュアルのリグレッションテストの負荷を下げようとしている
- 今後
- テスト自体が難しい環境起因の問題のか前
- リグレッションテストの自動化やりきる
- 並列化、スクショなど
- 発表資料
- @siro_uma
- こんな時代にCIにお金をかけるべきか
- CIサービスのお値段はそこそこ高い
- Azure Pipelines
- Azure DevOpsの中のCIサービス
- OSSに優しい
- 優しさ
- １０ジョブが並列、毎月の時間制限なし
- 1プロジェクト無料、1ヶ月あたり1800分
- 環境
- azule pipeline, macなど
- yml
- Appium serverのためのnodeのバージョンの指定
- pythonも同様にバージョンの指定
- appiumはnativeでサポートされているわけではないのでbashで叩いていく
- pytestによるappium e2eテストの実行
- CIのE2Eテストのデバッグ辛い
- appium
- start_recording_screen()で画面をレコーディングしてデバッグしやすく
- brew install ffmpeg
- appium