JavaでWebサービスを作り続けるための戦略と戦術

#ccc_g1 JavaでWebサービスを作り続けるための 戦略と戦術 JJUG-CCC 2018 Spring ベルサール新宿 2018-05-26 Y. Watanabe published

#ccc_g1 ストップウォッチスタート確認 published 2

#ccc_g1 published 3

#ccc_g1 Webサービスを止めずに Webサービスを進化させ続けるには？ published 4

Who? #ccc_g1 ● 渡辺 祐 ● (株)ビズリーチ ● SREグループ ○ Site Reliability Engeneering ● twitter: @nabedge published 5

#ccc_g1 ビズリーチシステムとは ● 創業事業かつ主力事業 2009〜 ● 社内でもっとも古くから稼働している Javaアプリケーション群 published 6

#ccc_g1 1. 2. 3. 4. 5. 6. published 開発環境とCI戦略 老朽化した技術からの脱却 フロントエンドと仲良くする 手動テストも、自動テストも。 セキュリティ バージョンアップする 7

#ccc_g1 1. 2. 3. 4. 5. 6. published 開発環境とCI戦略 老朽化した技術からの脱却 フロントエンドと仲良くする 手動テストも、自動テストも。 セキュリティ バージョンアップする 8

#ccc_g1 Q. 開発環境とは？ A. そこでアプリケーションが動く けど、それは本番用ではないモノ すべてを指す PCだけ？エンジニアだけ？ published 9

#ccc_g1 10 「動くソフトウェアこそが 進捗の最も重要な尺度」 アジャイルソフトウェア開発宣言より published

#ccc_g1 11 逆に、なぜ ”動かない” のか？ ● あるエンジニアのPCでなら動く ● 他のエンジニアのPCでも動くけど 準備に時間がかかる ● 検証環境でも動くけど、いま別のチームが テストのために検証環境にデプロイしているのは 別ブランチのコードなのでやっぱり動かない published

#ccc_g1 あるべき姿（ローカル開発環境編） 1. sh ./setup.sh でミドルウェアは全部入る 2. データ層へのテストデータ投入も 1に含まれている 3. システムAのローカル開発環境は システムBのそれと干渉しない published 12

#ccc_g1 仮想OS on 仮想OS Mac OS OracleVirtualBox CentOS Docker (MySQL) CentOS Docker (Redis) 172.16.1.1 Aサービス のコード setup.sh published Docker (PgSQL) Docker (fakes3) 172.16.2.2 Bサービス のコード setup.sh 13

#ccc_g1 あえて生dockerを使わなかった理由 ● “その当時は”、Docker for Macが不安定だった ● mysqlはlocalhost:3306だと他の環境とバッティング ○ ex. 新人君が本を写経しようとして... published 14

#ccc_g1 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するスクリプト published 15

#ccc_g1 16 逆に、なぜ動かないのか？（再掲） ● あるエンジニアのPCでなら動く ● 他のエンジニアのPCでも動くけど 準備に時間がかかる ● 検証環境でも動くけど、いま別のチームが テストのために検証環境にデプロイしているのは 別ブランチのコードなのでやっぱり動かない published

#ccc_g1 Docker利用は将来構想に向けての布石でもある ● いま、ローカル開発環境用に作っている Dockerfileをそのまま検証環境、本番環境で 使えれば使いたい。使えるように書きたい。 ● 少なくともDockerに関する知見を エンジニアが蓄積できる ● Dockerfileのメンテナはアプリケーションエンジニア。 published 17

#ccc_g1 Eclipse -> IntelliJ IDEA 1. ライブラリプロジェクト、アプリケーションプロジェクトの絶対数 が増 a. フラットなプロジェクトレイアウトが前提のEclipseだと何かと不都合 2. Python, TypeScript, Android Java... 3. Scalaのチームもいる 4. 全社の全エンジニアまとめてIntelliJ published 18

