Tech Night @ Shiodome 4
https://techsio.connpass.com/event/59789/
あたりまえのことをあたりまえにやる難しさ @voluntas
https://gist.github.com/voluntas/08671d717290a6f63cddd95052a33a86
- 文化の明文化の重要性
- 変化を受け入れられる文化を作ることが非常に重要
- 各組織によって自動化の手法は違うから他組織の事例は参考にならない。 自身で作るしかない。
- レビューはモラル
- 結局個人のモラルが重要になってくる。
- レビュー時によくわからない箇所を指摘して、その反応を見ること。 指摘箇所が分からないとか問題外。
- READMEとCHANGESをきちんと書くことで更新差分が分かるようになる
LT: AWS ECS （EC2 Container Service）を用いた AWS へのDocker コンテナデプロイ @legoboku
https://www.slideshare.net/legoboku/aws-ecsdocker
自動化におけるコード管理 高橋さん
各メンバの役割を決めて、ルールに則っているかどうかという観点でレビューを実施した。
新人が先輩をレビューする。
LT: 送信メールサービスをユニットテストしてみた @zinrai
LT: DevOpsとドキュメントデザインパターン @yuzutas0
https://speakerdeck.com/yuzutas0/20170703
DevOps、本当のところ - ファーストリテイリング @shot6
- @voluntas さんの話とかなりかぶっていたため、直前で資料を修正した、とのこと
- 100%内製は非現実的。 内製化によって効果が高いものを選定する。
- オンプレミスをやめて100%クラウド化
- DevOpsという言葉自体が怪しい
- https://ja.wikipedia.org/wiki/DevOps
- 開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する開発手法をさす。[1]ソフトウェアのビルド、テスト、そしてリリースの文化と環境を以前よりも迅速に、頻繁に、確実に発生する確立を目指している。
- ↑ 分かる
- また、DevOpsにビジネス部門を追加したBizDevOpsというワードも広がりつつある。ただし2013年現時点では厳密な定義は存在しておらず、抽象的な概念に留まっている。
- ↑ 怪しい
- 大きな粒度での自動化は難易度が高い。 エンジニアにあてた成果を上げるのではなく、大きな単位での成果を上げるには厳しい。
- DevOpsの文化を根付けるのが非常にきつい
- 理想のゴールを設けるより、具体性のある変化、実施を優先する
- 自動化そのものはゴールであって、組織体制、チームの分担などの変化が大事。
- 評価制度をきちんと設けないとDevOpsが進まない
- チーム組成･技術ﾏﾈｼﾞﾒﾝﾄを含めて費用対効果を考えること