X-Tech JAWS & JAWS-UGアーキテクチャ専門支部 コラボ勉強会#01 に参加して
こちらの勉強会に参加してきました。
これに来たhttps://t.co/5q2sY0pX8B#xtecharchjaws01 #xtechjaws #jawsug
— ごましお (@halnique) May 29, 2019
CI/CD・パイプラインといったテーマが中心でした。
特にわかり味が深かったのが、やはりビジネスサイドや開発メンバーの理解を得るためにどうするかといったところでした。
リファクタリングとかでもそうですが、表面的に見えない部分のエンジニアリングをどう理解してもらうかというのは永遠の課題なのかもしれないなと、改めて感じた次第です。
以下メモを残しておきます。
X-Tech JAWS & JAWS-UGアーキテクチャ専門支部 コラボ勉強会#01
2019/5/29
X-Tech（エックステック）
AWSなどをハブとして用いるFin-Tech, HR-Tech, Health-Techなど
xTech（クロステック）
X-Tech同士のメッシュ
AWSを使っていて、技術とあまり縁がなさそうかつ尖ったことやってそうな企業にオファーしました
JenkinsからCI/CDをはじめてみた結果
@ユニオンテック株式会社 井上 心太さん
建設xテック
建設業は自動車業についで国内第二位の市場規模！！！
発注者x受注者の間で情報の非対称性が起きている
「仕事受けてくれる人が見つからない」x「仕事がない」
- アプリと管理画面を別々にデプロイしたい
- 勝手にデプロイしたくない
- テストはない
Jenkins
- 単体ではできることが少なく、プラグインがけっこう必要
- Groovyの保守が大変
今日からはじめるCI/CD…のためのAWSアーキテクチャ事始め (その後のアップデート)
パイプライン
| 開発環境 | ソースコード | ビルド&テスト | デプロイ | プロダクション |
|---|---|---|---|---|
| CodeCommit | CodeBuild | CodeDeploy | EC2/ECS/S3/Fargate/Lambda/etc |
自分たちのパイプラインを論理的に説明できる必要がある！
最初にパイプラインの両端を検討
CI/CDデザインマップ
エンジニアの快適さ（開発環境）とサービスの快適さ（プロダクション環境）が優先
ビルドとテストは前後するはずなので、レイヤーとしては統合しとく
至高の CI/CD パイプラインを実現する5つの約束
前半
@ポジティブな Toriさん
最高のパイプラインを手に入れるためのマインドセットとは？
- パイプラインファースト
- 自動化されたパイプラインの維持
- 柔軟なパイプラインの維持
- パイプラインUXの継続的改善
- パイプラインが唯一のリリース手段
最高のパイプラインを手に入れるためのマインドセットとは？
— ごましお (@halnique) May 29, 2019
1. パイプラインファースト
2. 自動化されたパイプラインの維持
3. 柔軟なパイプラインの維持
4. パイプラインUXの継続的改善
5. パイプラインが唯一のリリース手段
耳が痛い！
#xtecharchjaws01
1. パイプラインファースト
- アプリケーション開発から始める
- CI/CDが後回しになる
- だんだんデプロイが遅くなる
最初にパイプラインを作る 圧倒的な低リスク投資！
ちゃんとしとく必要はない お手製のスクリプトでも良い
知見がない場合は、まず手動オペレーションをなるべくスクリプト化するのを大事に
2. 自動化されたパイプラインの維持
ビジネス要求に応じたアプリケーションの変化
- 自動化が難しくなる変更を避ける
- ビジネス要求への対応方法がそれしかないか何回も考える
- 他の実装方法がないか何回も何回も考える
大事なこと
- パイプラインをシンプルに保つ（アプリケーション都合の複雑性を持ち込まない）
- 一番複雑性を吸収しやすいのはアプリケーション
- 後方互換性を持たない変更はNGというポリシーにする、とか
3. 柔軟なパイプラインの維持
大事なこと
- パイプラインをシンプルに保つ（アプリケーション都合の複雑性を持ち込まない）2回目
- Pipeline as a Code (Git)
- Application / Pipeline / Infrastructure
4. パイプラインUXの継続的改善
パイプラインは開発メンバーへの「サービス」である
良くないこと
- 何が起きてるかわからない
- 時間がすごいかかる（黒魔術化は注意）
- 不安定
5. パイプラインは唯一のリリース手段
こんなことは（なるべく）やらない
- なんかテスト通らない
- なんかビルドできない
- 急ぎだから
後半
@株式会社サイバーエージェント 小西 宏樹さん
なぜパイプラインは神なのか
Context
- Webアプリケーション開発現場
- マイクロサービス
- Serverless
- AWS
- スピード重視
- 密結合
- 運用レベルのばらつき
現場の課題
- 無停止デプロイできない
- デプロイ時間が掛かる
- オペミス
- 手動オペレーションの秘伝のタレ化
- 職人誕生
- ビジネスとの付き合い
学び
- 常にビジネスは変化する（それに対応する）
- どこか妥協するとすぐに大きな負債になる
- 透明性が大事
ビジネス層とのコミュニケーション
- 常に議論する
- 簡単にYESと言わない
- ビジネス層にも見える化
VS: パイプラインとか後でいいから動くものまず見せて！
- 次のアップデートとかも手でやるの？
- バグ修正を緊急でやって、疲れた状態で手動リリースするの？
- 一度やらないと次もやらないでしょ？
- 抜け漏れない？
マインドセットの浸透についての組織論
- 信頼貯金を積み上げて実績を作る（時間がかかる）
- 思いに共感してくれる仲間を見つけて広げる
- 技術力を示す
- 仲間とのコミュニケーションを絶やさず
質疑応答など
Q. CI/CDの必要性から説明しなきゃいけないケースがいまだにあるのが辛い
ベテランのエンジニアの方とかで、手でやればいいじゃん論がいまだに強い
言い続けること・感染させていくこと
Q. 初心者なので入りやすいところを知りたい
CDは後回しで、linterとか静的解析とかをCIして通知するみたいなところから始めるのが良いかもね
テストから入るケースが多いはずだから、CIから始めなきゃだめだよね
パイプラインにはアプリとインフラの赤魔道士みたいな人が必要
Q. プロダクション環境がDockerじゃない場合のCIでの自動テストの環境どうしたらいいか
多少の環境差異があってもランタイムのバージョン等が揃ってれば基本的には大丈夫なので、やった方が良いは良い
インフラに依存が大きいものであれば…難しい
Q. パイプライン中にDockerイメージのビルドを入れると遅い
Dockerのイメージビルドが遅い要因は色々ある
マルチステージビルドを上手に使うとか