#ccc_g1 19 Maven -> Gradle ● ライブラリプロジェクト、アプリケーションプロジェクトの絶対数 の増加 ● CPUのコア数に合わせて並列ビルドできるほうが有利 ● フロントエンドのビルドツールもろともgradleから制御したい ● pom.xmlよりもbuild.gradleのほうが自由度が高いわりに読み やすい published

#ccc_g1 Jenkins1から2へ。そしてJenkinsfileへ ● Maven -> Gradle移行の過程でjenkinsジョブの 調整コストが増 ● 全ソース, build.gradle, Jenkinsfile まで含め git管理するだけで楽勝。 ● っていうのを見越してまず先にJenkins2に バージョンアップしていた published 20

#ccc_g1 次に目指しているところ（構想） 1. プルリクエストひとつに対して それ専用の検証環境がひとつ自動構築される 2. pushされる都度mergedな状態のコードで 1の環境にビルド＆デプロイされる 3. 非エンジニアが会議室のプロジェクタで 動くソフトウェアをいつでも確認できる published 21

#ccc_g1 22 逆に、なぜ動かないのか？（再掲） ● あるエンジニアのPCでなら動く ● 他のエンジニアのPCでも動くけど 準備に時間がかかる ● 検証環境でも動くけど、いま別のチームが テストのために検証環境にデプロイしているのは 別ブランチのコードなのでやっぱり動かない published

#ccc_g1 以下は、その実現方法論にすぎない ● イミュータブルインフラストラクチャ ● Blue/Greenデプロイメント ● 12-Factor App published 23

#ccc_g1 1. 2. 3. 4. 5. 6. published 開発環境とCI戦略 老朽化した技術からの脱却 フロントエンドと仲良くする 手動テストも、自動テストも。 セキュリティ バージョンアップする 24

#ccc_g1 インストール型Tomcatはオワコン published 25

#ccc_g1 ● tomcat（インストール前提）をどうやって 起動してますか？ ○ maven-tomcat-plugin ? ○ WTP? ○ sysdeo plugin? published 26

#ccc_g1 ● “public static void main”ならIDEだろうと サーバ上のCLIだろうと、どうにでも動かせる public class AppStarter { public static void main(String args[] argv) { Tomcat tomcat = new Tomcat(); tomcat.start(); published 27

#ccc_g1 Tomcatとは、インストールするものではなく、 new するもの。 参照：JJUG-CCC-2014 Fall 「JavaでやってみるThe Twelve Factor App」 published 28

#ccc_g1 JasperReportsはオワコン published 29

#ccc_g1 JasperReportはオワコン ● PDF出力ライブラリ ● Java8だとデザインツールが事実上動かない ○ (2016年当時です。今は知らない） ● 全体のJava8化を阻害する意外なボトルネックだった ● flying-soucer-pdf でPDF関連機能を全部作り直し published 30

#ccc_g1 ポイントはJasperReportの話ではなくて... published 31

#ccc_g1 “JSESSIONID”はオワコン published 32

#ccc_g1 “JSESSIONID”はオワコン ● サブシステムAは http://localhost:8001/ ● サブシステムBは http://localhost:8002/ ● 両方ともセッションCookie名が ”JSESSIONID” ● ローカル開発環境でA, B同時に起動すると 片方でしかログイン状態を保てない ● エンジニアの生産性低下 published 33

• http://localhost:9001/

#ccc_g1 意外と知らない人がいるから念のため Tomcatで言えば6.0.28 (2010年)から実装済み <!-- web.xmlの場合 --> <session-config> <cookie-config> <name>MY_HOGE_SESSIONID</name> </cookie-config> </session-config> published 34

#ccc_g1 35 // 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); published

#ccc_g1 でもなあ、セッションクッキー名が ”JSESSIONID”ではなくなります！って言うと、 L7ロードバランサのスティッキーセッションcookieも 設定変更しなきゃいけなくなって、 インフラ担当チームと調整しなきゃなんだよなあ。 published 36

