Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
バイオインフォマティクスの
ための開発基礎知識
国立がんセンター研究所
宮本 丈
ソフトウェア開発の進歩
ウォーター
フォール
アジャイル DevOps
どれも一長一短だが、バイオインフォマティクスの場合、
ウォーターフォール型の場面は少ない
進歩というより進化?
ウォーター
フォール
アジャイル DevOps
現代ではウォーターフォール型は使われない
というわけではない
ソフトウェア開発手法の比較
スパイラル
モデル
非スパイラ
ルモデル
スクラム
エクストリーム
プログラミング
(XP)
ウォーター
フォール
アジャイル DevOps
ウォーターフォール型開発
• ソフトウェア工学では非常に古くからある、もっともポピュラーな開発モデル。
原則として一度工程が完了したら前行程には戻らない
何を作りたいのか、正確に把握した上で始めなくてはならない
大規模開発に向く
「一流のアーキ...
ウォーターフォール型開発
メリット
•作業工程が管理しやすい
デメリット
•不測の事態に弱い(変更が利かない)
ウォーターフォール(スパイラル型)
• ウォーターフォールを何度も繰り返す
メリット
• 1周するたびに課題がはっきりする
デメリット
• 手間
• 「1週目だから手抜きでもいい」というメンタリティ
出典:http://iwatam-serve...
ウォーター
フォール
アジャイル DevOps
アジャイル
• ウォーターフォールに対するアンチテーゼとして生まれた
• 手法というより哲学
• 1~4週間を1サイクルとし、1つずつ機能を追加していく
出典:http://www.nec-nis.co.jp/ja/column/images/...
アジャイル
メリット
• 変更に強い
• 問題の可視化
デメリット
• 継続的にリファクタリングをする必要性 ->CI
• コミュニケーションコスト->20人以上だと難しい
スパイラルとアジャイルとの違い
• スパイラルは1回の反復ごとに
すべての機能を作る
• アジャイルは1回につき一機能
を作る
アジャイルの実装の一つ
チーム内コミュニケーションを密にすることに主眼
• 製品に入れたい機能、改善点をリスト化。優先度を付け定期
的に見直す
• 30日間のサイクルを繰り返す。終了時にソフトウェアは動作可
能でなければならない
• 毎日15分...
エクストリームプログラミング(XP)
アジャイルの実装の一つ
保守性の高いコードを作成することに主眼
• テスト駆動開発(TDD)
• ペアプログラミング
• ソースコードの共有所有
• 継続的インテグレーション(CI)
• 課題管理
エクストリームプログラミング(XP)
アジャイルの実装の一つ
保守性の高いコードを作成することに主眼
• テスト駆動開発(TDD)
• ペアプログラミング
• ソースコードの共有所有
• 継続的インテグレーション(CI)
• 課題管理
2種類のテスト
ユーザーのためのテスト
アジャイルではこちらに主眼
一か所でも変更したら
すべてをテストすることで
バグの波及を防ぐ
開発者のためのテスト
エクストリームプログラミング(XP)
アジャイルの実装の一つ
保守性の高いコードを作成することに主眼
• テスト駆動開発(TDD)
• ペアプログラミング
• ソースコードの共有所有
• 継続的インテグレーション(CI)
• 課題管理
• 分散型のバージョン管理ツール
• 変更履歴を共有
• 作業ごとにブランチを切ることで
行うべきタスクを分離する
出典:http://www.atmarkit.co.jp/ait/articles/0901/14/news133.html
Gitを用いたワークフロー (≒ how to branch)
ブランチの切り方はいろいろある
が、以下が基本
• 1 機能1ブランチ
• Masterは常にデプロイ可能
出典:https://www.atlassian.com/ja/git/...
• Gitのホスティングサービス
• 課題ごとにIssueを立てることで、
作業の経緯が明確に
Coding -> Pull Request -> Review -> merge
という流れを踏むことで、コードの統一性が保障される
Git&github でのworkflow
ローカル
での作業
push
Pull
Request
Code
Review
merge
Fork&
clone
出典:http://acrl.ala.org/techconnect/post/co...
Git&github でのworkflow ローカル
での作業
push
Pull
Request
Code
Review
merge
Fork&
clone
出典:http://acrl.ala.org/techconnect/post/co...
エクストリームプログラミング(XP)
アジャイルの実装の一つ
保守性の高いコードを作成することに主眼
• テスト駆動開発(TDD)
• ペアプログラミング
• ソースコードの共有所有
• 継続的インテグレーション(CI)
• 課題管理
継続的インテグレーション(CI)
自動化されたテスト
を頻繁に行う
問題の可視化が容易に
出典:http://www.techmatrix.co.jp/quality/ctest/pickup/ci_and_parasofttools/ci_a...
Gitとの連携
remoteにpushするたびに自動でテストする
Github + [travisCI or jenkins]
という組み合わせが多い
出典:http://www.casleyconsulting.co.jp/blog-engi...
エクストリームプログラミング(XP)
アジャイルの実装の一つ
保守性の高いコードを作成することに主眼
• テスト駆動開発(TDD)
• ペアプログラミング
• ソースコードの共有所有
• 継続的インテグレーション(CI)
• 課題管理
課題管理のプラクティス
• 大まかな流れは
ガントチャート、バーンダウンチャートで
出典:http://www.speed-star1.com/freeware/ganttchart.html
出典:http://anastasia.dip.j...
チケット駆動開発
• タスクをチケットとして一元管理
• プロジェクトスタート時には予測
できなかった細かい作業の管
理が容易に
出典:http://itpro.nikkeibp.co.jp/article/COLUMN/20130927/50...
ウォーター
フォール
アジャイル DevOps
DevOps
• 「アジャイルを運用まで拡大する」
という思想
つまり
• 変更を実稼働するシステムに即座
に反映させる
ソフトウェア単位ではなく
全てのシステムを
開発対象としてとらえる
Devopsのためのツール
• コンテナ型仮想化
•構成管理ツール
http://blog.xebialabs.com/2014/12/05/rocket-vs-docker-myth-simple-lightweight-enterprise...
Devopsのためのツール
•コンテナ型仮想化
• 構成管理ツール
http://blog.xebialabs.com/2014/12/05/rocket-vs-docker-myth-simple-lightweight-enterprise...
よくある状況
•
手元のパソコンで解析
コンピューティング資源
が足りない
パイプラインを別のところ
に移植したい
クラウド使える?
CloudBiolinux あるいはbioimg.org
の仮想マシンイメージを使用する
_人人人人人人人人人...
コンテナ型仮想化(docker)
• サードパーティ製のツールや
モジュールもすべて含めてイ
メージとして管理する
• Dockerが動く環境ならどこで
も確実に動く
(Build Once Run Anywhere)
• Gitライクな管理が...
従来の技術
chroot、cgroups KVM、Virtualbox
ファイル、プロセス空間の隔離 OS仮想化
• 重い
• Provisioningが難しい
• 他人の作ったbase imageを
使いまわすのが難しい
• (chrootは...
対抗勢力の出現
• セキュリティ問題
• Dockerfile問題
• 移植性の問題
Cache周りで変な挙動を示す
場合がある
書き方が独特->packerの登場
root権限が必須
結局、dockerが動く環境でないと
動かない
Kerne...
Devopsのためのツール
•コンテナ型仮想化
• 構成管理ツール
http://blog.xebialabs.com/2014/12/05/rocket-vs-docker-myth-simple-lightweight-enterprise...
Infrastructure as code
• サーバーの設定をコードとして管
理しておく
• サーバーに対して適用すると必
ず同じ状態に収束する(冪等性)
• サーバー間の移行が容易に
Fabric
Rubyベース Pythonベース
Ch...
Upcoming SlideShare
Loading in …5
×

バイオインフォマティクスのための開発基礎知識

社内での発表に用いたものです

  • Login to see the comments

バイオインフォマティクスのための開発基礎知識

  1. 1. バイオインフォマティクスの ための開発基礎知識 国立がんセンター研究所 宮本 丈
  2. 2. ソフトウェア開発の進歩 ウォーター フォール アジャイル DevOps どれも一長一短だが、バイオインフォマティクスの場合、 ウォーターフォール型の場面は少ない
  3. 3. 進歩というより進化? ウォーター フォール アジャイル DevOps 現代ではウォーターフォール型は使われない というわけではない
  4. 4. ソフトウェア開発手法の比較 スパイラル モデル 非スパイラ ルモデル スクラム エクストリーム プログラミング (XP)
  5. 5. ウォーター フォール アジャイル DevOps
  6. 6. ウォーターフォール型開発 • ソフトウェア工学では非常に古くからある、もっともポピュラーな開発モデル。 原則として一度工程が完了したら前行程には戻らない 何を作りたいのか、正確に把握した上で始めなくてはならない 大規模開発に向く 「一流のアーキテクトと大量の二流のプログラマ」 出典:http://www.nec-nis.co.jp/ja/column/images/01_wf_ag.png
  7. 7. ウォーターフォール型開発 メリット •作業工程が管理しやすい デメリット •不測の事態に弱い(変更が利かない)
  8. 8. ウォーターフォール(スパイラル型) • ウォーターフォールを何度も繰り返す メリット • 1周するたびに課題がはっきりする デメリット • 手間 • 「1週目だから手抜きでもいい」というメンタリティ 出典:http://iwatam-server.sakura.ne.jp/software/devintro/devprocess/devprocess/x111.html
  9. 9. ウォーター フォール アジャイル DevOps
  10. 10. アジャイル • ウォーターフォールに対するアンチテーゼとして生まれた • 手法というより哲学 • 1~4週間を1サイクルとし、1つずつ機能を追加していく 出典:http://www.nec-nis.co.jp/ja/column/images/01_wf_ag.png
  11. 11. アジャイル メリット • 変更に強い • 問題の可視化 デメリット • 継続的にリファクタリングをする必要性 ->CI • コミュニケーションコスト->20人以上だと難しい
  12. 12. スパイラルとアジャイルとの違い • スパイラルは1回の反復ごとに すべての機能を作る • アジャイルは1回につき一機能 を作る
  13. 13. アジャイルの実装の一つ チーム内コミュニケーションを密にすることに主眼 • 製品に入れたい機能、改善点をリスト化。優先度を付け定期 的に見直す • 30日間のサイクルを繰り返す。終了時にソフトウェアは動作可 能でなければならない • 毎日15分のミーティングを行い、困っていることや行う予定の ことを確認する • パーティションを廃止し、チームを一部屋に集める スクラム
  14. 14. エクストリームプログラミング(XP) アジャイルの実装の一つ 保守性の高いコードを作成することに主眼 • テスト駆動開発(TDD) • ペアプログラミング • ソースコードの共有所有 • 継続的インテグレーション(CI) • 課題管理
  15. 15. エクストリームプログラミング(XP) アジャイルの実装の一つ 保守性の高いコードを作成することに主眼 • テスト駆動開発(TDD) • ペアプログラミング • ソースコードの共有所有 • 継続的インテグレーション(CI) • 課題管理
  16. 16. 2種類のテスト ユーザーのためのテスト アジャイルではこちらに主眼 一か所でも変更したら すべてをテストすることで バグの波及を防ぐ 開発者のためのテスト
  17. 17. エクストリームプログラミング(XP) アジャイルの実装の一つ 保守性の高いコードを作成することに主眼 • テスト駆動開発(TDD) • ペアプログラミング • ソースコードの共有所有 • 継続的インテグレーション(CI) • 課題管理
  18. 18. • 分散型のバージョン管理ツール • 変更履歴を共有 • 作業ごとにブランチを切ることで 行うべきタスクを分離する 出典:http://www.atmarkit.co.jp/ait/articles/0901/14/news133.html
  19. 19. Gitを用いたワークフロー (≒ how to branch) ブランチの切り方はいろいろある が、以下が基本 • 1 機能1ブランチ • Masterは常にデプロイ可能 出典:https://www.atlassian.com/ja/git/workflows#!workflow-gitflow
  20. 20. • Gitのホスティングサービス • 課題ごとにIssueを立てることで、 作業の経緯が明確に Coding -> Pull Request -> Review -> merge という流れを踏むことで、コードの統一性が保障される
  21. 21. Git&github でのworkflow ローカル での作業 push Pull Request Code Review merge Fork& clone 出典:http://acrl.ala.org/techconnect/post/coding-collaboration-on-github
  22. 22. Git&github でのworkflow ローカル での作業 push Pull Request Code Review merge Fork& clone 出典:http://acrl.ala.org/techconnect/post/coding-collaboration-on-github チケットの発行 ↓ 課題管理 ビルドテスト ↓ CI
  23. 23. エクストリームプログラミング(XP) アジャイルの実装の一つ 保守性の高いコードを作成することに主眼 • テスト駆動開発(TDD) • ペアプログラミング • ソースコードの共有所有 • 継続的インテグレーション(CI) • 課題管理
  24. 24. 継続的インテグレーション(CI) 自動化されたテスト を頻繁に行う 問題の可視化が容易に 出典:http://www.techmatrix.co.jp/quality/ctest/pickup/ci_and_parasofttools/ci_and_parasofttools_2.html CIツール:Jenkins
  25. 25. Gitとの連携 remoteにpushするたびに自動でテストする Github + [travisCI or jenkins] という組み合わせが多い 出典:http://www.casleyconsulting.co.jp/blog-engineer/git/
  26. 26. エクストリームプログラミング(XP) アジャイルの実装の一つ 保守性の高いコードを作成することに主眼 • テスト駆動開発(TDD) • ペアプログラミング • ソースコードの共有所有 • 継続的インテグレーション(CI) • 課題管理
  27. 27. 課題管理のプラクティス • 大まかな流れは ガントチャート、バーンダウンチャートで 出典:http://www.speed-star1.com/freeware/ganttchart.html 出典:http://anastasia.dip.jp/index.php?url=tech_it_ip&contents=kotei • 細かい作業は チケット、issueで Redmine Github + Zenhub ガントチャート バーンダウンチャート
  28. 28. チケット駆動開発 • タスクをチケットとして一元管理 • プロジェクトスタート時には予測 できなかった細かい作業の管 理が容易に 出典:http://itpro.nikkeibp.co.jp/article/COLUMN/20130927/507265/?SS=imgview&FD=55983188&ST=devops を使うことが多い
  29. 29. ウォーター フォール アジャイル DevOps
  30. 30. DevOps • 「アジャイルを運用まで拡大する」 という思想 つまり • 変更を実稼働するシステムに即座 に反映させる ソフトウェア単位ではなく 全てのシステムを 開発対象としてとらえる
  31. 31. Devopsのためのツール • コンテナ型仮想化 •構成管理ツール http://blog.xebialabs.com/2014/12/05/rocket-vs-docker-myth-simple-lightweight-enterprise-platform/ Fabric
  32. 32. Devopsのためのツール •コンテナ型仮想化 • 構成管理ツール http://blog.xebialabs.com/2014/12/05/rocket-vs-docker-myth-simple-lightweight-enterprise-platform/ Fabric
  33. 33. よくある状況 • 手元のパソコンで解析 コンピューティング資源 が足りない パイプラインを別のところ に移植したい クラウド使える? CloudBiolinux あるいはbioimg.org の仮想マシンイメージを使用する _人人人人人人人人人人_ > dependency hell<  ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄ ソフトウェアやパッケージのバージョンが違う _人人人人人人人人人人_ > No Reproducibility<  ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄ Yes No
  34. 34. コンテナ型仮想化(docker) • サードパーティ製のツールや モジュールもすべて含めてイ メージとして管理する • Dockerが動く環境ならどこで も確実に動く (Build Once Run Anywhere) • Gitライクな管理ができる クラウド、サーバー間の移植が容易に 「ソフトウェア開発」をするのと同じように 「コンテナ開発」ができる
  35. 35. 従来の技術 chroot、cgroups KVM、Virtualbox ファイル、プロセス空間の隔離 OS仮想化 • 重い • Provisioningが難しい • 他人の作ったbase imageを 使いまわすのが難しい • (chrootは)1ユーザーのプロセスがすべてを 食い尽くす危険がある いいとこどりを目指したツール
  36. 36. 対抗勢力の出現 • セキュリティ問題 • Dockerfile問題 • 移植性の問題 Cache周りで変な挙動を示す 場合がある 書き方が独特->packerの登場 root権限が必須 結局、dockerが動く環境でないと 動かない Kernel version3.8以上が推奨 Cloudius OSV Dockerの問題点 まだちょっと使いづらい Base imageなどのコミュニティリソースが少ない
  37. 37. Devopsのためのツール •コンテナ型仮想化 • 構成管理ツール http://blog.xebialabs.com/2014/12/05/rocket-vs-docker-myth-simple-lightweight-enterprise-platform/ Fabric
  38. 38. Infrastructure as code • サーバーの設定をコードとして管 理しておく • サーバーに対して適用すると必 ず同じ状態に収束する(冪等性) • サーバー間の移行が容易に Fabric Rubyベース Pythonベース Chef Zero 小 規 模 大 規 模 • Chefは独特の用語を覚えるのが面倒 • CloudBiolinuxがFabricをサポートしている

×