CircleCI ユーザーコミュニティミートアップ #3 https://gyazo.com/62f2a6ebaec1594a387880037fa07120
澤田 翔太
クラウドワークスにおけるCircleCIの歩み
2016/03に1.0移行
2017/03に2.0移行
2018/11に2.1移行
127Line => 1059 Line
レビューが大変になるので読みやすさが大切に
2.1を使っているか？
新機能おさらい
Executors
実行環境を定義する
docker/machine/macosなどが選択可能
シェルの種類
Commands
ステップを定義できる機能
各ジョブで実行させたいコマンドを便利に呼び出せる
Paramererized Jobs
workflow中にjobにパラメータを渡す
Orbs
commandsやjobs、executorsをパッケージとして使い回せる
うれしさ
偉人の記述をOrbで使える
重複する記述を共通化
yamlのaliasからも脱却
肥大化していた記述を読みやすい粒度に
思考コストが大きくなった
Orbをどう切り分けるか
どういう基準のCommand
パラメータのとり方
画面にお様わらにWorkflow
全体像が捉えづらい
解決策
Orbsの実装が隠蔽している
URLやコメントを多めに書く
code:config.yml
展開されたconfigで読むと読みやすい
configucationタブを見る
circleci config processコマンドで読むことができる
どういう基準で切り分けるか
Jobが何しているか俯瞰して読みやすい粒度に
ただし実行環境に依存している処理は無理に切り分けない
1回しか呼ばれないものはcommand化しないほうがいい
それくらいならコメントで区切る
パラメータ設計
責務で考える
中心となる処理
付随して行われる処理
一緒に使うが必要にならないもの => オプション化
Conditional Stepsを活用
when
unless
booleanだけじゃなく空文字でもいけたはず
bundle installで考える
中心となる処理 => bundle install
付随して行われる処理 => cacheのリストアと保存
一緒に使うが必要にならないもの => workspaceへの永続化
縦長になりがちなworkflows
filterの重複記述
https://gyazo.com/7f210b3c2b4ff270ac5eab59eb517e85
bundle-install, static-checks, yarn-install
つらみ
Worlflowの発火条件が複数箇所に書かれている
似たものをコピペで作ったときミスしやすい
ダミージョブで発火条件をまとめる
https://gyazo.com/ff9c4d3f8376ee1ed1c094e1522f4e63
Parameterized jobsを安易に使う
パラメータの分、縦長になる
Jobの意味がわかりにくい
意味のある名前を表示する
巨大Configファイルの分割
src以下にファイルを分割する
pushする前にconfig.ymlにまとめる
commitする前にconfig packでconfig.ymlを生成
最新であるかチェックするjobを追加
git diff --exit-codeでdiffが出ないかチェック
必要悪？
README.mdを書く
運用方法
ちゃんとしたcircleciの使い方じゃないから…
コメントが反映されないので、全体的な記述などはREADMEに書く
メリット
1ファイルの中で行き来するストレスが減る
jobやcommandsがファイルめになっているので俯瞰しやすい
デメリット
ローカルルールを決めて運用する必要
config.ymlが小さいうちはメリットなし
エンジニアであればconfig.ymlは誰でも触る
まとめ
展開したconfigを読もう
俯瞰して読みやすい粒度に
パラメータの適切な設計
workflowの発火条件
Parametarized Jobは意味のある名前にする
巨大configファイルは分割Orbのごとく分割する
梅崎 裕利
検索API
約300のリポジトリがCircleCIを活用
全部で約700リポジトリ
アクティブに動かしてるのは約200リポジトリ
5人で管理
デプロイ先
Docker imageをpushしてECRに
StandbyにデプロイしてE2Eが通ったらSwap よくあるCircleCIのworkflowと処理ステップ
https://gyazo.com/4cd1067184ce065cca7a6469724720c6
test
https://gyazo.com/4a4858a885557f3864391f70cf485d61
deploy
https://gyazo.com/bf3f01f3a8c50e59e04ade3eee7c4a79
https://gyazo.com/8dc070af072803593bbab93bb15877e1
CIの遅くなりがちな処理で困ること
テストの待ち時間が増える
デプロイに時間がかかる
CIのキューが溜まりやすくなる
それぞれの時間短縮方法
GitのCheckoutが遅い
まず確認する
executor imageにssh, gitは含まれているか？
fallback時はcheckoutが大幅に遅くなる
Gitのコードが多い時
Shallow cloneを利用する
Orbsを使うと楽
5GBリポジトリで90s => 60s
.gitをキャッシュする
逆効果の場合もある
リストア、チェックアウトを合わせると変わらない
キャッシュの保存でさらに時間がかかる
依存ライブラリのインストールが遅い
キャッシュする
注意
毎回キャッシュを使いまわししすぎて過大サイズになってないか
仮想環境が多重になり、何度もlibsを落としてないか
Docker build, pushが遅い時
Imageサイズを小さくする
SlimまたはAlpineイメージをチヨウ
レイヤ数を減らす
不要なファイルをイメージから除去
.dockerignoreを用意
イメージ生成にキャッシュを利用する手法
Imageをsave&cache
キャッシュを圧縮して保存すると効率的
Registory Imageをキャシュとして利用
us-east-1リージョンを使うと多少速い
Docker-layer-caching
有料オプション
ホスト内にキャッシュが残るために高速化される
その他
Docker 18.09 + DOCKER_BUILDKIT
cache-fromがまだ使えず梗塞にならず
Docker multi stage buildなら効果あるかも
まとめ
CIの実行時間は定期的に見直して高速化
高速化が逆効果になる場合も
ベストプラクティスは共有しよう
セッション3: CircleCI 2.1の機能を使って、インフラの全自動構成管理（？）をやってみた話 太田 航平
開発部 SREチーム
AWSやGCP上で技術スタックの調査・検討・実装、設計も担当 プロダクト
プライベートブランド「ZOZO」
インフラ構成管理自動化の動機
設計をどうするか？
反映のタイミングを全部で手でやるのは怖い
なのでできる限り自動化したい
全体のアーキテクチャ
リリース、マスターブランチ
CircleCi
Terraform
バケット
問題なければapplyする
ポイント
ステートファイルはGCSに保存
parameterを用いてワークフローを統一化
excutor, commandを使って共通化
Manual Approvalを使った環境の反映
2.1の新機能について
executor
command
parameter
orb
今回は未使用
必要な定義をコンポーネント化できるようになった
DRYにworkflowを書く
TerraformとCIの設計方針
極力コード化
環境依存をなくしてDRYに書く
Terraformのtfvars
Terraformで使う変数をCIから渡す変数で動的に読み込み
全体のworkflowを統一化できた
手動のオペレーションを減らす
plan => applyまでをCI上で完結
Manual Approvalを使う
CIのステップを手動承認
CIの画面から人間の目に入れて確認させたい場合などに用いる
https://gyazo.com/1ae7e94098ef0dfa5d020841c073bd29
何を自動化して何を自動化しないかを見定めることが重要
Jesse Katsumata
CircleCI Artifact
ビルドされた .jar ファイルや .ipa ファイルなどを格納できる。
静的サイトの Artifact
静的サイトのプレビュー
Test Coverage Report
毎回Artifactを見に行くのは確認が面倒では？
Klank
指定パスの Artifact を PR に対してコメントする
パッと見に行けるので効率がいい
使い方
config.yml で store_Artifacts する
Project の環境変数に CIRCLE_TOKEN, GITHUB_TOKEN をいれる
npm scripts に Artifact のパスをいれる
"klank": "klank ****/index.html"
デモURL
セキュリティ
LOC 10万行
アップグレード前 config.yml
testとdeploy jobのみ
静的解析、スタイルガイドなし
アップグレードの大変さ
CIの実行回数が増える
ジョブを改善してミスを減らして高速に行う
アップグレードの方針
専任者を立てる
外部のエキスパートに以来
レビュワーは最優先でレビューする
アップグレードと機能開発は並列的
導入・修正Pull Requestは最速対応
CIで静的解析ツールを全ファイルに実施
モチベーションを落とさない
対応したこと
RuboCop
auto-gen-config
brakeman
--no-exit-on-warn
--no-exit-on-error
erb-lint
Shopify
rails assets:precompileだけを実行するジョブ
rails db:rollback STEP=10 db:migrate rollbackテスト
jobの中に入れると便利