#ccc_g1 sticky-session-cookieもオワコン JSESSIONID=abc123.1 1号機JVM セッション ALB 2号機JVM published 37

#ccc_g1 sticky-session-cookieもオワコン ● ● ● ● APサーバ2台の冗長構成だとして リリースのときは1台ずつ止めてデプロイ リリース中は片系統にアクセス集中 リリース後も片系統にアクセス集中したまま (sticky-session-cookieとはそういうもの） ● 同時利用ユーザー数が増えると... !! published 38

#ccc_g1 sticky-session-cookieもオワコン ● spring-session-redis のフィルタをかぶせるだけで、 javax.servlet.http.HttpSessionの取り回しをラッピング 1号機JVM Redis ALB 2号機JVM published セッション 39

#ccc_g1 ● L7ロードバランサ、お払い箱説。 ● WAF的な機能は残るかもですが。 published 40

#ccc_g1 セッションストアが JVMヒープでは無いということは？ SerializationFailedExceptionを起こしやすくなる published 41

#ccc_g1 “設定ファイル.xml”はオワコン published 42

#ccc_g1 “設定ファイル.xml”はオワコン ● xmlは修正ポイントがわかりにくい ● JavaConfigならIDEで補完が効くのでミスりにくい ● JavaConfigはif文、switch文なんでもOKで小回りが利く ○ 環境差分に対処しやすくなる ■ 環境が無数にある場合に便利 ■ さっき、プルリクエスト毎に専用環境が...って話 published 43

#ccc_g1

おすすめの「JavaConfigはじめかた」
xmlファイルにほんの数行だけ残しておく
<beans xmlns:context="http://www.springframework.org/schema/context">
<context:component-scan base-package="jp.bizreach.foo"/>
</beans>
package jp.bizreach.foo
@Configuration
public BarConfig {
@Bean
public HogeService hogeService() {...}
}
published

44

#ccc_g1 jspはオワコン published 45

#ccc_g1 jspはオワコン ● 今さら自作カスタムタグのメンテだるい。 ● リファクタリングしづらくてゴミになりがち ● メールのテンプレートには使えない ● jspの単体テストはJUnitすら使えない ○ apache cactus?そんなものもありましたね published 46

#ccc_g1 断捨離、大切。 published 47

#ccc_g1 そもそも”src/main/webapp”がオワコン published 48

src/main/webappの存在がオワコン #ccc_g1 49 ● クラスパスではないからJUnitから読み込めない ○ 単体テスト自動化を妨げる元凶 ● MVCフレームワークの機能が中途半端だった時代の遺跡 ○ ほとんどのMVC-FWは、”src/main/resources/static” に置 いた静的リソースをそのままレスポンスする機能が既にあ る。 ○ TomcatのDefaultServletの出番はもはや無いのに、それ を使うためのディレクトリ構造を残すの？ published

#ccc_g1 ├ build.gradle └ src/ ├ main/ │ ├ java/ │ ├ resources/ │ └ webapp/ │ └ WEB-INF/ └ test/ ├ java/ └ resources/ published 普通のクラスパス ロストテクノロジー置き場 テストのクラスパス 50

#ccc_g1 51 普及する前にオワコン化しそうな “META-INF配下のjsp” src/ ├ main/ │ ├ java/ │ └ resources/ │ └ META-INF/ │ └ foo.jsp published ● Servlet3.0仕様的には jspをここに置くこともで きる。 ● Tomcatなら7.0以降で 実装済み

#ccc_g1 1. 2. 3. 4. 5. 6. published 開発環境とCI戦略 老朽化した技術からの脱却 フロントエンドと仲良くする 手動テストも、自動テストも。 セキュリティ バージョンアップする 52

#ccc_g1 ちょっと休憩 1. 水を飲む 2. 時間を確認 20分？ published 53

