Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

JavaでWebサービスを作り続けるための戦略と戦術 JJUG-CCC-2018-Spring-g1

1,197 views

Published on

ビジネスは利益を求め日々成長することを是としています。そのためにコードは書かれ続けます。そして書いたそばから陳腐化してゆきます。株式会社ビズリーチの主力事業、ビズリーチシステムのメイン言語はJavaです。このセッションでは、社内で最も古くからあるシステムの1つをJavaで開発し、事業として顧客に提供し続ける中で遭遇した課題、つちかってきた戦略と戦術を、余すところなくお話します。

Published in: Software

JavaでWebサービスを作り続けるための戦略と戦術 JJUG-CCC-2018-Spring-g1

  1. 1. #ccc_g1 published JavaでWebサービスを作り続けるための 戦略と戦術 JJUG-CCC 2018 Spring ベルサール新宿 2018-05-26 Y. Watanabe
  2. 2. #ccc_g1 published ストップウォッチスタート確認 2
  3. 3. #ccc_g1 published 3
  4. 4. #ccc_g1 published Webサービスを止めずに Webサービスを進化させ続けるには? 4
  5. 5. #ccc_g1 published Who? ● 渡辺 祐 ● (株)ビズリーチ ● SREグループ ○ Site Reliability Engeneering ● twitter: @nabedge 5
  6. 6. #ccc_g1 published ビズリーチシステムとは ● 創業事業かつ主力事業 2009〜 ● 社内でもっとも古くから稼働している Javaアプリケーション群 6
  7. 7. #ccc_g1 published 1. 開発環境とCI戦略 2. 老朽化した技術からの脱却 3. フロントエンドと仲良くする 4. 手動テストも、自動テストも。 5. セキュリティ 6. バージョンアップする 7
  8. 8. #ccc_g1 published 1. 開発環境とCI戦略 2. 老朽化した技術からの脱却 3. フロントエンドと仲良くする 4. 手動テストも、自動テストも。 5. セキュリティ 6. バージョンアップする 8
  9. 9. #ccc_g1 published Q. 開発環境とは? A. そこでアプリケーションが動く けど、それは本番用ではないモノ すべてを指す PCだけ?エンジニアだけ? 9
  10. 10. #ccc_g1 published 「動くソフトウェアこそが 進捗の最も重要な尺度」 アジャイルソフトウェア開発宣言より 10
  11. 11. #ccc_g1 published ● あるエンジニアのPCでなら動く ● 他のエンジニアのPCでも動くけど 準備に時間がかかる ● 検証環境でも動くけど、いま別のチームが テストのために検証環境にデプロイしているのは 別ブランチのコードなのでやっぱり動かない 逆に、なぜ ”動かない” のか? 11
  12. 12. #ccc_g1 published あるべき姿(ローカル開発環境編) 1. sh ./setup.sh でミドルウェアは全部入る 2. データ層へのテストデータ投入も 1に含まれている 3. システムAのローカル開発環境は システムBのそれと干渉しない 12
  13. 13. #ccc_g1 published 仮想OS on 仮想OS 13 OracleVirtualBox CentOS Docker (MySQL) Docker (Redis) CentOS Docker (PgSQL) Docker (fakes3) Aサービス のコード Bサービス のコード 172.16.1.1 172.16.2.2 setup.sh setup.sh Mac OS
  14. 14. #ccc_g1 published あえて生dockerを使わなかった理由 ● “その当時は”、Docker for Macが不安定だった ● mysqlはlocalhost:3306だと他の環境とバッティング ○ ex. 新人君が本を写経しようとして... 14
  15. 15. #ccc_g1 published setup.shがやってること 1. vagrant up 1.1. 仮想OS(CentOS)起動 1.2. yum install docker-ce 2. vagrant ssh -c “docker-compose up -d” 2.1. mysql, solr, localstack, etc... 3. DBにテストデータをINSERTするスクリプト 15
  16. 16. #ccc_g1 published ● あるエンジニアのPCでなら動く ● 他のエンジニアのPCでも動くけど 準備に時間がかかる ● 検証環境でも動くけど、いま別のチームが テストのために検証環境にデプロイしているのは 別ブランチのコードなのでやっぱり動かない 逆に、なぜ動かないのか?(再掲) 16
  17. 17. #ccc_g1 published ● いま、ローカル開発環境用に作っている Dockerfileをそのまま検証環境、本番環境で 使えれば使いたい。使えるように書きたい。 ● 少なくともDockerに関する知見を エンジニアが蓄積できる ● Dockerfileのメンテナはアプリケーションエンジニア。 17 Docker利用は将来構想に向けての布石でもある
  18. 18. #ccc_g1 published Eclipse -> IntelliJ IDEA 1. ライブラリプロジェクト、アプリケーションプロジェクトの絶対数 が増 a. フラットなプロジェクトレイアウトが前提のEclipseだと何かと不都合 2. Python, TypeScript, Android Java... 3. Scalaのチームもいる 4. 全社の全エンジニアまとめてIntelliJ 18
  19. 19. #ccc_g1 published Maven -> Gradle ● ライブラリプロジェクト、アプリケーションプロジェクトの絶対数 の増加 ● CPUのコア数に合わせて並列ビルドできるほうが有利 ● フロントエンドのビルドツールもろともgradleから制御したい ● pom.xmlよりもbuild.gradleのほうが自由度が高いわりに読み やすい 19
  20. 20. #ccc_g1 published Jenkins1から2へ。そしてJenkinsfileへ 20 ● Maven -> Gradle移行の過程でjenkinsジョブの 調整コストが増 ● 全ソース, build.gradle, Jenkinsfile まで含め git管理するだけで楽勝。 ● っていうのを見越してまず先にJenkins2に バージョンアップしていた
  21. 21. #ccc_g1 published 次に目指しているところ(構想) 1. プルリクエストひとつに対して それ専用の検証環境がひとつ自動構築される 2. pushされる都度mergedな状態のコードで 1の環境にビルド&デプロイされる 3. 非エンジニアが会議室のプロジェクタで 動くソフトウェアをいつでも確認できる 21
  22. 22. #ccc_g1 published ● あるエンジニアのPCでなら動く ● 他のエンジニアのPCでも動くけど 準備に時間がかかる ● 検証環境でも動くけど、いま別のチームが テストのために検証環境にデプロイしているのは 別ブランチのコードなのでやっぱり動かない 逆に、なぜ動かないのか?(再掲) 22
  23. 23. #ccc_g1 published 以下は、その実現方法論にすぎない ● イミュータブルインフラストラクチャ ● Blue/Greenデプロイメント ● 12-Factor App 23
  24. 24. #ccc_g1 published 1. 開発環境とCI戦略 2. 老朽化した技術からの脱却 3. フロントエンドと仲良くする 4. 手動テストも、自動テストも。 5. セキュリティ 6. バージョンアップする 24
  25. 25. #ccc_g1 published インストール型Tomcatはオワコン 25
  26. 26. #ccc_g1 published ● tomcat(インストール前提)をどうやって 起動してますか? ○ maven-tomcat-plugin ? ○ WTP? ○ sysdeo plugin? 26
  27. 27. #ccc_g1 published ● “public static void main”ならIDEだろうと サーバ上のCLIだろうと、どうにでも動かせる 27 public class AppStarter { public static void main(String args[] argv) { Tomcat tomcat = new Tomcat(); tomcat.start();
  28. 28. #ccc_g1 published Tomcatとは、インストールするものではなく、 new するもの。 参照:JJUG-CCC-2014 Fall 「JavaでやってみるThe Twelve Factor App」 28
  29. 29. #ccc_g1 published JasperReportsはオワコン 29
  30. 30. #ccc_g1 published JasperReportはオワコン ● PDF出力ライブラリ ● Java8だとデザインツールが事実上動かない ○ (2016年当時です。今は知らない) ● 全体のJava8化を阻害する意外なボトルネックだった ● flying-soucer-pdf でPDF関連機能を全部作り直し 30
  31. 31. #ccc_g1 published ポイントはJasperReportの話ではなくて... 31
  32. 32. #ccc_g1 published “JSESSIONID”はオワコン 32
  33. 33. #ccc_g1 published “JSESSIONID”はオワコン ● サブシステムAは http://localhost:8001/ ● サブシステムBは http://localhost:8002/ ● 両方ともセッションCookie名が ”JSESSIONID” ● ローカル開発環境でA, B同時に起動すると 片方でしかログイン状態を保てない ● エンジニアの生産性低下 33
  34. 34. #ccc_g1 published 意外と知らない人がいるから念のため Tomcatで言えば6.0.28 (2010年)から実装済み <!-- web.xmlの場合 --> <session-config> <cookie-config> <name>MY_HOGE_SESSIONID</name> </cookie-config> </session-config> 34
  35. 35. #ccc_g1 published // JavaConfigの場合 @WebListener public class SessionTrackingListener implements ServletContextListener { @Override public void contextInitialized(ServletContextEvent event) { SessionCookieConfig config = event.getServletContext().getSessionCookieConfig(); config.setName("MY_HOGE_SESSIONID"); config.setHttpOnly(true); 35
  36. 36. #ccc_g1 published でもなあ、セッションクッキー名が ”JSESSIONID”ではなくなります!って言うと、 L7ロードバランサのスティッキーセッションcookieも 設定変更しなきゃいけなくなって、 インフラ担当チームと調整しなきゃなんだよなあ。 36
  37. 37. #ccc_g1 published sticky-session-cookieもオワコン 37 1号機JVM 2号機JVM セッション ALB JSESSIONID=abc123.1
  38. 38. #ccc_g1 published sticky-session-cookieもオワコン ● APサーバ2台の冗長構成だとして ● リリースのときは1台ずつ止めてデプロイ ● リリース中は片系統にアクセス集中 ● リリース後も片系統にアクセス集中したまま (sticky-session-cookieとはそういうもの) ● 同時利用ユーザー数が増えると... !! 38
  39. 39. #ccc_g1 published sticky-session-cookieもオワコン ● spring-session-redis のフィルタをかぶせるだけで、 javax.servlet.http.HttpSessionの取り回しをラッピング 39 1号機JVM 2号機JVM ALB Redis セッション
  40. 40. #ccc_g1 published ● L7ロードバランサ、お払い箱説。 ● WAF的な機能は残るかもですが。 40
  41. 41. #ccc_g1 published セッションストアが JVMヒープでは無いということは? SerializationFailedExceptionを起こしやすくなる 41
  42. 42. #ccc_g1 published “設定ファイル.xml”はオワコン 42
  43. 43. #ccc_g1 published “設定ファイル.xml”はオワコン ● xmlは修正ポイントがわかりにくい ● JavaConfigならIDEで補完が効くのでミスりにくい ● JavaConfigはif文、switch文なんでもOKで小回りが利く ○ 環境差分に対処しやすくなる ■ 環境が無数にある場合に便利 ■ さっき、プルリクエスト毎に専用環境が...って話 43
  44. 44. #ccc_g1 published おすすめの「JavaConfigはじめかた」 <beans xmlns:context="http://www.springframework.org/schema/context"> <context:component-scan base-package="jp.bizreach.foo"/> </beans> 44 package jp.bizreach.foo @Configuration public BarConfig { @Bean public HogeService hogeService() {...} } xmlファイルにほんの数行だけ残しておく
  45. 45. #ccc_g1 published jspはオワコン 45
  46. 46. #ccc_g1 published jspはオワコン ● 今さら自作カスタムタグのメンテだるい。 ● リファクタリングしづらくてゴミになりがち ● メールのテンプレートには使えない ● jspの単体テストはJUnitすら使えない ○ apache cactus?そんなものもありましたね 46
  47. 47. #ccc_g1 published 断捨離、大切。 47
  48. 48. #ccc_g1 published そもそも”src/main/webapp”がオワコン 48
  49. 49. #ccc_g1 published src/main/webappの存在がオワコン ● クラスパスではないからJUnitから読み込めない ○ 単体テスト自動化を妨げる元凶 ● MVCフレームワークの機能が中途半端だった時代の遺跡 ○ ほとんどのMVC-FWは、”src/main/resources/static” に置 いた静的リソースをそのままレスポンスする機能が既にあ る。 ○ TomcatのDefaultServletの出番はもはや無いのに、それ を使うためのディレクトリ構造を残すの? 49
  50. 50. #ccc_g1 published ├ build.gradle └ src/ ├ main/ │ ├ java/ │ ├ resources/ │ └ webapp/ │ └ WEB-INF/ └ test/ ├ java/ └ resources/ 普通のクラスパス テストのクラスパス ロストテクノロジー置き場 50
  51. 51. #ccc_g1 published 普及する前にオワコン化しそうな “META-INF配下のjsp” ● Servlet3.0仕様的には jspをここに置くこともで きる。 ● Tomcatなら7.0以降で 実装済み src/ ├ main/ │ ├ java/ │ └ resources/ │ └ META-INF/ │ └ foo.jsp 51
  52. 52. #ccc_g1 published 1. 開発環境とCI戦略 2. 老朽化した技術からの脱却 3. フロントエンドと仲良くする 4. 手動テストも、自動テストも。 5. セキュリティ 6. バージョンアップする 52
  53. 53. #ccc_g1 published ちょっと休憩 53 1. 水を飲む 2. 時間を確認 20分?
  54. 54. #ccc_g1 published 1. 開発環境とCI戦略 2. 老朽化した技術からの脱却 3. フロントエンドと仲良くする 4. 手動テストも、自動テストも。 5. セキュリティ 6. バージョンアップする 54
  55. 55. #ccc_g1 published フロントエンド ”技術” と仲良くする 55
  56. 56. #ccc_g1 published ● IDEはもちろんIntelliJ IDEA ○ Java, Scala, TypeScript, JavaScript, Python 全部対応 ● npm + gulp/webpack から yarn + gradle へ 56
  57. 57. #ccc_g1 published ● わざわざgradleからyarnを呼ぶ理由 ○ gradleのほうがなんでも書ける(groovy)わりに、bashより も読みやすい ○ mavenではまず無理 ○ 並列実行ですばやくビルドできる ○ 並列実行対象タスクを任意に設定しやすい ○ Jenkinsfileが短くなる 57
  58. 58. #ccc_g1 published フロントエンド ”エンジニア” と仲良くする 58
  59. 59. #ccc_g1 published Swagger + SpringMVC 大好評 59
  60. 60. #ccc_g1 published 1. 開発環境とCI戦略 2. 老朽化した技術からの脱却 3. フロントエンドと仲良くする 4. 手動テストも、自動テストも。 5. セキュリティ 6. バージョンアップする 60
  61. 61. #ccc_g1 published お約束 61
  62. 62. #ccc_g1 published テストコードに価値はなく、 その実行結果を見たあとの行動に価値がある。 ● 基本 ○ プルリク作る前に手元でテストを実行 ○ プルリクごとにJenkinsが自動テスト ● 理想 ○ 自動テストが失敗したらプルリクの マージボタンが押せない 62
  63. 63. #ccc_g1 published テストの理想と現実 ● 自動化に倒すべきなのは確か ○ JUnit, spring-test, Selenium... ● 「テスト項目表を書いての手動テスト」も 結局は存在し続けるだろう ○ その良し悪しはともかく 63
  64. 64. #ccc_g1 published 「組織にテストを書く文化を根付かせる には年単位の取り組みが必要だ」 ○ これは本当に本当! ○ ゼロから初めて既に2年半が経過 ○ テストコードを根気よく、少しずつ、皆で書く。 64
  65. 65. #ccc_g1 published 65
  66. 66. #ccc_g1 published ● 良い兆候=ビズリーチシステムの現状 ○ 若手のエンジニアが増、ソースコードの絶対量も増。 ○ にも関わらずテストカバレッジ率は下がってない。 むしろジリジリと上がってる。 ○ “@Test”メソッドの数は明らかに増えている ● よくある悪い兆候 ○ テストが書いてあるのに実行されてない。 ○ ソース規模やカバレッジ率が 毎日測定&周知されてない or 不正確。 66
  67. 67. #ccc_g1 published 当面の目標 誰かがコードレビューするとマージ ボタンが活性化 Jenkinsでのテストが一部失 敗している SonarQubeのコーディング ルールチェックはOK テストコードの有無、カバレ ジの低下傾向チェックもやり たい どれか一つでもXならマージボタンを押 せなくしたい! 67
  68. 68. #ccc_g1 published 手動テスト 68
  69. 69. #ccc_g1 published ● あるエンジニアのPC上でなら動く ● 他のエンジニアのPCでも動くけど 準備に時間がかかる ● 検証環境でも動くけど、いま別のチームが テストのために検証環境にデプロイしているのは 別ブランチのコードなのでやっぱり動かない 「動くソフトウェアで進捗を確認せよ」 しかし、なぜ動かないのか?(再掲) 69
  70. 70. #ccc_g1 published ● あるエンジニアのPC上でなら動く ● 他のエンジニアのPCでも動くけど 準備に時間がかかる ● 検証環境でも動くけど、いま別のチームが テストのために検証環境にデプロイしているのは 別ブランチのコードなのでやっぱり動かない 「動くソフトウェアで進捗を確認せよ」 しかし、なぜ動かないのか?(再掲) だから手動テストが面倒くさくなる 70
  71. 71. #ccc_g1 published 歴史を紐解いてみる ● 2001年: アジャイルソフトウェア宣言 ○ 「動くソフトウェアこそが最重要な進捗の尺度だ」 ● 2004年: レガシーコード改善ガイド ○ 「レガシーコードとはテストが無いコードのことだ」 ● 2005年: JUnit4 71
  72. 72. #ccc_g1 published 歴史を紐解いてみる ● 2001年: アジャイルソフトウェア宣言 ○ 「動くソフトウェアこそが最重要な進捗の尺度だ」 ● 2004年: レガシーコード改善ガイド ○ 「レガシーコードとはテストが無いコードのことだ」 ● 2005年: JUnit4 ● この頃無かったもの ○ 分散VCS(git), AWS-EC2, IaaC, Docker 72
  73. 73. #ccc_g1 published 2000年代前半に書かれたバイブルを片手に 2018年の”Cloud Native”の世界を生きる? 73
  74. 74. #ccc_g1 published 分散VCS, コンテナ, IaaC時代の手動テスト(案) 1. プルリクエスト毎にそれ専用の検証環境が 自動構築される 2. pushされる都度mergedな状態のコードで 1の環境にビルド&デプロイされる 3. そのプルリクに対するテストをいつでも誰でもできる a. エンジニア、デザイナー b. 社内の手すきの人員? c. クラウドソーシング? まだ出来てませんが、 目指すところです。 74
  75. 75. #ccc_g1 published ちょっと休憩 75 1. 水を飲む 2. 時間を確認 35-40分?
  76. 76. #ccc_g1 published 1. 開発環境とCI戦略 2. 老朽化した技術からの脱却 3. フロントエンドと仲良くする 4. 手動テストも、自動テストも。 5. セキュリティ 6. バージョンアップする 76
  77. 77. #ccc_g1 published ● AWS-S3のバケットがうっかりpublic設定 ● パスワードを平文でログ出力 ● 割賦販売法改正, PCI-DSS…? ● AWSのシークレットキーを ソースコードに埋め込んだままn年変えてない ● JRE/ライブラリ/フレームワークで 脆弱性報告からのバージョンアップ祭り 77
  78. 78. #ccc_g1 published AWSのシークレットキーをソースコードに 埋め込んだままn年変えてない問題 ※ビズリーチではこれから説明する内容で解決済みです 78
  79. 79. #ccc_g1 published ● シークレットキーをローテーションするというより、 ローテーションしやすくするのがポイント ● AWSに限らない。Twilioのアクセスキー, OAuth2 プロバイダのclient-secretも。 79
  80. 80. #ccc_g1 published ● ベストなのはOS環境変数 ● キーを変えたくなってもソースコードを変更する必 要をなくす。 ● OS環境変数を変更してアプリケーションを再起動 するだけ。 ● OS環境変数をどう管理するかは別途 ○ Hashicorp Vault, AWSパラメータストア アプリケーションの外から差し替え可能にする 80
  81. 81. #ccc_g1 published それ、Spring3.1 (2011年)から普通にできるよ! $ export FOO_KEY=HOGE $ java -jar application.jar @Component public class FooBean { @Value("${foo.key}") private String key; 1. FOO_KEY は foo.key プロパティに 当てられる 2. 変数 “key” に “HOGE” が入る See: SystemEnvironmentPropertySource.java 81
  82. 82. #ccc_g1 published 考え方 ● 設定値の外部化は、セキュリティ確保とテスト容易性の両方に 関係する ○ 「プルリクエストの数と同じだけの開発環境がある」をお忘 れなく ● デプロイ先の環境に合わせてビルドしなおしたら負け 82
  83. 83. #ccc_g1 published JRE/ライブラリ/フレームワークで 脆弱性報告からのバージョンアップ祭り 83
  84. 84. #ccc_g1 published xxxxxというJavaライブラリに脆弱性が発見されました 深刻度: important CVE-2018-xxx….. 84
  85. 85. #ccc_g1 published たとえばlogbackの脆弱性 ● logback1.2.0未満にはシリアライゼーション機構に脆弱性が ある ● SocketServer と ServerSocketReciever 要するにソケット通 信でログを中継する機能を使ってる場合は危険 ● 逆にいうとそれを使っていなければ大丈夫そうだね 85
  86. 86. #ccc_g1 published たとえばJREの脆弱性 ● JavaWebStartのサンドボックス機構が破られる脆弱性 ● JavaWebStart使ってるのJenkinsしか見たことないよ 86
  87. 87. #ccc_g1 published たとえばTomcatの脆弱性 @WebServlet (name = "Root", urlPatterns = { "/" }) @ServletSecurity( value=@HttpConstraint(rolesAllowed={"admin"}) ) public class HelloServlet extends HttpServlet { 最後に自前でサーブレットクラスを書いたのは いつだっけ?(遠い目) 87
  88. 88. #ccc_g1 published ● ウチでは使ってない機能の脆弱性だから 今のバージョンのままでいい ● そんな対応を続けると、どうなるか? 88
  89. 89. #ccc_g1 published 1.0.1 いま使っているバージョン 1.0.2 自分は使ってない機能での脆弱性Aに 対応したバージョン 1.1.0 便利な機能が増えましたバージョン 1.1.1 バグを直したバージョン ここで危険な脆弱性Bが発見される 1.1.2 脆弱性Bに対応したバージョン 89
  90. 90. #ccc_g1 published 1. 脆弱性Bはやばい!xxxライブラリを1.1.2まで バージョンアップしよう! 2. あれ?アプリケーションが 動かなくなった...だと?! 3. 1.1.0 の段階で自分たちが使っている メソッドの仕様が変更されてました。 「リリースノートやChangeLogに 全てが書いてあるなんて誰が言った?」 4. 詰んだ!\(^o^)/ 90
  91. 91. #ccc_g1 published 1. xxxライブラリのAという機能に脆弱性が 発見されたけど自分たちは使ってないから 問題ない 2. (半年後)新しい画面の開発のために xxxライブラリのAを活用しました(ドヤ顔) 91
  92. 92. #ccc_g1 published ❏ セキュリティに100%は無い。 ❏ サービス/開発の利便性とセキュリティを 両立させる有効な手段? ❏ 自分のプロダクトでの影響範囲を見極める ❏ 一発で大きくバージョンアップ ❏ 複数回に分けて小さくバージョンアップ 92
  93. 93. #ccc_g1 published 1. 開発環境とCI戦略 2. 老朽化した技術からの脱却 3. フロントエンドと仲良くする 4. 手動テストも、自動テストも。 5. セキュリティ 6. バージョンアップする 93
  94. 94. #ccc_g1 published ライブラリ/フレームワークを バージョンアップする理由 1. セキュリティ的な理由で上げることになる。 Webサービスを開発している場合は特に。 2. そもそも、新しいバージョンの方が便利なんだから ありがたく乗って、作り続ける。 94
  95. 95. #ccc_g1 published ビズリーチシステムでは ● Java6 -> Java8 ● Spring 3.0 -> 3.2 -> 4.0 -> 4.1 -> 4.2 -> 4.3 -> 5.0 ● Tomcat6(インストール方式) -> tomcat-embed-8.5 ● Maven -> Gradle ○ Mavenの基本は「先勝ち」でjarが入ってくるため 意図せず古いor新しいjarが使われることがある ○ Gradleではデフォルト”Newest” 95
  96. 96. #ccc_g1 published ❏ サービス/開発の利便性とセキュリティを 両立させる有効な手段? ❏ 自分のプロダクトでの脆弱性の影響範囲を見 極める ❏ 一発で大きくバージョンアップ ❏ 複数回に分けて小さくバージョンアップ 96
  97. 97. #ccc_g1 published 絶え間ないバージョンアップを支えてくれたもの 少しずつ書き溜めた自動テスト ● ビジネスロジックに対するJUnit ● Model, View, Controller の各レイヤー毎に わざとバラして書いたJUnit ● Seleniumテスト ○ メンテ工数大なので最小限 97
  98. 98. #ccc_g1 published 1. 開発環境とCI戦略 2. 老朽化した技術からの脱却 3. フロントエンドと仲良くする 4. 手動テストも、自動テストも。 5. セキュリティ 6. バージョンアップする 98 おっ、すべて語りきれたかな? 1. 水を飲む 2. 時間を確認 あと何分?
  99. 99. #ccc_g1 published 99 開発環境、CI、テスト、フロントエンド、 セキュリティ、絶え間ないバージョンアップ... これらすべてを支える最後の一手とは?
  100. 100. #ccc_g1 published ソフトウェアプロジェクトの世界では、その技術においても管理手 法においても、生産性、信頼性、容易性の飛躍的な改善を約束す る特効薬のような、 銀の弾丸など無い。 “No Silver Bullet” フレデリック・ブルックス 1987 “The Computer” IEEE 100
  101. 101. #ccc_g1 published 金の弾丸は実在する。 匿名エンジニア 2018 “The Twitter” 101
  102. 102. #ccc_g1 published 102 Mac Book Pro 3GHz Core i7 16GB memory 250GB SSD Jet Brains All Products Pack ビズリーチのエンジニアとデザイナーの基本装備
  103. 103. #ccc_g1 published 「マシンパワーがエンジニアの能力を 最大限に引き出せてない事象が 発生している」 by CTO 103
  104. 104. #ccc_g1 published 104 iMac Pro 136台 Xeon 8コア メモリ 32G
  105. 105. #ccc_g1 published ノートパソコンじゃないと、 会議室に持っていけないから 不便じゃね? (とあるツイートより) 105
  106. 106. #ccc_g1 published A. MacBook Pro + 外付けディスプレイ B. iMac Pro + MacBook (Proじゃないやつ) 106 好きなほうを選べ。ってことになってます
  107. 107. #ccc_g1 published 107
  108. 108. #ccc_g1 published エンジニアの感想 ● IntelliJ が vim のようにスムーズに...動くぞ! ● sbt(scalaのビルド), webpack, XCodeビルドを同時に動かし てもへっちゃら! 108
  109. 109. #ccc_g1 published まとめ 109 1. 時間を確認
  110. 110. #ccc_g1 published 作るのではなく、作り続けるために ● ビッグリライト ● リファクタリング 110
  111. 111. #ccc_g1 published リファクタリングとは(若干のこじつけあり) ● オワコンは乗り換えるしかない ● ゴミは断捨離するしかない ● 新しい息吹を吹き込む ○ フロントエンド技術、Python... ● 遅くなってしまったものを速くする ○ Maven -> Gradle ● CIまで含めて管理しやすくする ○ Jenkins2 と Jenkinsfile 111
  112. 112. #ccc_g1 published リファクタリングを支えるもの ● setup.sh 一発で準備できるローカル開発環境 ● 基本FW/ライブラリのこまめなバージョンアップ ● 自動テストコード ● いつでも誰でも確実に手動テストできる環境 ○ プルリクエストひとつに対して 検証環境ひとつ(を目指してます) 112
  113. 113. #ccc_g1 published 簡単かつ確実にセキュリティを維持する基本は ● 「シークレット」「キー」と名のつく設定値を OS環境変数で書き換えられるようにしておく ○ 検証環境がn個ある状態に耐えられるように なる副次効果あり ● こまめなバージョンアップ ○ 巷の脆弱性情報の影響範囲を見極めたところで ちょっとした時間稼ぎにしかならない 113
  114. 114. #ccc_g1 published こまめなバージョンアップを支えるものは ● 自動テストコード ● 多種類の技術を束ねて並列高速ビルドするGradle ● 自動テストを確実に実行するCIサーバ群 114
  115. 115. #ccc_g1 published 目指す世界線は? ● プルリクエストひとつに対してその動作検証環境が ひとつ、自動的に構築される世界。 ○ 誰でも、いつでも、安定的に、再現性高めに、 テスト=要求と実際の動作を比較する=を 可能にする世界。 115
  116. 116. #ccc_g1 published 目指す世界線のための布石は? ● IaaCとコンテナ技術の知見を身につけておく ○ ローカル開発環境でDockerを使ってみる ○ vagrant, docker, setup.shの存在理由が “ローカル開発環境構築手順書” (A4 15枚) の代替だけだと思ってると、もったいない。 116
  117. 117. #ccc_g1 published JJUG-CCC-2014 Fall 「JavaでやってみるThe Twelve Factor App」 Y.Watanabe JJUG-CCC-2015 Fall 「Java8移行から始まる技術的負債との戦い」 Daisuke.Sei JJUG-CCC-2016 Spring 「テストゼロからイチに進むための戦略と戦術」 Y.Watanabe JJUG-CCC-2018 Spring 「JavaでWebサービスを作り続けるための戦略と戦術」 Y.Watanabe 117
  118. 118. #ccc_g1 published 118
  119. 119. #ccc_g1 published この講演で語ったことのうち、自分一人だけで 思いついたことも成せたことも、何ひとつありません。 チームの同僚が助けてくれてこそのことです。 あらためて、同僚に感謝します。 助けてくれて、ありがとう。 119
  120. 120. #ccc_g1 published 120 ビズリーチでは エンジニアを募集しています

×