Upgrade to Pro — share decks privately, control downloads, hide ads and more …

楽楽明細の開発を支える技術

B887cc104275187588fae7d58790563e?s=47 A1
April 24, 2017

 楽楽明細の開発を支える技術

2017/4/21 合同ビアバッシュ発表資料

B887cc104275187588fae7d58790563e?s=128

A1

April 24, 2017
Tweet

More Decks by A1

Other Decks in Programming

Transcript

  1. 楽楽明細の開発を⽀支える 技術 株式会社ラクス ファイナンシャルクラウド開発3課 Eiichi Mita 2017/4/21

  2. ⾃自⼰己紹介 • Eiichi Mita • Twitter/Qiita/Github/mstdn.jp: @eichisanden • 2014年6⽉月⼊入社(Ops=> SIer

    => ラクス) • ⼊入社以来、楽楽明細を担当 • ポケモンおじさん WANTED!!
  3. None
  4. 楽楽明細 • 2013年にサービスイン • Java 8/Tomcat/Apache/PostgreSQL • 現在、開発者は3名 • ⼀一番多い時でメンバー8名

  5. 現在は、マンパワーはないが ⼩小回りが利くので、⼩小さな改善はし やすいタイミング YYY ͠Α͏ͥ :FBI

  6. ただ、やることが多く開発や改善に時間を取れ ない ։ൃ ӡ༻ ׂΓࠐ ΈλεΫ όάର Ԡ վળ ಋೖࢧԉ

    αϙʔτ
  7. ӡ༻ ׂΓࠐΈ λεΫ αϙʔτ όάରԠ վળ ಋೖ ࢧԉ ։ൃ こうしたい

  8. 銀の弾丸はないので地道に改善して いっている

  9. 開発フロー

  10. Subversion + Redmineでの コードレビューが⾟辛い(結構前の話 ですが) 課題 チケットに「xxxクラスの何⾏行⺫⽬目の…」と書いた り、該当箇所のコード貼りつけたり、とにかく⾟辛 かった(ましてオフショア相⼿手なら尚更…)

  11. GitLab導⼊入 解決 マージリクエストベースでの開発 レビュアーもレビュイーも⼤大幅に負担軽減

  12. Gitのブランチ運⽤用 解決 Gitフローを多少アレンジした感じでやって います。

  13. NBTUFS WEFW GFBUVSF GFBUVSF GFBUVSF こんな感じ

  14. Gitだとコミットの単位を調整しやすい 解決 git add -p や git rebase -i などを駆使してレビューし

    やすい単位でコミットを分割。 リファクタリングと業務要件の実装は分けてコミット。
  15. テスト

  16. テストがない!!! 課題 ※実際は、ない訳ではなく、 過去に作成したJUnitのテストをメンテできずにビルドからも外され塩 漬けになったいた。 テストコードのメンテはそれなりに⼯工数が掛るので、致し⽅方ない⾯面 も。。

  17. テストを復活させた 解決 殆どのテストコードはそのまま使えた ただし、少しの修正で蘇⽣生できないテスト は捨てた 㱺ݹ͍΋ͷݻࣥ͢ΔΑΓ早くテストがある 状態に戻すことが先決だった!!

  18. Mockito導⼊入 解決 以前は依存するクラスを動かすために、テ ストごとにDIコンテナを起動していた 㱺͘͢͝஗͍͠ɺґଘ͢ΔΫϥεΛಈ͔ͨ͢Ίͷ setupも⼤大変。  本質的じゃないところで疲弊してテストがメンテで きなかたのかも(想像) Mockを活⽤用してテストしたいコードに集 中できるようになった

  19. JUnitを3から4へバージョンアップ 解決 テストの階層化やパラメータ化が可能にな り、より分かりやすくテストが書けるよう になった 㱺ϊ΢ϋ΢ΛษڧձΛ։࠵ͯ͠νʔϜ಺ʹ ڞ༗した

  20. コミット時のテスト⾃自動実⾏行とカバ レッジも⾒見えるようにした 解決

  21. テストが失敗するとすぐ分かるように 解決 リアルなおっさんが怒って詰め寄ってき ます

  22. E2Eテスト

  23. リリース前のリグレッション テストが⾟辛い 課題 でも、デグレが怖いのでやらない訳にも いかない

  24. Seleniumテストを導⼊入(準備中) 解決 SeleniumラッパーはSelenideを使⽤用しています。 去年のSeleniumアドベントカレンダーに記事を書きました。 http://qiita.com/EichiSanden/items/ea857b46cbf5435b0c3b

  25. リリース時の疎通確認が⾟辛い 課題 サーバも増えてきたし、 もはや⼿手動でやるレベルじゃなくなってきた

  26. Selenideでテストを作成 解決 次回のリリースから本格的に使⽤用予定

  27. DBマイグレーション

  28. 元々、DDLは差分パッチSQLで管理していたが、ど の環境にどこまで当てたか分かりにくかった 課題 CFHJO BMUFSUBCMFIPHFBEE DPMVNODPMUFYU DPNNJU CFHJO JOTFSUJOUPIVHB JE

    WBM  WBMVFT  BBB    CCC  DPNNJU CFHJO ESPQUBCMFHPNJ DPNNJU 20170419_1.sql 20170420_1.sql 20170420_2.sql
  29. Flywayを導⼊入した • flyway info でどこまで当っているか確認できる • flyway migrate を実⾏行すれば、まだ適⽤用していない パッチだけを当ててくれる

    • 本番環境はどこまで当っているか⾃自明なので、検証環 境でのみ利⽤用 • Flywayはバージョンダウンには対応していないが、 そこは割り切った(たまに欲しい時があるが、バー ジョンダウンのSQLを常に書くのは割に合わないた め) 解決
  30. 運⽤用

  31. アプリからのエラー通知がメールで来るが ⼤大量すぎて⼤大事なものが埋もれてしまう 課題

  32. 無駄なアラートを減らす取り組み 解決⽅方法 ɾηογϣϯ͕੾Εͨޙͷૢ࡞ ɾbotからのアクセス ɾμ΢ϯϩʔυதʹΩϟϯηϧ͞Εͨ ɾϥΠϒϥϦ͕ग़ྗ͢ΔແବͳΤϥʔ など内部エラーを減らす取り組みを地道に⾏行っている あるサーバーからの通知数が 1年前 1127通

    -> 今年 377通に激減 メールをチェックする時間短縮と重要なアラートを⾒見 逃すリスクが減った!
  33. DevOps(的な)

  34. 開発担当とインフラ担当が分かれており、 すごく典型的なDevOpsの問題がある 課題

  35. • 組織的な問題まで踏み込めないので、出来 ることをやるのみ 解決できていないが…

  36. 依頼した作業の背景をきちんと説明する 㱺໨త΍എܠΛ理解してもらうことで同じゴールを⺫⽬目指せる 考え⽅方の違うことを理解する 㱺͓ޓ͍ओு͕͋ΔͷͰาΈدΔ͜ͱ͕⼤大事 運⽤用系のシェルなど、GitLab上で共同メンテ しようと準備中 㱺࠷ॳ͸গ͠൓ରҙݟ΋͕͋ͬͨɺϝϦοτΛઆ໌ͯ͠΍ͬ ͯΈΔ͜ͱʹɻOpsにもGitLabを使ってもらって相互レ ビューし合うのが理想 やっていること

  37. Infrastructure as Code ɾखॱॻϕʔεͷ؀ڥߏங͸ਏ͍ͷͰɺAnsibleなど、オー ケストレーションツールを使っていきたい。 ɾサーバーが増えるたびに動作確認するのも⾟辛いので、そろ そろコード化しないとキツイ 㱺ͱΓ͋͑ͣϩʔΧϧ։ൃ؀ڥͷߏஙͰAnsibleや ServerSpecを使って広めようとしている。 (⼩小さく始めて実績を作ると広めやすいと思っている)

    やりたい
  38. 今後やりたいことは沢⼭山... フレームワーク乗り換え マイクロサービス Docker AWS アジャイル/スクラム デザインガ イド React/AngularJS/Vue Sass/Less/Stylus

    EsLint Gradleで依存関係解決 PostCSS ローカル開発環境の⾃自動構築 Elastic Search/Kibana/Embulk CI/CD Jenkins2/GitLab CI Swagger Go Babel Webpack
  39. バイブル

  40. ご清聴ありがとうございました