#ccc_g1 1. 2. 3. 4. 5. 6. published 開発環境とCI戦略 老朽化した技術からの脱却 フロントエンドと仲良くする 手動テストも、自動テストも。 セキュリティ バージョンアップする 54

#ccc_g1 フロントエンド ”技術” と仲良くする published 55

#ccc_g1 ● IDEはもちろんIntelliJ IDEA ○ Java, Scala, TypeScript, JavaScript, Python 全部対応 ● npm + gulp/webpack から yarn + gradle へ published 56

#ccc_g1 ● わざわざgradleからyarnを呼ぶ理由 ○ gradleのほうがなんでも書ける(groovy)わりに、bashより も読みやすい ○ mavenではまず無理 ○ 並列実行ですばやくビルドできる ○ 並列実行対象タスクを任意に設定しやすい ○ Jenkinsfileが短くなる published 57

#ccc_g1 フロントエンド ”エンジニア” と仲良くする published 58

#ccc_g1 Swagger + SpringMVC 大好評 published 59

#ccc_g1 1. 2. 3. 4. 5. 6. published 開発環境とCI戦略 老朽化した技術からの脱却 フロントエンドと仲良くする 手動テストも、自動テストも。 セキュリティ バージョンアップする 60

#ccc_g1 お約束 published 61

#ccc_g1 テストコードに価値はなく、 その実行結果を見たあとの行動に価値がある。 ● 基本 ○ プルリク作る前に手元でテストを実行 ○ プルリクごとにJenkinsが自動テスト ● 理想 ○ 自動テストが失敗したらプルリクの マージボタンが押せない published 62

#ccc_g1 テストの理想と現実 ● 自動化に倒すべきなのは確か ○ JUnit, spring-test, Selenium... ● 「テスト項目表を書いての手動テスト」も 結局は存在し続けるだろう ○ その良し悪しはともかく published 63

#ccc_g1 「組織にテストを書く文化を根付かせる には年単位の取り組みが必要だ」 ○ これは本当に本当！ ○ ゼロから初めて既に2年半が経過 ○ テストコードを根気よく、少しずつ、皆で書く。 published 64

#ccc_g1 published 65

#ccc_g1 ● 良い兆候＝ビズリーチシステムの現状 ○ 若手のエンジニアが増、ソースコードの絶対量も増。 ○ にも関わらずテストカバレッジ率は下がってない。 むしろジリジリと上がってる。 ○ “@Test”メソッドの数は明らかに増えている ● よくある悪い兆候 ○ テストが書いてあるのに実行されてない。 ○ ソース規模やカバレッジ率が 毎日測定＆周知されてない or 不正確。 published 66

#ccc_g1 当面の目標 誰かがコードレビューするとマージ ボタンが活性化 67 Jenkinsでのテストが一部失 敗している SonarQubeのコーディング ルールチェックはOK テストコードの有無、カバレ ジの低下傾向チェックもやり たい どれか一つでもXならマージボタンを押 せなくしたい！ published

#ccc_g1 手動テスト published 68

#ccc_g1 「動くソフトウェアで進捗を確認せよ」 しかし、なぜ動かないのか？（再掲） ● あるエンジニアのPC上でなら動く ● 他のエンジニアのPCでも動くけど 準備に時間がかかる ● 検証環境でも動くけど、いま別のチームが テストのために検証環境にデプロイしているのは 別ブランチのコードなのでやっぱり動かない published 69

#ccc_g1 「動くソフトウェアで進捗を確認せよ」 しかし、なぜ動かないのか？（再掲） ● あるエンジニアのPC上でなら動く ● 他のエンジニアのPCでも動くけど 準備に時間がかかる だから手動テストが面倒くさくなる ● 検証環境でも動くけど、いま別のチームが テストのために検証環境にデプロイしているのは 別ブランチのコードなのでやっぱり動かない published 70

