開発リードタイム短縮への挑戦 ?とある現場のパターン?ランゲージ?
Download as PPTX, PDF9 likes2,858 views
2015年3月10日 @IT主催勉強会 基調講演 https://itmedia.smartseminar.jp/public/seminar/view/687
![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](https://image.slidesharecdn.com/20150310itstudygroupjp-150312044242-conversion-gate01/85/-15-320.jpg)
![[Biz reach qa meetup] qa team_build](https://cdn.slidesharecdn.com/ss_thumbnails/bizreachqameetupqateambuild-190719053542-thumbnail.jpg?width=560&fit=bounds)
More Related Content
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
- #2: @IT 主催、オージス総研さん、協賛 “リリース直前のサプライズ”を防ぐ、「スピーディに品質を作り込む」二つの秘策 https://itmedia.smartseminar.jp/public/seminar/view/687 ※パターンとは? はこちらをご参照ください。 『パターン、Wiki、XP』江渡浩一郎 （Eto, Kouichiro） アレグザンダー ??? パターンの集合である総体を言語になぞらえた。1つの建築活動に必要なパターンの集まりを「パターン?ランゲージ」と名づけた
- #5: ※ リードタイム = 工程に着手してから全ての工程が完成するまでの所要期間 (http://ja.wikipedia.org/wiki/リードタイム) --> 開発リードタイム ??? 製造工程に着手してからリリースするまでの所要時間 (要件定義の時間短縮の話はしません)
- #7: 开発リードタイム短缩のための业务改善策を计画?実装して広めるためにやってきたことのパターンを、人に関するもの、システムに関するものにまとめてみたのが、こちらと次のスライドになります。
- #8: 開発リードタイム短縮のための業務改善策を計画?実装して広めるためにやってきたパターンのうち、システムに関するものがこちらのスライドになります。 枠の線を太くしてある、Git化、自動化、リポジトリ連携、脱Excel 、の４つのパターンは、私がこれまでやってきたことを振返ってみて、パターンといえるかな、というものをあげています。
- #17: ビルド結果ページと、Stash、Jiiraへのリンクです。 前回のビルドから、今回のビルドまでに、誰がどんな変更をしたか、サマリ表示されます。 また、その変更はどのチケット起因かもリンクされます。 もしビルド失敗するようなことがあれば、犯人の特定がかなり容易です。
- #18: マニュアルテストの失敗報告画面から、Jiraチケットを起票するところです。 1クリックで、テストの前提条件、手順、期待値、テスターのコメントを転記したjirチケットを起票できます。 当然、テスト結果レポートとこの起票されたJiraはリンクされるので、マネージャーが失敗したテストケースは対応済みかどうかがすぐに分かります。 コーダーはいちいちテスト実行手順を聞く手間を省けて、地味に便利な機能です。
- #24: 継続的デリバリーもつきつめれば、Server、SW、Networkの実装です。 開発業務のシステム化にほかなりません。
- #25: デモの流れです。 ビルドプランを選択し、ビルドが走り、Glassfish管理サーバにwarファイルを移送し、デプロイコマンドをキックします。デプロイ対象のクラス名は、ビルド開始時に入力した値を使います。 デプロイ後は、手動の結合テストや、セレニウムを使ったUIの自動テストを走らせます。 私たちのグループでは、このUIの自動テストを 継続的システムテストと称し、デグレの早期発見に取り組みはじめました。 継続的システムテストの詳細（コンセプト、課題、ソリューション）は参照先のコンテンツをご参照ください。
- #29: ※人間がやるレビュー? 読みやすい(他の人が再短時間で理解できる) コードか否か? 他のメンバーに期待して良い技術レベルは各チーム毎に文化としてなんとなく決まっていればよい。ただし、学習コストに対して効果が十分高いものは導入するべき。 明確な単語を選ばれているか？ネーミングの問題 × いい加減な名前。tmp × 誤解される checkNull) ○ 付加された情報 plaintext_password コメント (書き手の意図を読み手に知らせること)? 制御フロー???読みやすく (if/elseブロックの並び順、三項演算子、早期return、ネストを浅くする)?
- #32: 募集中！待ってます！