Jenkins ユーザ・カンファレンス東京2018
Jenkinsユーザ・カンファレンス東京2018に参加してきたので、そのメモ書き。
バッテリーが充電できなかったので、基調講演しかメモできなかったです。。
基調講演
- jenkinsがどういうことをやろうとしているのかについて
- pipeline
- jenkinsのコアから変えようとしていて、pipelineの仕組みを変えようとしている
- もう一つはblue oceanという機能
- フロントとサーバーサイドを分離して、モダンなUXを提供するための機能
- 次はJenkinsに取り込みたいと考えている
- Evergreen
- プラグインを組み合わせるのではなく、最初からパッケージされているようなもの
- 簡単にCI/CDを始められるようにすることを目指している
- Evergreenでは自動的にアップグレードされるようにしたい
- configuration as a code
- 設定をyamlファイルにすべて記述できるようにすれば、Jenkinsのバージョン管理、配布ができるようになる。
- Clout Native jenkins
- 最初は低スペックなマシンでJenkinsを立ち上げてもあとからクラウドにスケールアウトするようにする
- Jenkins X
- k8sで最初からクラウドネイティブにする
- Jenkinsはいろいろな機能が追加されているので、今までと同じ使い方をするのではなく、新しいJenkinsの使い方をしていってほしい
Accelerate with Jenkins X
- Jenkins Xは開発者がすばやくクラウドに移動できることを目指している
- k8sを拡張している
- k8sを始めるは簡単ではないが、Jenkins Xを使えば簡単に移行できる
- Accelerateという本がある
- 数年のdevopsについて書かれている
- 開発者のコードがリリースされるまでどれくらいかかるのか
- MTBF
- デプロイにどれくらいの割合で失敗するのか
- jenkisn Xではこの本で記載されているプラクティスを実践している
- すべての変更をGitで管理する
- 自動でデプロイしてくれる
- プレビュー環境も提供してくれる
- マイクロサービスを開発するのが楽になる
- 最初からステージング環境と本番環境がある
- なぜk8sなのか
- 様々プラットフォームをサポートしている提供されている
- 開発者に何が嬉しいのか
- クラウドサービスのポータビリティが高い
- コミュニティが活発
- しかし、k8sを使うのは簡単ではない
- チームの開発プロセスを決めなければいけない
- Jenkins X は高いレベルの自動化を提供する
感想
Jenkins Xに関してはデモが見れてかなり使いやすそうな印象を受けました。
もっとJenkinsに触れなければ！という危機感もちょっと受けました。。。
業務がWebドメインではないので、クラウドとかは少し使うのが難しいので、Jenkinsのこれからの進化と自分の使い方にマッチするのはどういう機能なのかを見極めて行きたいなぁと思いました。
そういう意味では、個人的には最初からオールインワンで入っているようなEvergreenは期待したい。
2セッション目で紹介されていた本は↓これだろうか？
Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
posted with amazlet at 18.09.23
IT Revolution Press (2018-03-27)
もう上の本を勢いだけでポチってしまったが、和訳本は↓これだろうか？
LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する (impress top gear)
posted with amazlet at 18.09.23
XP祭り 2018
随時更新記事
とりあえずメモベースで公開
【基調講演】テスト駆動開発の過去・現在・未来（和田卓人さん）
- 本の付録Cについて
- ケント・ベックの本が絶版になった
- １５年前の本を訳し治すだけではなく、まとめとして付録をつけた
- 付録Cが扱っているのは２００２年から２０１４年
- ４冊の本と一人の人物
- TDD生誕前
- 大きくは４人が関わっている
- パターンコミュニティが関わっている
- コンパイラの開発者がテストコードを書いていた
- TDD2章はjunitの作り方とほぼ同じ
- オブジェクト指向へのカンファレンスへの飛行機の上でペアプログラミングをした
- Kent BeckはJavaが知りたかった。Erich Gammaはテストが知りたかった
- テスト駆動開発はテストファーストにインクリメントな要素を入れたものと定義している
- C2 wikiには当時の議論が全て残っている
- TDDの誕生から現在まで
- 2007年までに事例の本がいっぱい出てきた
- その間の本は用語が統一されていなかった。用語も統一されていなかった。
- そのときにxUnit Test PATTERNSという本が出た
- この本はネットで公開されている。
- ↑この本を書いた人がなぜこの本を出せたのかを調べたらパターンマニアだった
- Mockにも広義のmockと狭義のmockがある
- 理想は学習コストが高いが、学習したあとは開発が楽になると思っていたが、現実はそうなっていない。
- この本では、もうそのことに言及していて、どうリファクタリングしていくかが記載されている
- その後、Growing Object-Oriented Software, Guided By Tests(実践テスト駆動開発)が出る
- ロンドンにXPを話し合うコミュニティがあった
- テスト駆動開発に流派が大きく２つあった（ケント・ベックが書いた本をベースにした古典派と、mockを使ったロンドンの流派）
- 今で言う広義のmockオブジェクトが生まれた
- mockオブジェクトは依存関係を排除することで、開発の順番も変えられる事に気がついた
- その結果、お客さんに近い部分（画面）から作成できるようになった
- TDDのTについて考える
- マイヤーズのテストの定義とTDDのTの定義がずれていた
- TDDのTはテストお一部に過ぎない
- 2002年にtesting Extreme Programing という本が出ていた（日本では未翻訳）
- アジャイルの中でテストエンジニアが何ができるかが書かれている
- ４象限のモデルを2003年にもう定義している
- TDDはテストではなく、チェックキングだということを早くから言っている
- テストエンジニアは自動化できないマニュアルテスト（探索的テストなど）を高めようと言っている
- アジャイルにおけるテストとはテストフェーズではなく、日々の行いである
- TDDからBDDへ
- 2003年、テストコードからドキュメントを作成するようになる
- 仕様を示すメソッド名をつけるとドキュメントとして残る様になった。それがBDDへになった。
- testではなく、shouldを使うようになった
- BDDはコードだから、お客と円滑に会話できないという議論が出てきた
- BDDは２つの流派に別れた。今までのBDDとcucumberのように仕様記述のBDDに別れた
- そして現在
- 2014年何が起こったか
- 教条主義化が起きた。テスト駆動開発の義務化、高圧化が起きた。
- 最初のテスト駆動開発の本もTDDの強要ほど、TDDのの普及を妨げるものはない、と記載されている
- David Heinemeier Hansson氏によって、TDD is dead. Long live testingという記事が書かれた
- 意味の希薄化
- 応用情報技術者試験でTDDの問題が出たが、意味があっていない
- テストファーストとテスト駆動開発の違いがわからなくなっている
- mockライブラリが強力になった結果、設計改善効果はなくなってきている
- mockが書きにくいときは、設計が悪いという判断基準になっていたのに今は無理やりテストを通る様になっている
- コードを書く段階になったらTDDとBDDに違いはない。RSpecは厳密にいうとテストツールではない。
- 未来について
- 意味が希薄化され、ツールだけが残っている
- テストは品質を挙げない
QA to AQ – Being Agile at Quality: Values, Practices, and Patterns（Joseph Yoderさん、鷲崎さん）
(英語ベースのセッションだったので、私の理解で書いています。)
- アジャイルでは、開発者、QA、プロダクトオーナーなどの人の壁を取って一つのチームとしてして扱う
- そこで、QAはチームに加わりQA的な観点でvalueを考える必要がある
- 今回行ったのは、アジャイル開発における品質シナリオを作成するワークショップ
- QAもアジャイルにチームに参加したときに、品質を作り込むための品質シナリオをバックログに入れ込む（非機能などをどう担保し、どう計測するかを考える）
- 品質シナリオは用意されたアーキテクチャに沿って品質シナリオを作成する。
- stimulus,artiface,enviroment,response,response measure
- 上げた非機能を担保するバックログは、非機能はプロジェクトのフェーズにより決める段階が異なるため、優先順位付けをする
- 作り込んだ品質シナリオを実現するようにアーキテクチャの変更を検討する。
『フレーズ』で体験する、あのチーム（とちぎRubyの勉強会（toRuby））
ワークショップというより、”あのチーム”で普段使用しているフレーズを紹介して、参加者が自分の現場と比較してどう思うか、と言うようなことを議論する形式だった。
torubyには未参加だけれど、”あのチーム”の話はよく聞くので、興味があって参加してみた。
感想としては、チームの心理的安全が確保されているからあれらのワードが躊躇なく使えるんだろうなぁということを感じた。
チーム全員が製品のことを考えていて、チームメンバが全体最適を考えていることが素晴らしいなぁと思った。
その環境を作るのはそういう環境にした優れたリーダーや、アジャイルのプラクティスで共通の目標を持つように出来たから、今の環境があるのかなぁと思ったがどうなんだろうか？
"あのチーム"の今より、どうやって今のチームを作成したのかを今後聞いてみたいと思った。
（資料が公開されたらもう少し書く予定）