#ccc_g1 歴史を紐解いてみる ● 2001年: アジャイルソフトウェア宣言 ○ 「動くソフトウェアこそが最重要な進捗の尺度だ」 ● 2004年: レガシーコード改善ガイド ○ 「レガシーコードとはテストが無いコードのことだ」 ● 2005年: JUnit4 published 71

#ccc_g1 歴史を紐解いてみる ● 2001年: アジャイルソフトウェア宣言 ○ 「動くソフトウェアこそが最重要な進捗の尺度だ」 ● 2004年: レガシーコード改善ガイド ○ 「レガシーコードとはテストが無いコードのことだ」 ● 2005年: JUnit4 ● この頃無かったもの ○ 分散VCS(git), AWS-EC2, IaaC, Docker published 72

#ccc_g1 2000年代前半に書かれたバイブルを片手に 2018年の”Cloud Native”の世界を生きる？ published 73

#ccc_g1 分散VCS, コンテナ, IaaC時代の手動テスト（案） 1. プルリクエスト毎にそれ専用の検証環境が 自動構築される 2. pushされる都度mergedな状態のコードで 1の環境にビルド＆デプロイされる 3. そのプルリクに対するテストをいつでも誰でもできる a. エンジニア、デザイナー b. 社内の手すきの人員？ まだ出来てませんが、 c. クラウドソーシング？ 目指すところです。 published 74

#ccc_g1 ちょっと休憩 1. 水を飲む 2. 時間を確認 35-40分？ published 75

#ccc_g1 1. 2. 3. 4. 5. 6. published 開発環境とCI戦略 老朽化した技術からの脱却 フロントエンドと仲良くする 手動テストも、自動テストも。 セキュリティ バージョンアップする 76

#ccc_g1 ● ● ● ● AWS-S3のバケットがうっかりpublic設定 パスワードを平文でログ出力 割賦販売法改正, PCI-DSS…? AWSのシークレットキーを ソースコードに埋め込んだままn年変えてない ● JRE/ライブラリ/フレームワークで 脆弱性報告からのバージョンアップ祭り published 77

#ccc_g1 AWSのシークレットキーをソースコードに 埋め込んだままn年変えてない問題 ※ビズリーチではこれから説明する内容で解決済みです published 78

#ccc_g1 79 ● シークレットキーをローテーションするというより、 ローテーションしやすくするのがポイント ● AWSに限らない。Twilioのアクセスキー, OAuth2 プロバイダのclient-secretも。 published

#ccc_g1 80 アプリケーションの外から差し替え可能にする ● ベストなのはOS環境変数 ● キーを変えたくなってもソースコードを変更する必 要をなくす。 ● OS環境変数を変更してアプリケーションを再起動 するだけ。 ● OS環境変数をどう管理するかは別途 ○ Hashicorp Vault, AWSパラメータストア published

#ccc_g1

