開発リードタイム短縮への挑戦 〜とある現場のパターン・ランゲージ〜
•Download as PPTX, PDF•
9 likes•2,848 views
2015年3月10日 @IT主催勉強会 基調講演 https://itmedia.smartseminar.jp/public/seminar/view/687
Recommended
More Related Content
Similar to 開発リードタイム短縮への挑戦 〜とある現場のパターン・ランゲージ〜
Similar to 開発リードタイム短縮への挑戦 〜とある現場のパターン・ランゲージ〜 (20)
開発リードタイム短縮への挑戦 〜とある現場のパターン・ランゲージ〜
- 1. 開発リードタイム短縮への挑戦 ~とある現場のパターン・ランゲージ~ 2015/03/10 山木隆寛 楽天株式会社 楽天市場サービス開発・運用部 http://www.rakuten.co.jp/
- 2. 2 結論を先に！ • モチベーション 1. より早く、より良いものを、リリースしたい！ • 作戦 1. 手作業排除 2. コーダーに対するフィードバックを素早く 1. ビルド結果 2. 静的なコード分析結果 3. 継続的システムテスト結果 4. セキュリティチェック結果 開発リードタイム短縮への挑戦
- 6. 6 利用したパターン for 人 みんなを巻き込む エバンジェリスト 『アジャイルに効く アイデアを組織に広めるための48のパターン』 Mary Lynn Manns, Linda Rising著, 川口 恭伸 監訳 (2014) 正式な推進担当者 イノベーター アーリーアダプター 勉強会やってみる 種をまく個人的な接触 体験談の共有
- 7. 7 利用したパターン for システム Git 化 Step by Step 小さな成功 自動化 リポジトリ連携 脱Excel 外部のお墨付き ちょうど十分
- 8. 8 Git 化 Step by Step 小さな成功 自動化 リポジトリ連携 脱Excel 外部のお墨付き ちょうど十分 キーワード pull-request CI テストケース管理 ブランチ管理 git-flow チケット code ビルド, デプロイ テスト
- 9. 9 Git 化 Step by Step 小さな成功 自動化 リポジトリ連携 脱Excel 外部のお墨付き ちょうど十分 事例のご紹介 CI ココ ココ チケット code ビルド, デプロイ テスト
- 10. 10 アジェンダ • はじめに • 事例のご紹介 – リポジトリ連携 – 自動化 • 将来像 • まとめ
- 12. 12 パターン・リポジトリ連携 • 状況 –開発中におきる“ものこと” 同士を関連づけ るのは、エクセルの備考欄! 個人メモ! • このチケットの案件、コードレビュー終わった？ • このチケットの案件、どの環境にデプロイした？ • 問題 –トレーサビリティを簡単にしたい
- 13. 13 パターン・リポジトリ連携 続き • 制約 –社内のツール推進部署がサービス提供中 • チケット管理、ソースコード管理、ドキュメント管理 • 解決方法 –これらと相性のいいものを選んで、それぞ れのリポジトリのデータを連携させる!
- 14. 14 テストケース テスト結果 リポジトリ連携 結果 (1) チケット Codes 成果物 ライブラリ ドキュメント Code 品質 RMS ビルド結果 デプロイ結果 セキュリティレポート 情報蓄積 制約 (既存ツール)
- 15. 15 チケットとCodesの簡単紐付け Tips 前提 1.git-flow に従って、ブランチ名は feature/xxxx 2.feature 名はチケットID cd .git/hooks mv prepare-commit-msg.sample prepare-commit-msg vi prepare-commit-msg #!/bin/sh # mv $1 $1.tmp echo -n "[`git branch | grep "*" | awk '{print $2}' | sed -e "s/feature///g" `] " > $1 cat $1.tmp >> $1 サンプルコード by T. Sugihara
- 16. 16 リポジトリ連携 From ビルド結果 デプロイ情報 チケット Codes 変更ログ (誰? 何?)
- 17. 17 リポジトリ連携 From テスト結果 チケット テストNG報告 チケット作成 テスト結果 修正チケット
- 19. 19 事例のご紹介(2) 自動化
- 20. 20 パターン・自動化 • 状況 –手作業 多過ぎ • 問題 –手作業に工数を取られる。ミスもある • 制約 –既存ツールとの親和性 • 解決方法 –既存ツールと相性のいいものを選んで 自動化！自動化！自動化！
- 21. 21 自動化 参考資料 (1) 『継続的デリバリー』 David Farley (著), Jez Humble (著), 和智 右桂 (翻 訳), 高木 正弘 (翻訳)
- 22. 22 自動化 参考資料 (2) 『万人のためのオートメーション: デプロイメント の自動化パターン』 Paul Duvall http://www.ibm.com/developerworks/jp/java/library/j-ap01139/ – シングル・クリック – 構成の外部化 – ヘッドレス実行 – スクリプト化デプロイメント – リモート・デプロイメント
- 24. 24 デモ 自動デプロイ・シナリオ アプリケーション 管理サーバ クラスター #1 #2 #3 #4 手動テスト 継続的 システムテスト* (3) (2) (4) * Kotaro Ogino and Francois Picalausa “Continuous System Test”. Test Automation. http://kokotatata.hatenablog.com/entry/2014/03/14/075842 (1) CIツール
- 25. 25 MOVIE 自動デプロイ
- 27. 27 アジェンダ • はじめに • 事例のご紹介 • 将来像 • まとめ
- 28. 28 STG QA DEVBuild 将来像 ･･･ “デプロイメントパイプライン” IT Release Judge Acceptance Test PROD Blue- Green Deploy Clone Build UT Code Analysis Deploy Conf Test Conf Test Deploy ST Conf Test Code Review Metrics Release Judge Security Test ST Security Test
- 29. 29 大切なことなので再掲 • モチベーション 1. より早く、より良いものを、リリースしたい！ • 作戦 1. 手作業排除 2. コーダーに対するフィードバックを素早く 1. ビルド結果 2. 静的なコード分析結果 3. 継続的システムテスト結果 4. セキュリティチェック結果 開発リードタイム短縮への挑戦
- 30. 30 QA
Editor's Notes
- @IT 主催、オージス総研さん、協賛 “リリース直前のサプライズ”を防ぐ、「スピーディに品質を作り込む」二つの秘策 https://itmedia.smartseminar.jp/public/seminar/view/687 ※パターンとは? はこちらをご参照ください。 『パターン、Wiki、XP』江渡浩一郎 （Eto, Kouichiro） アレグザンダー ･･･ パターンの集合である総体を言語になぞらえた。1つの建築活動に必要なパターンの集まりを「パターン・ランゲージ」と名づけた
- ※ リードタイム = 工程に着手してから全ての工程が完成するまでの所要期間 (http://ja.wikipedia.org/wiki/リードタイム) --> 開発リードタイム ･･･ 製造工程に着手してからリリースするまでの所要時間 (要件定義の時間短縮の話はしません)
- 開発リードタイム短縮のための業務改善策を計画・実装して広めるためにやってきたことのパターンを、人に関するもの、システムに関するものにまとめてみたのが、こちらと次のスライドになります。
- 開発リードタイム短縮のための業務改善策を計画・実装して広めるためにやってきたパターンのうち、システムに関するものがこちらのスライドになります。 枠の線を太くしてある、Git化、自動化、リポジトリ連携、脱Excel 、の４つのパターンは、私がこれまでやってきたことを振返ってみて、パターンといえるかな、というものをあげています。
- ビルド結果ページと、Stash、Jiiraへのリンクです。 前回のビルドから、今回のビルドまでに、誰がどんな変更をしたか、サマリ表示されます。 また、その変更はどのチケット起因かもリンクされます。 もしビルド失敗するようなことがあれば、犯人の特定がかなり容易です。
- マニュアルテストの失敗報告画面から、Jiraチケットを起票するところです。 1クリックで、テストの前提条件、手順、期待値、テスターのコメントを転記したjirチケットを起票できます。 当然、テスト結果レポートとこの起票されたJiraはリンクされるので、マネージャーが失敗したテストケースは対応済みかどうかがすぐに分かります。 コーダーはいちいちテスト実行手順を聞く手間を省けて、地味に便利な機能です。
- 継続的デリバリーもつきつめれば、Server、SW、Networkの実装です。 開発業務のシステム化にほかなりません。
- デモの流れです。 ビルドプランを選択し、ビルドが走り、Glassfish管理サーバにwarファイルを移送し、デプロイコマンドをキックします。デプロイ対象のクラス名は、ビルド開始時に入力した値を使います。 デプロイ後は、手動の結合テストや、セレニウムを使ったUIの自動テストを走らせます。 私たちのグループでは、このUIの自動テストを 継続的システムテストと称し、デグレの早期発見に取り組みはじめました。 継続的システムテストの詳細（コンセプト、課題、ソリューション）は参照先のコンテンツをご参照ください。
- ※人間がやるレビュー 読みやすい(他の人が再短時間で理解できる) コードか否か 他のメンバーに期待して良い技術レベルは各チーム毎に文化としてなんとなく決まっていればよい。ただし、学習コストに対して効果が十分高いものは導入するべき。 明確な単語を選ばれているか？ネーミングの問題 × いい加減な名前。tmp × 誤解される checkNull) ○ 付加された情報 plaintext_password コメント (書き手の意図を読み手に知らせること) 制御フロー･･･読みやすく (if/elseブロックの並び順、三項演算子、早期return、ネストを浅くする)
- 募集中！待ってます！