IIJ Technical WEEK 2014 1日目 #iij_tw2014

堂前@IIJ @IIJ_doumae

バージョン管理システムをgitに変更。SVNのマージコストが高い問題を解決。多数のブランチを上手に扱うことができる。競合する編集があった場合に、編集の順序を調整してうまく収めることができる。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

GitHub. com Gitを使ったソースコード共有サービス。gitの操作のほとんどがWebUIで利用可能。IIJでもオープンソースにしているコードを置いたりしている。しかしあくまで公開サービスである。 #iij_tw2014 bit.ly/iij_tw2014

眼力 玉壱號 @objectxplosive

branch と tag を path で代用したのが Subversion 最大の設計ミスだったと思う #iij_tw2014

堂前@IIJ @IIJ_doumae

あくまで公開サービスなので、社内の認証と連携できない。IIJ専用のGitHubを作るために、GitHub Enterpriseを導入した。VMwareのVMとして提供される。社内の認証(AD)と連携できる。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

GitHubのよいところ。従来マージは特定の担当者が手元のコンピュータで独りで作業していた。GitHubではWebUI上で作業。「マージの依頼」「マージのレビュー」を分けることができる。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

GitHubでマージの要求(pull-request)を提出すると、それがマージ可能かを自動的に判定してくれる。マージできない場合は要求を出した人に通知できる。WebUI上でreqに対する議論を展開できる。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

「コードの近くで議論する」ということで、指摘が明確になる。このような書き方がある、というやりとりを行うことで、ノウハウの共有にもつながる。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

SVNからGit(GitHub)への変更によるメリット。複数ブランチを使った並行開発が可能になった。pull-requestを使うことで、コードレビューが都度に実施できるようになった。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

テストの話。継続適インテグレーション(CI…Continuous Integration)。ソースコード変更の度にbuild・単体テストを実施。「いつの間にか動かなくなっていた」を防ぐことができる。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

様々なプラットフォームで動くプログラムの場合、それぞれのテストを手動で実施するのは困難→自動化。 定期的なテストでは、テストの間に行った複数の変更から原因を特定するのが困難→コードを変更する度にテストする。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

GitHub .comと連携するCIサービスがいくつもある。Travis-CI、CircleCI、drone.ioなど。開発者はgithubの画面だけを見ていればよく、ユーザビリティが高い。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

IIJでは社内に設置したGitHub Enterpriseを使っている。社内のGitHubとインターネット上のCIサービスを連携させることは困難。(CIサービスがGHEに対応していない) #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

IIJでは汎用のCIツールとしてJenkinsを使用している。汎用品のため、GitHub Enterpriseとの連携は不十分。自作を考えていたところ、OSS版のdroneが公開された。GHEにも対応。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

早速社内にOSS版droneを構築。リンク切れなど怪しい部分も幾つかあったが、必要な機能は動作していた。GitHub Enterprise上でビルド結果を確認できる。公開から2週間で社内で利用開始することに。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

CI導入による変化。特定のブランチではなく、すべてのpull-requestについてテストが行えるようになった。「マージしても大丈夫か？」の判断を一部自動化できる。レビュー実施コストの低減。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

継続的デプロイメント。デプロイ…サービスを提供するサーバにソフトウェアを適用すること。単にソフトウェアをインストールするのではなく、「正しく動いていること」を確認するまでがデプロイ。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

サービスを提供するサーバは冗長化などで多数存在する。そのすべてを対象にする必要がある。手作業では非常に手間がかかる→回数を減らしたい→自動化のモチベーションが下がる→手間が減らない。という悪循環。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

悪循環を断ち切るために、自動化を進める。自動化を進めやすいようにシステム構成を変更する。コマンド数回でデプロイができるようにする。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

「いつの間にか動作が代わっていた」を防ぐために、特定ブランチが更新される度に開発用サーバに自動的にデプロイされるような仕組みを作った。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

デプロイ・確認の自動化により手間を削減。コード変更の度にデプロイすることで、デプロイとGitHubで管理されるソースコードの変更を関連づけて集中管理できるようになった。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

タスク管理。従来はTracとMS Projectで管理。「実施すること」の管理について最適化されている。アジャイル的な開発では。開発サイクル毎に「何を実施するか」が状況に応じて変化する。これには向かない。 #iij_tw2014 bit.ly/iij_tw2014

眼力 玉壱號 @objectxplosive

PivotalTracker なのか…ストーリー使う奴、使いこなしが難しいとアジャイルサムライに出てた記憶 #iij_tw2014

堂前@IIJ @IIJ_doumae

Pivotal Trackerを導入。UIは3カラム。CURRENT(現在実施している項目)・BACKLOG(実施予定の項目)・INBOX(実施時期が未定の項目) CURRENTには実施可能な項目だけが入る。 #iij_tw2014 bit.ly/iij_tw2014

Tetsuya Morimoto @t2y

pivotaltracker.com これは知らなかった、あとで触ってみよう #iij_tw2014

堂前@IIJ @IIJ_doumae

ドラッグ＆ドロップで項目を相互に入れ替え可能。タスクの消化傾向を可視化することも可能。デットラインに間に合うかどうか、など。 #iij_tw2014 bit.ly/iij_tw2014