IIJ Technical WEEK 2014 1日目 #iij_tw2014
- IIJ_doumae
- 4906
- 0
- 2
- 53
バージョン管理システムをgitに変更。SVNのマージコストが高い問題を解決。多数のブランチを上手に扱うことができる。競合する編集があった場合に、編集の順序を調整してうまく収めることができる。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:01:56GitHub. com Gitを使ったソースコード共有サービス。gitの操作のほとんどがWebUIで利用可能。IIJでもオープンソースにしているコードを置いたりしている。しかしあくまで公開サービスである。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:03:06branch と tag を path で代用したのが Subversion 最大の設計ミスだったと思う #iij_tw2014
2014-11-26 16:03:55あくまで公開サービスなので、社内の認証と連携できない。IIJ専用のGitHubを作るために、GitHub Enterpriseを導入した。VMwareのVMとして提供される。社内の認証(AD)と連携できる。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:04:04GitHubのよいところ。従来マージは特定の担当者が手元のコンピュータで独りで作業していた。GitHubではWebUI上で作業。「マージの依頼」「マージのレビュー」を分けることができる。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:05:46GitHubでマージの要求(pull-request)を提出すると、それがマージ可能かを自動的に判定してくれる。マージできない場合は要求を出した人に通知できる。WebUI上でreqに対する議論を展開できる。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:07:17「コードの近くで議論する」ということで、指摘が明確になる。このような書き方がある、というやりとりを行うことで、ノウハウの共有にもつながる。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:07:51SVNからGit(GitHub)への変更によるメリット。複数ブランチを使った並行開発が可能になった。pull-requestを使うことで、コードレビューが都度に実施できるようになった。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:08:46テストの話。継続適インテグレーション(CI…Continuous Integration)。ソースコード変更の度にbuild・単体テストを実施。「いつの間にか動かなくなっていた」を防ぐことができる。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:09:53様々なプラットフォームで動くプログラムの場合、それぞれのテストを手動で実施するのは困難→自動化。 定期的なテストでは、テストの間に行った複数の変更から原因を特定するのが困難→コードを変更する度にテストする。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:11:01GitHub .comと連携するCIサービスがいくつもある。Travis-CI、CircleCI、drone.ioなど。開発者はgithubの画面だけを見ていればよく、ユーザビリティが高い。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:12:05IIJでは社内に設置したGitHub Enterpriseを使っている。社内のGitHubとインターネット上のCIサービスを連携させることは困難。(CIサービスがGHEに対応していない) #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:13:04IIJでは汎用のCIツールとしてJenkinsを使用している。汎用品のため、GitHub Enterpriseとの連携は不十分。自作を考えていたところ、OSS版のdroneが公開された。GHEにも対応。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:14:08早速社内にOSS版droneを構築。リンク切れなど怪しい部分も幾つかあったが、必要な機能は動作していた。GitHub Enterprise上でビルド結果を確認できる。公開から2週間で社内で利用開始することに。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:15:46CI導入による変化。特定のブランチではなく、すべてのpull-requestについてテストが行えるようになった。「マージしても大丈夫か?」の判断を一部自動化できる。レビュー実施コストの低減。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:16:56継続的デプロイメント。デプロイ…サービスを提供するサーバにソフトウェアを適用すること。単にソフトウェアをインストールするのではなく、「正しく動いていること」を確認するまでがデプロイ。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:18:17サービスを提供するサーバは冗長化などで多数存在する。そのすべてを対象にする必要がある。手作業では非常に手間がかかる→回数を減らしたい→自動化のモチベーションが下がる→手間が減らない。という悪循環。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:19:29悪循環を断ち切るために、自動化を進める。自動化を進めやすいようにシステム構成を変更する。コマンド数回でデプロイができるようにする。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:21:17「いつの間にか動作が代わっていた」を防ぐために、特定ブランチが更新される度に開発用サーバに自動的にデプロイされるような仕組みを作った。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:21:43デプロイ・確認の自動化により手間を削減。コード変更の度にデプロイすることで、デプロイとGitHubで管理されるソースコードの変更を関連づけて集中管理できるようになった。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:22:42タスク管理。従来はTracとMS Projectで管理。「実施すること」の管理について最適化されている。アジャイル的な開発では。開発サイクル毎に「何を実施するか」が状況に応じて変化する。これには向かない。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:24:17PivotalTracker なのか…ストーリー使う奴、使いこなしが難しいとアジャイルサムライに出てた記憶 #iij_tw2014
2014-11-26 16:25:40Pivotal Trackerを導入。UIは3カラム。CURRENT(現在実施している項目)・BACKLOG(実施予定の項目)・INBOX(実施時期が未定の項目) CURRENTには実施可能な項目だけが入る。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:25:55ドラッグ&ドロップで項目を相互に入れ替え可能。タスクの消化傾向を可視化することも可能。デットラインに間に合うかどうか、など。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 16:27:21