【DevOps】DevOpsハッカソンはハンズオンだった
DevOpsハッカソン
MS主催のDevOpsハッカソンへ参加した。
DevOps Hackathon (English - 通訳あり)
まずはじめに感じたのは、この空間で濃密な２日間はなかなか味わえない環境だと思う
開催していただいた、牛尾さん、Davidさんに感謝します
だいたいのまとめ
ファシリテーターなど
参加人数：30名
急いでる人は、ここと #devopsjp あたりを見ると良いと思います。
- DevOpsプリンスの登場
- DevOpsの文脈を再確認（資料良かった!）
- ノリノリの英語発表
- Azureを使ったデプロイチェーンのデモ（infrastructure as code的なの）
- アイディア発表（わりと英語）
- AzureとVSOのハンズオン（ここ本質的なのではない）
- 日本人率80%ぐらいだが、全体発表の公用語は英語（同時翻訳わかりやすい！）
- Azureを初めて触ってるがために、ほとんどハンズオン状態で終わってしまった
- AzureとVSOを繋げることで、だいたい今やりたいであろう開発フローは実現できそう
サンプルコード
VSO
新Azure Manager
旧Azure Maneger
このまとめ書くのに調べていて気がついたけど
大元の募集要項があった。： blogs.msdn.com
なぜ参加したのか
きっかけはこんなところ
- 最近文脈として、DevOpsに興味があること
- ここ1年ぐらいの業務などではUTだったりTFDに近いことができてきている（TDDではない）
- 社内のシステムは知ってるけど、世の中はあまり知らない（井の中の蛙）
- 面白いイベントあるよと唆された
参加して得たいもの
- 世の中の文脈としてDevOpsがどんな認知なのだろうか
- 自分が思うDevOpsと何が違うのか
- そもそも、DevOpsハッカソンとか、よくわからないモノをどうやるのか
- 知識のインプットだけではなくアウトプットしきたい
だいたい、この辺が参加したきっかけと興味関心
能力的にはWebのバックエンドAPI作っているゆるふわエンジニアだったりします
全体のながれ
day1
- DevOpsの説明
- VSO & Azureでのデプロイチェーン全般の紹介
- アイディア出し&チームビルディング
- ハッカソン開始（ほぼAzure & VSOと戯れる）
day2
- アイスブレイク
- タスクボード作ってみる（状況共有ツールの紹介 この辺がDevOps的なところ）
- ハッカソン後半戦
- 発表
ハッカソン自体は、12時〜18時 + 9時〜15時なので、だいたい12時間ぐらいのもの
DevOpsとは何か
個人の理解として、DevOpsはツールと文化のコラボレーションだ
カンバンや、CIツールや、Deployチェーンがあることは大切なことだが
それがあるだけでは意味がない
これらを活用するチームメンバーである企画・開発・運用などが、
ユーザーにより良いものを届けたいという共通のVisionを持ち、
互いを尊重しながら推し進める事も重要な要素となる
互いを理解せずに進めていては、遠回りをしてしまいうまくいかないのだ
（セクショナリズムをなくし、コラボレーションを大切にする）
今回参加してみて感じた事は何か
とにかく２日間AzureとVSOと戯れ続けて終わってしまった。。。
チームの皆さんには何も力になれてない気がして申し訳なかったです
成果物自体も、ハッカソン自体のものとしてはなく
初めて触ったwindowsサーバーとAzureとVSOについて、理解が深まったのと
このハッカソンが記念すべき第一回目だからこそ経験できる
産みの苦しみを感じられました
また、コミュニケーションの難しさを改めて感じた
特に分野の違う人々が集まり、DevOpsという同じ土俵で話をしても
その堅牢さなどは変わってくると感じた
ここの認識を揃えることに注力できなかったかもなと思う
そのほか振り返ってみると
よかった事
- Azure / VSOと普段触れない世界に触れられた事
これは一つ触ってみたいと思っていたので良かった - 様々な人のDevOpsの考えを聞けた事
- それらの人の中で広めようと思っている方は、みんな同様に産みの苦しみを感じてる事を体感できた
- 座学ではなく手を動かし実践できたこと
個人的には癖はあるのだろうと思うが、AzureとVSOがコラボすることで
タスク管理や実装コードの管理、またCI/CDという流れ全般が活用できるのはすごい良かった
これもっと事前に慣れていれば、色々できたのかもしれない
（とはいえ、ゆるふわエンジニアなので出来ないと思う）
それと、最近知識ばかりでちゃんと手を動かしてないなと思っている自分にはとても良い機会でした
実際知識としてDevOpsを知っていても体験してみないと
初期構築の難しさやCIするための苦労などって分からないと思う
できる人には当たり前でも、やっていない人には遥か彼方の地平線のようなものは沢山あるってこと
悪かった事
特に失敗したなと思ったのは、
最初の時点でチームの能力の把握とミニマムなトライを定義しなかったこと
これって難しいんだけど、おそらく初めて会う人同士でチームビルディングなら
絶対に必須の事なのだと思う。
そうすることで、皆の得意分野がみえて、アウトプットが出しやすくなる
エンジニアって不幸なことに、結構一度やったことをやらないし（そうでもないのか？）
人は初めてのものに触れるとき、悩んでしまって動かないもの
そうすると、チームとして誰も触ったことがなくても
その中に知識がありそうな人にすがり動かなくなるのだと思う
なんとなく、誰かがやってくれそうという思いのデットロックがかかるのだろうか
次回参加するならどうする
１つ目 良かったことはさらに伸ばしたい
普段とは違うツールに触れ考え動かしてみるという機会を作るのは中々難しい
例えば、jenkinsを普段使っていてVSO使ったらどうなるのかなんてのは、
やってみないとわからないしどちらが良いかの比較もできない
こういう機会は今後も作っていきたいし
また、DevOpsというプラクティスは範囲が広く全てを短い期間で感じることができる
環境は本当に少ないと思っている（もしこれが普段から体験できてるなら、すごい恵まれた環境だ）
そういうのと戯れられるというのも良いinputになると思う
2つ目 悪かったことは直したい
ツールにこだわってしまったり、壮大な夢を見てしまったり
あまりDevOps的な展開を行うことができなかったなと思う
例えば、誰か環境整備が得意な人がセットアップツールを作り展開するとか
早めにデプロイチェーンを動かして、失敗を早い段階で検知する環境を作っておくとか
ミニマムに動く状態を整備するとか
デプロイ自体をテスト駆動的に作る（始めは動かないデプロイチェーンを作るが、徐々に動いていくみたいな）
なんか、こうもっと開発初期からデプロイまでの流れ全体を最適化するような方法を考えられればよかったなと
特に、機械系や医療系やフリーやwebなど様々な分野の人が集まれば考え方も違うわけだし
その辺のバランスを取れれば良かったのだろう
また、運営の皆さまへ
ある程度事前にサンプルコードや流れを告知しておいていただけると助かりました
（してあったけど、くみ取れてなかったです）
せっかくAzureあるので、とりあえずVM作ればOKみたいな環境あると
とっつきやすいのかもと思っています
どうぞよろしくお願いします
最後に
セミナーなんかも一種のプロダクトなので、昨日今日のデプロイ結果を計測して
次回サービスに反映されることを期待してます
また、DevOps、CI/CD、ユニットテストこの辺の文脈に興味がある人
触れてみたい人は是非参加してみるといいと思います!
２日間で質の良いInputが得られると思います
