Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie 2017spring jjug ccc_f2
Ähnlich wie 2017spring jjug ccc_f2 (20)
2017spring jjug ccc_f2
- 2. #ccc_f2 自己紹介 和田 一洋（わだ かずひろ） • グロースエクスパートナーズ（株）所属 • 大手SIerで６年間勤務ののち2015年に GxP入社 • http://qiita.com/khwada 1
- 3. #ccc_f2 紹介するプロジェクト • 金融系のコンシューマー向けWeb会員サイト （会員数：約60万）の受託開発 • 10名強のチームで開発 • 顧客情報システム部門と開発チームを支援す る業務に従事 顧客 情報システム部門 弊社 開発チーム 10名強 要件や方式の 取りまとめ支援 設計や開発改善 の支援 2
- 4. #ccc_f2 今日の話（変化のスイッチ） • 以前の自分 • 勉強会に参加したり、技術書を読んでも、日々 の開発にどう生かせるのか、どうしたら近づいてい けるのか分からなかった • エンタープライズ開発のあるある？ • つまり「変化のスイッチ」が分からなかった • 「こうあるべき」「こうなるべき」は分かっても・・・ • 「何をまず変えれば変化の歯車が回りだすのか」 「現実的にどうすれば変わるのか」が分からない ※ http://d.hatena.ne.jp/Chikirin/20090210 3
- 5. #ccc_f2 今日の話 • 参画から２年間の取り組みを４つのフェーズ に分けてご紹介（だいたい半年ずつ） • 各フェーズで取り組んだことと、その「変化のス イッチ」について 参画 開発 モダン化 巻き取り 段階的な 再構築 いまココ！ モジュール分割 OAuth2 Provider ふりかえり ブランチ運用 CI/CD build pipeline API化 モジュール再分割 4
- 7. #ccc_f2 参画のきっかけ • 既存のベンダーさんが大規模案件に追われる 中、「規模は小さいがスピード感が求められ る」開発を進めるために参画。 • システムの中身はほとんど知らない状態。 • レガシーフレームワーク（Struts1系ベースの 独自フレームワーク）上での開発、ソースの変 更履歴をコメントアウトですべて保持、そして、 ベンダーをまたがったソースコードマージ・・・ ⇒モジュール分割 6
- 10. #ccc_f2 モジュール分割 • 役割分担 • アプリ１：引き続き既存ベンダーが担当 • アプリ２：GxPが担当 • 制約 • インフラ部門との調整にかける時間がなかったた め、モジュールをear同梱することでインフラ影響 を最小化 • DBは共有、HttpSessionも共有 9
- 11. #ccc_f2 モジュール分割 • 残った課題（後述） • アプリ２で「メニュー」を表示できない • 各機能の認可判定が仕様／実装ともに複雑 で、認可判定ロジック（メニュー生成ロジック） は簡単には呼び出しや移植ができなかった 10 各機能 コンシューマー 各機能 認可判定ロジック アプリ１ アプリ２
- 12. #ccc_f2 モジュール分割の効果 • 提携サービスとの連携をはじめるにあたり、 OAuth2連携を導入 • Spring Security OAuth2を利用して、ア プリ２上にOAuth2 Provider機能を開発 ⇒レストランやホテルの予約サイトなど、様々な 提携サービスに「XXXXXでログイン」がついた ⇒レガシーフレームワーク上では難しい機能を実 現し、モジュール分割の効果を示すことができた 11
- 13. #ccc_f2 変化のスイッチ • レガシーフレームワーク上での開発はしたくない、 従来の開発文化を引き継いではいけない、と いう想い • やや強引に「モジュール分割する」と決めて、 顧客を説得し、ジャンプをした • 課題も出たが、次につながる結果を出せた 12
- 15. #ccc_f2 ふりかえり • 開発が軌道に乗ったタイミングから、定期的な ふりかえりを開始 • 隔週（目標）でKPTを実施 • 若手を含めたチーム全員が、日常の作業から いったん離れて、プロジェクトについて考え、意見 を発信する場（付箋を利用した個人ワークを 挟む） • 現在では、開発チームが10名強に増えたため、 毎回２チームに分けて、それぞれテーマを決め て実施 14
- 17. #ccc_f2 16 ふりかえり 前回までのTry進捗状況の確認 全体 10分 Keep／Problem出し 個人 5分 Keep／Problemをチーム内共有 チーム 10分 Try出し 個人 5分 Tryをチーム内共有 チーム 10分 全体共有 全体 10分 Actionの選定 全体 10分 ・挙がったTryからタスク化するものを選ぶ ・残っている過去のTryも含めて優先度が高い10個 程度のタスクに対して、ToDoラベルをつけて担当者 を割り当て
- 18. #ccc_f2 補足：Atlassianツール 17 Wiki／情報共有 他の例) ・Redmine ・Qiita:Team Issue Tracking System 他の例） ・Redmine ・Backlog ・GitHub issues Gitリポジトリ 他の例） ・GitHub ・GitLab 継続的インテグレーション（CI） 他の例） ・Jenkins ・Travis CI ・Circle CI
- 19. #ccc_f2 ブランチ運用 • 課題 • masterへのマージタイミングをはっきり決めてい なかった • 社内テスト環境にリリースするとき？ • 顧客の環境にリリースするとき？ • 本番リリースするとき？ • 並行開発時のブランチ運用ルールが曖昧で、ブ ランチがぐちゃぐちゃになりかけていた ⇒Git-flowをベースとしたブランチ運用を導入 18
- 21. #ccc_f2 ブランチ運用 • 新たな課題 • 顧客側でのテスト期間が長く、なかなか developをmasterへマージできない • その間、次の開発を「案件親ブランチ」で運用す るが、並行開発案件が多くなると「開発親ブラ ンチ」の数が多くなり、リリース順も分かりづらい ⇒バージョン番号を導入 20
- 22. #ccc_f2 ブランチ運用 • バージョン番号 • リリース順に採番 • バージョン番号ごとのdevelopブランチを作成 • 採番ルール • メジャーバージョン：一定規模以上の案件 • マイナーバージョン：定期保守リリースなど • リビジョン：緊急リリース • 間に案件が入った場合、マイナーバージョンで間 に挟み、一度決めたバージョンは変更しない 9.1.1 メジャー マイナー リビジョン 21
- 25. #ccc_f2 CI/CD（テスト自動化） • エビデンス納品対象のテストを「結合テスト」と 定義 • 単体テストは原則JUnit化 JUnitでテストしづらいところは、手動（打鍵） でテスト • 結合テストは打鍵してExcelにスクリーンショット を貼りつけ、整形してエビデンスとする ただしSelenide（Seleniumラッパー）を利 用して、ブラウザオートメーションによる打鍵補助 を導入 24
- 26. #ccc_f2 CI/CD（テスト自動化） テストフェーズ テスト観点 実施＆レビュー方法 単体 validationや業務ロジックのパターン網 羅／境界値テスト API呼び出しの正常系／異常系 JUnit（DB読み書きや他シ ステムAPIはモック） テストコードレビュー 画面単体 画面レイアウト／文言 正常系／異常系メッセージの表示位置 JavaScriptの挙動 打鍵 Excelでのテストエビデンスの レビュー 結合 画面遷移 会員やデータのパターン データの登録更新パターン モジュール間を結合したシナリオ 打鍵（Selenideによる打 鍵補助） Excelでのテスト設計／テス ト結果のレビュー 25
- 27. #ccc_f2 CI/CD（テスト自動化） • レビューアに優しいテストコード 例)validation • 画面入力１項目ごとにグルーピングして階層化 @RunWith(Enclosed.class) • テストメソッド名は日本語に 26
- 28. #ccc_f2 CI/CD（テスト自動化） • 次のステップ • 外部仕様に対するテストコード • 実装ロジックをなぞるテストコードは、プロダクトコード を直すときは必ずテストコードを触ることになる • 改修時のデグレ防止、実装後のリファクタリングの自 由度を上げられるテストコードに • E2Eテストの自動化 • selenideの資産を活用 • 主要なシナリオに限って回帰テストを定期自動実 行 27
- 30. #ccc_f2 CI/CD（テスト環境デプロイ） • 課題 • デプロイの手作業が煩雑 • 並行開発が増え、テスト環境が増えるとさらに 煩雑 • テスト環境にデプロイしようとしてbuildするまで、 JUnitテストをまとめて実行するタイミングがない ⇒Bambooを導入 29
- 33. #ccc_f2 変化のスイッチ • ふりかえりを起点に、手の届く範囲から地道な 改善を積み重ねた • 参画期に、スピードを優先して進めた部分を見 直して足場固め • 自分たちでプロジェクトを改善できるという実感 を得た • 「自動化」という当たり前のことも、取り組んで いくと、教科書的な話だけでない次の課題や ステップが見えてくる = チームの成長 32
- 36. #ccc_f2 巻き取り • 課題：「アプリ１」のビルド方法・・・ • 本番のwarを解凍し、リリース対象のclassファ イルを入れ替えて、圧縮しなおすことでwarを作 成して、リリースしていた • テスト環境／本番環境の環境差異はコメント アウトで切替 • リリース時のミスも頻発・・・ ⇒巻き取りに際してビルド改善の工数を確保し ていただいた 35
- 37. #ccc_f2 build pipeline • 「アプリ１」をgradleでビルドできるように • 環境ごとの差異は設定ファイルに追い出して、 設定値でふるまいを変えるように改修 • ソースコードとビルド成果物を1:1に • 地道に検証 • gradleでbuildしたwarの中身を逆コンパイル • 本番環境のwarの中身を逆コンパイル ⇒diffを取り、意図しない差異がないかを検証 36
- 38. #ccc_f2 build pipeline アプリ１ push アプリ１trigger war アプリ２ trigger build push trigger deploy アプリ２ ear 37
- 39. #ccc_f2 API化 • 「アプリ１」を巻き取ったことで、全体最適の視 点で機能配置を考えられるように • ２つのアプリの疎結合化に着手 • アプリ間連携をRest API化 • HttpSession経由での新たな共有はしない 38
- 41. #ccc_f2 変化のスイッチ • 開発モダン化期で自動化をしていたからこそ、 その流れに乗せることを前提にできた • 継続開発で顧客との築いてきた信頼関係が前 提 • 各活動の意義を理解していただき、各案件や 保守の中で少しずつ工数を使わせていただいた • 「アプリ１」に手を出せるようになったことにより、 部分最適から全体最適へ視点が変わった 40
- 43. #ccc_f2 段階的な再構築 • 顧客内でレガシーフレームワークの撤廃が求め られるように • 合わせて画面リニューアル、スマホ最適化方 式の見直しなどを進めたい • ただし、移植中の案件凍結はなるべく避けた い ⇒各開発案件内で、改修対象機能を「アプリ ２」に移植していく方針に（段階的な再構築） 42
- 44. #ccc_f2 段階的な再構築 機能１ 機能２ 機能３ … 機能４ 機能５ 機能１ 機能２ 機能３ … アプリ１ アプリ１ アプリ２ 機能４ 機能５ アプリ２ 機能１ 機能２ 機能３ … もともと 現在 移植完了後…？ 43 レガシー フレームワーク レガシー フレームワーク Spring Spring
- 46. #ccc_f2 モジュール再分割 • 当初は「ベンダー」切り口でのモジュール分割 • ベンダーをまたがったソースコードマージを避ける • １社体制になった今のモジュール分割 • 複数案件並行開発時のマージを最小化 • 改修時の影響調査／リグレッションテスト範囲 を局所化 • （将来的に）モジュールごとに非機能要件を 分ける 45
- 47. #ccc_f2 モジュール再分割 • 新規アプリへの切り出し • CRUD対象テーブルが比較的独立しており、同 時に改修が入るケースが多い機能群 • 方式 • 引き続きearに同梱（インフラの見直しは、 H/W保守切れのタイミングまで待つ） • メモリ上でのHttpSession共有はしない（疎 結合化） • Oracle DBへのconnection数の増大を防ぐ ために、weblogicのconnection pool管理 を利用 46
- 51. #ccc_f2 まとめ 50
- 53. #ccc_f2 まとめ • 内発的なスイッチ • ふりかえりを起点に、手の届く範囲から改善 • 自分たちでプロジェクトを改善できる、という実感を 得る • 取り組んでいくと、教科書的な話だけでなく、次の 課題やステップが見えてくる = チームの成長 • 外発的なスイッチ • 世の中のアーキテクチャ／技術トレンドの変化、新 しいツールの普及（「当たり前」が変わっていく） • やや（？）無茶な要件やスケジュールを真剣に考 えてみる機会が、ブレークスルーを生むことも 52
- 54. #ccc_f2 まとめ • 内発的なスイッチ • 自分たちでコントロールできる • 外発的なスイッチ • 自分たちでコントロールできない • ただし、チームがちゃんと準備をしていれば、チャ ンスが訪れたときに掴むことができる • 準備 = 社内外の勉強会などを通して世の中 のトレンドを知る。知るだけでなく、触ってみて、 自分たちのプロジェクトに引きつけて考える。 53