それ、Spring3.1 (2011年)から普通にできるよ！
$ export FOO_KEY=HOGE
$ java -jar application.jar
@Component
public class FooBean {

1. FOO_KEY は
foo.key プロパティに
当てられる
2. 変数 “key” に
“HOGE” が入る

@Value("${foo.key}")
private String key;
published

See: SystemEnvironmentPropertySource.java

81

#ccc_g1 82 考え方 ● 設定値の外部化は、セキュリティ確保とテスト容易性の両方に 関係する ○ 「プルリクエストの数と同じだけの開発環境がある」をお忘 れなく ● デプロイ先の環境に合わせてビルドしなおしたら負け published

#ccc_g1 JRE/ライブラリ/フレームワークで 脆弱性報告からのバージョンアップ祭り published 83

#ccc_g1 xxxxxというJavaライブラリに脆弱性が発見されました 深刻度: important CVE-2018-xxx….. published 84

#ccc_g1 85 たとえばlogbackの脆弱性 ● logback1.2.0未満にはシリアライゼーション機構に脆弱性が ある ● SocketServer と ServerSocketReciever 要するにソケット通 信でログを中継する機能を使ってる場合は危険 ● 逆にいうとそれを使っていなければ大丈夫そうだね published

#ccc_g1 たとえばJREの脆弱性 ● JavaWebStartのサンドボックス機構が破られる脆弱性 ● JavaWebStart使ってるのJenkinsしか見たことないよ published 86

#ccc_g1 87 たとえばTomcatの脆弱性 @WebServlet (name = "Root", urlPatterns = { "/" }) @ServletSecurity( value=@HttpConstraint(rolesAllowed={"admin"}) ) public class HelloServlet extends HttpServlet { 最後に自前でサーブレットクラスを書いたのは いつだっけ?（遠い目） published

#ccc_g1 ● ウチでは使ってない機能の脆弱性だから 今のバージョンのままでいい ● そんな対応を続けると、どうなるか？ published 88

#ccc_g1 1.0.1 いま使っているバージョン 1.0.2 自分は使ってない機能での脆弱性Aに 対応したバージョン 1.1.0 便利な機能が増えましたバージョン 1.1.1 バグを直したバージョン ここで危険な脆弱性Bが発見される 1.1.2 published 脆弱性Bに対応したバージョン 89

#ccc_g1 1. 脆弱性Bはやばい！xxxライブラリを1.1.2まで バージョンアップしよう！ 2. あれ？アプリケーションが 動かなくなった...だと？！ 3. 1.1.0 の段階で自分たちが使っている メソッドの仕様が変更されてました。 「リリースノートやChangeLogに 全てが書いてあるなんて誰が言った？」 4. 詰んだ！＼(^o^)／ published 90

#ccc_g1 1. xxxライブラリのAという機能に脆弱性が 発見されたけど自分たちは使ってないから 問題ない 2. （半年後）新しい画面の開発のために xxxライブラリのAを活用しました（ドヤ顔） published 91

#ccc_g1 ❏ セキュリティに100%は無い。 ❏ サービス/開発の利便性とセキュリティを 両立させる有効な手段？ ❏ 自分のプロダクトでの影響範囲を見極める ❏ 一発で大きくバージョンアップ ❏ 複数回に分けて小さくバージョンアップ published 92

#ccc_g1 1. 2. 3. 4. 5. 6. published 開発環境とCI戦略 老朽化した技術からの脱却 フロントエンドと仲良くする 手動テストも、自動テストも。 セキュリティ バージョンアップする 93

#ccc_g1 ライブラリ/フレームワークを バージョンアップする理由 1. セキュリティ的な理由で上げることになる。 Webサービスを開発している場合は特に。 2. そもそも、新しいバージョンの方が便利なんだから ありがたく乗って、作り続ける。 published 94

#ccc_g1 ビズリーチシステムでは ● 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が使われることがある ○ published Gradleではデフォルト”Newest” 95

#ccc_g1 ❏ サービス/開発の利便性とセキュリティを 両立させる有効な手段？ ❏ 自分のプロダクトでの脆弱性の影響範囲を見 極める ❏ 一発で大きくバージョンアップ ❏ 複数回に分けて小さくバージョンアップ published 96

#ccc_g1 絶え間ないバージョンアップを支えてくれたもの 少しずつ書き溜めた自動テスト ● ビジネスロジックに対するJUnit ● Model, View, Controller の各レイヤー毎に わざとバラして書いたJUnit ● Seleniumテスト ○ メンテ工数大なので最小限 published 97

#ccc_g1 おっ、すべて語りきれたかな？ 1. 水を飲む 2. 時間を確認 あと何分？ published 1. 2. 3. 4. 5. 6. 開発環境とCI戦略 老朽化した技術からの脱却 フロントエンドと仲良くする 手動テストも、自動テストも。 セキュリティ バージョンアップする 98

#ccc_g1 開発環境、CI、テスト、フロントエンド、 セキュリティ、絶え間ないバージョンアップ... これらすべてを支える最後の一手とは？ published 99

#ccc_g1 100 ソフトウェアプロジェクトの世界では、その技術においても管理手 法においても、生産性、信頼性、容易性の飛躍的な改善を約束す る特効薬のような、 銀の弾丸など無い。 “No Silver Bullet” フレデリック・ブルックス 1987 “The Computer” IEEE published

#ccc_g1 金の弾丸は実在する。 匿名エンジニア 2018 “The Twitter” published 101

#ccc_g1 ビズリーチのエンジニアとデザイナーの基本装備 Mac Book Pro 3GHz Core i7 16GB memory 250GB SSD Jet Brains All Products Pack published 102

#ccc_g1 「マシンパワーがエンジニアの能力を 最大限に引き出せてない事象が 発生している」 by CTO published 103

#ccc_g1 104 iMac Pro 136台 Xeon 8コア メモリ 32G published

#ccc_g1 ノートパソコンじゃないと、 会議室に持っていけないから 不便じゃね？ （とあるツイートより） published 105

#ccc_g1 好きなほうを選べ。ってことになってます A. MacBook Pro + 外付けディスプレイ B. iMac Pro + MacBook (Proじゃないやつ) published 106

#ccc_g1 published 107

#ccc_g1 108 エンジニアの感想 ● IntelliJ が vim のようにスムーズに...動くぞ！ ● sbt(scalaのビルド), webpack, XCodeビルドを同時に動かし てもへっちゃら！ published

#ccc_g1 まとめ 1. 時間を確認 published 109

#ccc_g1 作るのではなく、作り続けるために ● ビッグリライト ● リファクタリング published 110

#ccc_g1 リファクタリングとは（若干のこじつけあり） ● オワコンは乗り換えるしかない ● ゴミは断捨離するしかない ● 新しい息吹を吹き込む ○ フロントエンド技術、Python... ● 遅くなってしまったものを速くする ○ Maven -> Gradle ● CIまで含めて管理しやすくする ○ Jenkins2 と Jenkinsfile published 111

#ccc_g1 リファクタリングを支えるもの ● setup.sh 一発で準備できるローカル開発環境 ● 基本FW/ライブラリのこまめなバージョンアップ ● 自動テストコード ● いつでも誰でも確実に手動テストできる環境 ○ プルリクエストひとつに対して 検証環境ひとつ（を目指してます） published 112

#ccc_g1 簡単かつ確実にセキュリティを維持する基本は ● 「シークレット」「キー」と名のつく設定値を OS環境変数で書き換えられるようにしておく ○ 検証環境がn個ある状態に耐えられるように なる副次効果あり ● こまめなバージョンアップ ○ 巷の脆弱性情報の影響範囲を見極めたところで ちょっとした時間稼ぎにしかならない published 113

#ccc_g1 こまめなバージョンアップを支えるものは ● 自動テストコード ● 多種類の技術を束ねて並列高速ビルドするGradle ● 自動テストを確実に実行するCIサーバ群 published 114

#ccc_g1 目指す世界線は？ ● プルリクエストひとつに対してその動作検証環境が ひとつ、自動的に構築される世界。 ○ 誰でも、いつでも、安定的に、再現性高めに、 テスト＝要求と実際の動作を比較する＝を 可能にする世界。 published 115

#ccc_g1 目指す世界線のための布石は？ ● IaaCとコンテナ技術の知見を身につけておく ○ ローカル開発環境でDockerを使ってみる ○ vagrant, docker, setup.shの存在理由が “ローカル開発環境構築手順書” (A4 15枚) の代替だけだと思ってると、もったいない。 published 116

#ccc_g1 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 published 117

#ccc_g1 published 118

#ccc_g1 この講演で語ったことのうち、自分一人だけで 思いついたことも成せたことも、何ひとつありません。 チームの同僚が助けてくれてこそのことです。 あらためて、同僚に感謝します。 助けてくれて、ありがとう。 published 119

#ccc_g1 ビズリーチでは エンジニアを募集しています published 120