Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie バイオインフォマティクスのための開発基礎知識
Ähnlich wie バイオインフォマティクスのための開発基礎知識 (20)
Mehr von 丈 宮本
バイオインフォマティクスのための開発基礎知識
- 8. ウォーターフォール(スパイラル型) • ウォーターフォールを何度も繰り返す メリット • 1周するたびに課題がはっきりする デメリット • 手間 • 「1週目だから手抜きでもいい」というメンタリティ 出典：http://iwatam-server.sakura.ne.jp/software/devintro/devprocess/devprocess/x111.html
- 10. アジャイル • ウォーターフォールに対するアンチテーゼとして生まれた • 手法というより哲学 • 1~4週間を1サイクルとし、1つずつ機能を追加していく 出典：http://www.nec-nis.co.jp/ja/column/images/01_wf_ag.png
- 11. アジャイル メリット • 変更に強い • 問題の可視化 デメリット • 継続的にリファクタリングをする必要性 ->CI • コミュニケーションコスト->20人以上だと難しい
- 13. アジャイルの実装の一つ チーム内コミュニケーションを密にすることに主眼 • 製品に入れたい機能、改善点をリスト化。優先度を付け定期 的に見直す • 30日間のサイクルを繰り返す。終了時にソフトウェアは動作可 能でなければならない • 毎日15分のミーティングを行い、困っていることや行う予定の ことを確認する • パーティションを廃止し、チームを一部屋に集める スクラム
- 14. エクストリームプログラミング(XP) アジャイルの実装の一つ 保守性の高いコードを作成することに主眼 • テスト駆動開発(TDD) • ペアプログラミング • ソースコードの共有所有 • 継続的インテグレーション(CI) • 課題管理
- 15. エクストリームプログラミング(XP) アジャイルの実装の一つ 保守性の高いコードを作成することに主眼 • テスト駆動開発(TDD) • ペアプログラミング • ソースコードの共有所有 • 継続的インテグレーション(CI) • 課題管理
- 17. エクストリームプログラミング(XP) アジャイルの実装の一つ 保守性の高いコードを作成することに主眼 • テスト駆動開発(TDD) • ペアプログラミング • ソースコードの共有所有 • 継続的インテグレーション(CI) • 課題管理
- 18. • 分散型のバージョン管理ツール • 変更履歴を共有 • 作業ごとにブランチを切ることで 行うべきタスクを分離する 出典：http://www.atmarkit.co.jp/ait/articles/0901/14/news133.html
- 19. Gitを用いたワークフロー (≒ how to branch) ブランチの切り方はいろいろある が、以下が基本 • 1 機能1ブランチ • Masterは常にデプロイ可能 出典：https://www.atlassian.com/ja/git/workflows#!workflow-gitflow
- 20. • Gitのホスティングサービス • 課題ごとにIssueを立てることで、 作業の経緯が明確に Coding -> Pull Request -> Review -> merge という流れを踏むことで、コードの統一性が保障される
- 23. エクストリームプログラミング(XP) アジャイルの実装の一つ 保守性の高いコードを作成することに主眼 • テスト駆動開発(TDD) • ペアプログラミング • ソースコードの共有所有 • 継続的インテグレーション(CI) • 課題管理
- 25. Gitとの連携 remoteにpushするたびに自動でテストする Github + [travisCI or jenkins] という組み合わせが多い 出典：http://www.casleyconsulting.co.jp/blog-engineer/git/
- 26. エクストリームプログラミング(XP) アジャイルの実装の一つ 保守性の高いコードを作成することに主眼 • テスト駆動開発(TDD) • ペアプログラミング • ソースコードの共有所有 • 継続的インテグレーション(CI) • 課題管理
- 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 ガントチャート バーンダウンチャート
- 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. コンテナ型仮想化(docker) • サードパーティ製のツールや モジュールもすべて含めてイ メージとして管理する • Dockerが動く環境ならどこで も確実に動く (Build Once Run Anywhere) • Gitライクな管理ができる クラウド、サーバー間の移植が容易に 「ソフトウェア開発」をするのと同じように 「コンテナ開発」ができる
- 35. 従来の技術 chroot、cgroups KVM、Virtualbox ファイル、プロセス空間の隔離 OS仮想化 • 重い • Provisioningが難しい • 他人の作ったbase imageを 使いまわすのが難しい • (chrootは)1ユーザーのプロセスがすべてを 食い尽くす危険がある いいとこどりを目指したツール
- 36. 対抗勢力の出現 • セキュリティ問題 • Dockerfile問題 • 移植性の問題 Cache周りで変な挙動を示す 場合がある 書き方が独特->packerの登場 root権限が必須 結局、dockerが動く環境でないと 動かない Kernel version3.8以上が推奨 Cloudius OSV Dockerの問題点 まだちょっと使いづらい Base imageなどのコミュニティリソースが少ない
- 38. Infrastructure as code • サーバーの設定をコードとして管 理しておく • サーバーに対して適用すると必 ず同じ状態に収束する(冪等性) • サーバー間の移行が容易に Fabric Rubyベース Pythonベース Chef Zero 小 規 模 大 規 模 • Chefは独特の用語を覚えるのが面倒 • CloudBiolinuxがFabricをサポートしている
Hinweis der Redaktion
- 一度似たようなプロジェクトで失敗しなければ成功しないといわれる。 時間がないと破綻する すべて完成してから問題が発覚するなんてことも…
- 結構厳しいので、メンバーに経験が要求される