SI現場のテスト自動化への挑戦〜フルコンテナ構成のCI/CD環境〜

JJUG CCC 2019 Spring 登壇資料

Transcript

1. SI現場のテスト⾃動化への挑戦 〜フルコンテナ構成のCI/CD環境〜 2019年5⽉18⽇ JJUG CCC 2019 Spring #ccc_m4 川沼 ⼤輝 ⽇本アイ・ビー・エム株式会社 横⼭ 夏実 ⽇本アイ・ビー・エム システムズ・エンジニアリング株式会社
2. 2 ⾃⼰紹介 川沼 ⼤輝 ⽇本アイ・ビー・エム株式会社 クラウドデリバリー部⾨に所属し、インフラからアプリまで幅広く担当 Java/C#/IBM Cloud/AWS 横⼭ 夏実 ⽇本アイ・ビー・エム システムズ・エンジニアリング株式会社 開発プロセスの改善、開発環境の構築運⽤に関わり10数年 Docker/Kubernetes
3. 3 免責事項 本発表は私自身の見解であり、 所属組織の立場、戦略、意見を代表するものではありません
4. 4 アジェンダ • CI/CDを適⽤したプロジェクトについて • Javaのテスト実装について • フルコンテナ構成のCI/CD環境について • まとめ
5. 5 アジェンダ • CI/CDを適⽤したプロジェクトについて • Javaのテスト実装について • フルコンテナ構成のCI/CD環境について • まとめ
6. 6 CI/CDを適⽤した プロジェクトについて
7. 7 CI/CDを適⽤したプロジェクトについて プロジェクト概要 • 既存システムを統合し、新たなサービス基盤を構築するプロジェクト • APIにはMSA(Microservice Architecture)を採⽤ • ドメイン単位でCI/CDができる開発環境が必要 • 開発⼿法はWF型 • 想定される仕様変更に耐えられる品質ゲートを設けたい お客様 • CI/CDの必要性を認識されていて、取り組みに積極的 • 他のプロジェクトに横展開できるリファレンスケースを作りたい
8. 8 Web Server DB BFF CI/CDを適⽤したプロジェクトについて システムアーキテクチャ App API External API DB Service １ Service ２ Service N
9. 9 Web Server DB BFF CI/CDを適⽤したプロジェクトについて システムアーキテクチャ App API External API DB Service １ Service ２ Service N • 既存システムを統合/API化 • APIアーキテクチャにはMSAを採⽤
10. 10 Web Server DB BFF CI/CDを適⽤したプロジェクトについて システムアーキテクチャ App API External API DB Service １ Service ２ Service N • 既存システムを統合/API化 • APIアーキテクチャにはMSAを採⽤ • API化に合わせてAppも刷新 • Appアーキテクチャはモノリス
11. 11 Web Server DB BFF システムアーキテクチャ App API External API DB Service １ Service ２ Service N CI/CD対象 CI/CDを適⽤したプロジェクトについて
12. 12 Development Tools Orchestra2on Tool Pipeline Test Staging Prod Compile UT Package Publish Git Repo コンテナの配置 運⽤監視 リソース割当 バックアップ ログ管理 etc Image Registry Package Repo ITa Deploy 以下のようなCI/CD環境を構想 CI/CDを適⽤したプロジェクトについて
13. 13 テスト⾃動化を考える上での⼆つの観点 • テスト実装そのもの • 業務や業務データに強く依存し、どんなテストをすれば良いのかを ⼀般化することは難しい • テスト実装コストと品質の兼ね合いが⼀つのポイント ➡ 今回のプロジェクトの観点を短めに説明する（当然唯⼀解ではない） • テストを動かす環境 • テスト実装に関わらず、ある程度⼀般化することが可能 • ポータビリティーとスケーラビリティーがポイント ➡ 幅広く適⽤できる構成を詳しく説明する CI/CDを適⽤したプロジェクトについて
14. 14 アジェンダ • Microservice指向のプロジェクトについて • Javaのテスト実装について • フルコンテナ構成のCI/CD環境について • まとめ
15. 15 Javaの テスト実装について
16. 16 Javaのテスト実装について 3つのこだわりポイント 1. テスト実施観点の住み分け 2. 実装⽅法ごとにテストのレベル感を変える 3. テストデータは全て構造化されたフォーマットを使⽤する 品 質 コスト • 実装コストと品質が⽐例しなくなる 損益分岐点のようなものが存在する • 担保しなくてはいけない品質は満たしつつ、 妥当な実装コストを⾒出したい
17. 17 Javaのテスト実装について 1. テスト実施観点の住み分け 対象 観点 内容 CIでの実施 Test 静的 解析 • 全コード 静的コード 解析 • Checkstyle • SpotBugs 必須 UT • Controller • Service • Repository ホワイトボックス • 各レイヤーごとの単体テスト • ホワイトボックスの観点 • C1 100%を⽬指す 必須 ITa • Functional ブラックボックス • ⼀気通貫の機能テスト • ブラックボックスの観点 • パラメータ網羅を⽬指す 部分的
18. 18 Javaのテスト実装について Compile Run Unit Test Build Run ITa Test Publish Ar2facts • Checkstyle • SpotBugs • JUnit • Jacoco • ITaの正常系のみ実施 • スクリプトのメンテナンスが追いつかなくなり ⾃動化が回らなくなることも考慮 • シンプルな正常系のみをCI上では⾃動実⾏ 1. テスト実施観点の住み分け
19. 19 カスタム実装 API Controller Service Repository Controller Service Logic DAO 共 通 機 能 Entity DTO Service Client Request DTO Response DTO Javaのテスト実装について 2. 実装⽅法ごとにテストのレベル感を変える 自動生成
20. 20 ⾃動⽣成 クラス • 正常系1ケースのみ実装する • カバレッジ網羅が⽬的 • (UTが書いてある安⼼感) カスタム実装 クラス • 正常系と異常系を網羅的に実装する • C1 100%を⽬標にする • C2 は基本的に考慮しない Controller Service Service Client DAO Logic Javaのテスト実装について 2. 実装⽅法ごとにテストのレベル感を変える
21. 21 Javaのテスト実装について 3. テストデータには全て構造化されたフォーマットを使⽤ API Controller • Request • Response • Query param Service • Request • DTO • Response Repository • DTO • DB Data → JSON → JSON → TXT → JSON → JSON → JSON → JSON → CSV 構造化されたテストデータ Reviewerが データを把握しやすい テストコードと テストデータを切り離せる 変更箇所が明確になる ⭕ ⭕ ⭕
22. 22 Javaのテスト実装について テストコード（Controller） @Test public void ID001_selectPets_正常系パラメータ指定あり() throws Exception { List<PetResponse> actualResponse = TestDataLoader.loadJsonAsObject( RESOURCE_PATH + "/case001/response.json", new TypeReference<List<PetResponse>>() {}); when(petService.selectAll(any(PetRequestQuery.class), anyList(), anyList(), any(RowBounds.class))).thenReturn(actualResponse); String query = TestDataLoader.loadJsonAsString(RESOURCE_PATH + "/case001/query.txt"); String actualJson = TestDataLoader.loadJsonAsString(RESOURCE_PATH + "/case001/response.json"); this.mockMvc.perform(get( "/api/v1/customers/pets?" + query)) .andExpect(status().isOk()) .andExpect(content().contentType(MediaType.APPLICATION_JSON_UTF8)) .andExpect(content().json(actualJson)); verify(petService, times(1)).selectAll(queryCaptor.capture(), fieldsCaptor.capture(), sortsCaptor.capture(), rowBoundsCaptor.capture()); assertEquals(Arrays.asList(1, 2), queryCaptor.getValue().getSeq()); assertEquals(Arrays.asList("ぽち", "たま"), queryCaptor.getValue().getName()); assertEquals(Arrays.asList(1, 2), queryCaptor.getValue().getPetTypeId()); }
23. 23 Javaのテスト実装について テストコード（Controller） @Test public void ID001_selectPets_正常系パラメータ指定あり() throws Excepcon { List<PetResponse> actualResponse = TestDataLoader.loadJsonAsObject( RESOURCE_PATH + "/case001/response.json", new TypeReference<List<PetResponse>>() {}); when(petService.selectAll(any(PetRequestQuery.class), anyList(), anyList(), any(RowBounds.class))).thenReturn(actualResponse); String query = TestDataLoader.loadJsonAsString(RESOURCE_PATH + "/case001/query.txt"); String actualJson = TestDataLoader.loadJsonAsString(RESOURCE_PATH + "/case001/response.json"); this.mockMvc.perform(get( "/api/v1/customers/pets?" + query)) .andExpect(status().isOk()) .andExpect(content().contentType(MediaType.APPLICATION_JSON_UTF8)) .andExpect(content().json(actualJson)); verify(petService, cmes(1)).selectAll(queryCaptor.capture(), fieldsCaptor.capture(), sortsCaptor.capture(), rowBoundsCaptor.capture()); assertEquals(Arrays.asList(1, 2), queryCaptor.getValue().getSeq()); assertEquals(Arrays.asList("ぽち", "たま"), queryCaptor.getValue().getName()); assertEquals(Arrays.asList(1, 2), queryCaptor.getValue().getPetTypeId()); } List<PetResponse> actualResponse = TestDataLoader.loadJsonAsObject( PATH + "/case001/response.json", new TypeReference<List<PetResponse>>() {});
24. 24 Javaのテスト実装について テストコード（Repository） @Test public void ID005_insertSelective_正常系() throws Exception { databaseSetup(); PetDto dto = TestDataLoader.loadJsonAsObject(RESOURCE_PATH + "/case005/dto.json", PetDto.class); int insertedCount = petDao.insertSelective(dto); assertEquals(1, insertedCount); IDataSet expectedDataset = new CsvDataSet(new File(FILE_PATH + "/case005")); ITable expectedTable = expectedDataset.getTable("pet"); IDataSet databaseDataSet = databaseConnection.createDataSet(); ITable actualTable = databaseDataSet.getTable("pet"); Assertion.assertEquals(expectedTable, actualTable); databseClear(); }
25. 25 Javaのテスト実装について テストコード（Repository） @Test public void ID005_insertSelecYve_正常系() throws ExcepYon { databaseSetup(); PetDto dto = TestDataLoader.loadJsonAsObject(RESOURCE_PATH + "/case005/dto.json", PetDto.class); int insertedCount = petDao.insertSelecYve(dto); assertEquals(1, insertedCount); IDataSet expectedDataset = new CsvDataSet(new File(FILE_PATH + "/case005")); ITable expectedTable = expectedDataset.getTable("pet"); IDataSet databaseDataSet = databaseConnecYon.createDataSet(); ITable actualTable = databaseDataSet.getTable("pet"); AsserYon.assertEquals(expectedTable, actualTable); databseClear(); } PetDto dto = TestDataLoader.loadJsonAsObject(PATH + "/case005/dto.json", PetDto.class);
26. 26 Javaのテスト実装について テストコード（Repository） @Test public void ID005_insertSelective_正常系() throws Exception { databaseSetup(); PetDto dto = TestDataLoader.loadJsonAsObject(RESOURCE_PATH + "/case005/dto.json", PetDto.class); int insertedCount = petDao.insertSelective(dto); assertEquals(1, insertedCount); IDataSet expectedDataset = new CsvDataSet(new File(FILE_PATH + "/case005")); ITable expectedTable = expectedDataset.getTable("pet"); IDataSet databaseDataSet = databaseConnection.createDataSet(); ITable actualTable = databaseDataSet.getTable("pet"); Assertion.assertEquals(expectedTable, actualTable); databseClear(); } IDataSet expectedDataset = new CsvDataSet(new File(FILE_PATH + "/case005")); ITable expectedTable = expectedDataset.getTable("pet"); IDataSet databaseDataSet = databaseConnection.createDataSet(); ITable actualTable = databaseDataSet.getTable("pet"); Assertion.assertEquals(expectedTable, actualTable);
27. 27 アジェンダ • Microservice指向のプロジェクトについて • Javaのテスト実装について • フルコンテナ構成のCI/CD環境について • まとめ
28. 28 フルコンテナ構成の CI/CD環境について
29. 29 フルコンテナ構成のCI/CD環境について プロジェクト概要 • 既存システムを統合し、新たなサービス基盤を構築するプロジェクト • APIにはMSA(Microservice Architecture)を採⽤ • ドメイン単位でCI/CDができる開発環境が必要 • 開発⼿法はWF型 • 想定される仕様変更に耐えられる品質ゲートを設けたい お客様 • CI/CDの必要性を認識されていて、取り組みに積極的 • 他のプロジェクトに横展開できるリファレンスケースを作りたい 【再掲】
30. 30 フルコンテナ構成のCI/CD環境について CI/CD環境を構築する上で実現したいこと • 実現したいこと 1. 開発中のバグを早期に発⾒し、品質を担保する品質ゲートの構築 2. 横展開できるリファレンスケース • 他のプロジェクトにも適⽤可能なポータビリティー • ⼤規模のプロジェクトにも適⽤可能なスケーラビリティー
31. 31 フルコンテナ構成のCI/CD環境について 1. 開発中のバグを早期発⾒し、品質を担保する品質ゲートの構築 ⽬標: 正常なコードおよび実⾏可能なモジュールが常に⽤意できていること 1.1 実⾏可能であることを担保できるパイプラインを設定する ➡ DBを含むテスト、ITa相当のテストもCIの対象とする 1.2 バグが混在するコードはmasterにマージさせない ➡ featureブランチもCIの対象にする
32. 32 フルコンテナ構成のCI/CD環境について 1. 開発中のバグを早期発⾒し、品質を担保する品質ゲートの構築 ⽬標: 正常なコードおよび実⾏可能なモジュールが常に⽤意できていること 1.1 実⾏可能であることが担保できるパイプラインを設定する ➡ DBを含むテスト、ITa相当のテストもCIの対象とする 1.2 バグが混在するコードはmasterにマージさせない ➡ featureブランチもCIの対象にする
33. 33 フルコンテナ構成のCI/CD環境について Compile Run Maven Test Build Run SoapUI Test Publish Ar2facts DBを含むUT の実⾏ 下記を公開 • Git tag • Docker image • Maven artifact Maven artifactと Docker Imageを⽣成 SoapUIによる ITaテスト実⾏ Gitへのpushを トリガーに起動 1.1 DB/ITaを含めたパイプライン設計
34. 34 フルコンテナ構成のCI/CD環境について Compile Run Maven Test Build Run SoapUI Test Publish Artifacts 1.1 DB/ITaを含めたパイプライン設計
35. 35 Linux Open JDK Maven Jenkins Slave フルコンテナ構成のCI/CD環境について Compile Run Maven Test Build Run SoapUI Test Publish Ar2facts .class Compileが通ることを確認 mvn compile git clone .java GitLab 1.1 DB/ITaを含めたパイプライン設計
36. 36 フルコンテナ構成のCI/CD環境について Compile Run Maven Test Build Run SoapUI Test Publish Ar2facts Linux Open JDK Maven mvn test が通ることの確認 mvn test .java Jenkins Slave Linux PostgreSQL DB PostgreSQL docker run docker stop docker rm 1.1 DB/ITaを含めたパイプライン設計
37. 37 フルコンテナ構成のCI/CD環境について Compile Run Maven Test Build Run SoapUI Test Publish Artifacts Linux Open JDK Maven .war, Dockerイメージ を⽣成 mvn clean package –DskipTests=true docker build Linux JDK Wildfly Wildfly .war .java Jenkins Slave 1.1 DB/ITaを含めたパイプライン設計
38. 38 mockservicerunner.sh フルコンテナ構成のCI/CD環境について Compile Run Maven Test Build Run SoapUI Test Publish Artifacts Linux Open JDK Maven Jenkins ITaテストが通ることを確認 Linux JDK Wildfly Wildfly testrunner.sh docker-compose up –build -d junit ‘TEST*.xml' Jenkins Slave Linux PostgreSQL DB PostgreSQL Linux SoapUI Soap UI テスト結果（xml） docker-compose down 1.1 DB/ITaを含めたパイプライン設計
39. 39 Nexus フルコンテナ構成のCI/CD環境について Compile Run Maven Test Build Run SoapUI Test Publish Ar2facts Linux Open JDK Maven GitLab ソースコードのタグをGitLabに格納 テスト済みのモジュールとDockerイメージをNexusに格納 mvn deploy –DskipTests=true docker push … git push –f –tags … Jenkins Slave 1.1 DB/ITaを含めたパイプライン設計
40. 40 フルコンテナ構成のCI/CD環境について Compile Run Maven Test Build Run SoapUI Test Publish Ar2facts 1.1 DB/ITaを含めたパイプライン設計 Linux PostgreSQL DB PostgreSQL Linux SoapUI Soap UI Linux JDK Wildfly Wildfly Linux PostgreSQL DB PostgreSQL DBテスト、ITa相当のテストをCIに含むことで 品質ゲートのクオリティが向上した
41. 41 フルコンテナ構成のCI/CD環境について 1. 開発中のバグを早期発⾒し、品質を担保する品質ゲートの構築 ⽬標: 正常なコードおよび実⾏可能なモジュールが常に⽤意できていること 1.1 実⾏可能であることを担保できるパイプラインを設定する ➡ DBを含むテスト、ITa相当のテストもCIの対象とする 1.2 バグが混在するコードはmasterにマージさせない ➡ featureブランチもCIの対象にする
42. 42 フルコンテナ構成のCI/CD環境について 1.2 パイプライン実⾏の対象 master feature/#1 commit feature/#2 commits for feature/#1 commits for feature/#2 merge commits merge commits
43. 43 フルコンテナ構成のCI/CD環境について 1.2 パイプライン実⾏の対象 master feature/#1 commit feature/#2 commits for feature/#1 commits for feature/#2 merge commits merge commits
44. 44 フルコンテナ構成のCI/CD環境について 1.2 パイプライン実⾏の対象 master feature/#1 commit feature/#2 commits for feature/#1 commits for feature/#2 merge commits merge commits
45. 45 フルコンテナ構成のCI/CD環境について 1.2 パイプライン実⾏の対象 master feature/#1 commit feature/#2 commits for feature/#1 commits for feature/#2 merge commits merge commits 常にテスト済みのコードがMerge Requestされる
46. 46 フルコンテナ構成のCI/CD環境について CIに失敗したMerge Requestはマージできない ➡ masterにはCIが通ったものだけマージが可能
47. 47 フルコンテナ構成のCI/CD環境について CIに失敗したMerge Requestはマージできない ➡ masterにはCIが通ったものだけマージが可能
48. 48 フルコンテナ構成のCI/CD環境について 1. 開発中のバグを早期発⾒し、品質を担保する品質ゲートの構築 ⽬標: 正常なコードおよび実⾏可能なモジュールが常に⽤意できていること 1.1 実⾏可能であることを担保できるパイプラインを設定する ➡ DBを含むテスト、ITa相当のテストもCIの対象とする 1.2 バグが混在するコードはmasterにマージさせない ➡ featureブランチもCIの対象にする テストの品質が担保された テストのプロセスが担保された
49. 49 フルコンテナ構成のCI/CD環境について 2. 横展開できるリファレンスケース ⽬標: プロジェクト規模、CI/CD実⾏環境（オンプレ/クラウド）に関わらず 適⽤可能なリファレンスケースを作る 2.1 出来るだけ実⾏環境・テストツールにロックインされないこと ➡ OSSとコンテナを⽤いてポータビリティーを確保 2.2 プロジェクト規模に応じてスケール可能なテスト実⾏⽅法 ➡ テストにコンテナを⽤いてスケーラビリティーを確保
50. 50 フルコンテナ構成のCI/CD環境について テストツール⽤VM Jenkins Slave⽤VM RHEL Redmine Jenkins GitLab Nexus Docker Registry Maven Repository RHEL Docker Engine Wildfly PostgresSQL SoapUI Driver Stub Jenkins Slave 2.1 出来るだけ実⾏環境・テストツールにロックインされないこと
51. 51 フルコンテナ構成のCI/CD環境について テストツール⽤VM Jenkins Slave⽤VM RHEL Redmine Jenkins GitLab Nexus Docker Registry Maven Repository RHEL Docker Engine Wildfly PostgresSQL SoapUI Driver Stub Jenkins Slave 2.1 出来るだけ実⾏環境・テストツールにロックインされないこと 全てOSSで構成されている ➡ 実⾏環境に制約はない
52. 52 Redmine Jenkins GitLab Nexus Docker Registry Maven Repository Docker Engine Wildfl y PostgresSQL SoapUI Driver Stub Jenkins Slave Redmine Jenkins GitLab Nexus Docker Registry Maven Repository Docker Engine Wildfl y PostgresSQL SoapUI Driver Stub Jenkins Slave フルコンテナ構成のCI/CD環境について 2.1 出来るだけ実⾏環境・テストツールにロックインされないこと Redmine Jenkins GitLab Nexus Docker Registry Maven Repository Docker Engine Wildfl y PostgresSQL SoapUI Driver Stub Jenkins Slave On premises オンプレ/クラウドに関わらず 構築可能
53. 53 フルコンテナ構成のCI/CD環境について 2.1 出来るだけ実⾏環境・テストツールにロックインされないこと Redmine Jenkins GitLab Nexus Docker Registry Maven Repository Docker Engine Wildfly PostgresSQL SoapUI Driver Stub Jenkins Slave
54. 54 フルコンテナ構成のCI/CD環境について チケット管理 ジョブ管理 ソース管理 リポジトリ Docker Registry Maven Repository Docker Engine Wildfly PostgresSQL SoapUI Driver Stub Jenkins Slave 2.1 出来るだけ実⾏環境・テストツールにロックインされないこと テストツールにはあえて⾃由度を持たせて コンテナのみ流⽤するという考え⽅もできる ※ただし、ジョブなどはツールに合わせて⼀から実装する必要がある
55. 55 フルコンテナ構成のCI/CD環境について 2.1 出来るだけ実⾏環境・テストツールにロックインされないこと チケット管理 ジョブ管理 ソース管理 リポジトリ Docker Registry Maven Repository Wildfly PostgresSQL SoapUI Driver Stub Delivery Pipeline Managed GitLab Cloud Object Storage Container Registry Docker Engine テストのコンセプトと コンテナは流⽤可能
56. 56 フルコンテナ構成のCI/CD環境について 2. 横展開できるリファレンスケース ⽅針: プロジェクト規模、CI/CD実⾏環境（オンプレ/クラウド）に関わらず 適⽤可能なリファレンスケースを作る 2.1 出来るだけ実⾏環境・テストツールにロックインされないこと ➡ OSSとコンテナを⽤いてポータビリティーを確保 2.2 プロジェクト規模に応じてスケール可能なテスト実⾏⽅法 ➡ テストにコンテナを⽤いてスケーラビリティーを確保
57. 57 フルコンテナ構成のCI/CD環境について 2.2 プロジェクト規模に応じてスケール可能なテスト実⾏⽅法 Compile UT Package Publish ITa Deploy Compile UT Package Publish ITa Deploy Compile UT Package Publish ITa Deploy ⼀つのDB・スタブを共⽤する ➡ パイプラインのプロセスを並列実⾏できない テスト⽤ DB テスト⽤スタブ 【従来の⽅法】
58. 58 フルコンテナ構成のCI/CD環境について 2.2 プロジェクト規模に応じてスケール可能なテスト実⾏⽅法 Compile UT Package Publish ITa Deploy Compile UT Package Publish ITa Deploy Compile UT Package Publish ITa Deploy ⼀連のパイプラインのプロセス１回ごとに独⽴してコンテナが起動する ➡ 並列実⾏に機能的な制限はない 【今回の⽅法】
59. 59 フルコンテナ構成のCI/CD環境について 2.2 プロジェクト規模に応じてスケール可能なテスト実⾏⽅法 Compile UT Package Publish ITa Deploy Compile UT Package Publish ITa Deploy Compile UT Package Publish ITa Deploy Compile UT Package Publish ITa Deploy ・ ・ ・ 物理リソースの限界までスケールさせることが可能 ※ただし、オーケストレーション・ツールは必須性が⾼い（後述） 【今回の⽅法】
60. 60 フルコンテナ構成のCI/CD環境について 2. 横展開できるリファレンスケース ⽬標: プロジェクト規模、CI/CD実⾏環境（オンプレ/クラウド）に関わらず 適⽤可能なリファレンスケースを作る 2.1 出来るだけ実⾏環境・テストツールにロックインされないこと ➡ OSSとコンテナを⽤いてポータビリティーを確保 2.2 プロジェクト規模に応じてスケール可能なテスト実⾏⽅法 ➡ テストにコンテナを⽤いてスケーラビリティーを確保 ポータビリティーが確保できた スケーラビリティーが確保できた
61. 61 フルコンテナ構成のCI/CD環境について プロジェクト概要 • 既存システムを統合し、新たなサービス基盤を構築するプロジェクト • APIにはMSA(Microservice Architecture)を採⽤ • ドメイン単位でCI/CDができる開発環境が必要 • 開発⼿法はWF型 • 想定される仕様変更に耐えられる品質ゲートを設けたい お客様 • CI/CDの必要性を認識されていて、取り組みに積極的 • 他のプロジェクトに横展開できるリファレンスケースを作りたい 【再掲】
62. 62 フルコンテナ構成のCI/CD環境について 実践的なプラクティスをいくつかご紹介
63. 63 フルコンテナ構成のCI/CD環境について • Docker outside of Docker (DooD) • Slaveのコンテナ上で実⾏されたDockerコマンドは ホスト側のDocker環境で実⾏される Docker Engine Jenkins Slave /var/run/docker.sock /var/run/docker.sock mount Wildfly PostgreSQL $ docker run Docker実⾏⽅法 ホスト側で 起動する
64. 64 フルコンテナ構成のCI/CD環境について パイプラインの設定はソースコードと⼀緒にリポジトリで管理 • ソースコード • テストデータ • JSON • CSV • SQL • Jenkisfile • Dockerfile • アプリ • DB • スタブ Git • ソースコード、テストデータ、Dockerfile、Jenkinsfile等は ドメインごとにGitリポジトリで管理している • Infrastructure as Codeの観点 • ローカル環境とCI/CD環境で同⼀のテストが実⾏可能 （ローカル環境でDockerを使ったテストが⾏える） ・・・ • ソースコード • テストデータ • JSON • CSV • SQL • Jenkisfile • Dockerfile • アプリ • DB • スタブ Domain 1 Domain N
65. 65 フルコンテナ構成のCI/CD環境について パイプラインの成果物は全て⼀意のリリースID持たせて管理する Gitタグ Nexus Maven Artifact ID Dockerイメージのタグ v_x.x.x Git • MavenのArtifact ID、Dockerイメージのタグ、Gitリポジトリのタグを揃える • 問題が発⽣したとき、以前のリリースにロールバックできる パイプラインの Publish処理で採番
66. 66 アジェンダ • SI現場のよくある問題 • Microservice プロジェクトについて • Javaのテスト実装について • フルコンテナ構成のCI/CD環境について • まとめ
67. 67 まとめ
68. 68 まとめ フルコンテナ構成のCI/CD環境を構築した • DBテスト、ITa相当のテストを含んだパイプラインを構築できた • ポータビリティとスケーラビリティを兼ね備えたリファレンスケースを作成できた 課題 • オーケストレーション・ツールの必要性が⾼い
69. 69 課題 • 現状 • 現在の実装ではGitリポジトリ単位で固定のポートを利⽤ • Jenkinsの処理実⾏時に読み込むプロパティを切り替える • ポートも指定してアクセスする • 今後 • オーケストレーション・ツールの提供する機能に応じて実装を⾏う • サービスはポート指定なしでアクセスできるようにする • ポートとホストを紐付け、デプロイされているアプリケーションは紐付けを変更 するだけで即座にサービスとして公開できる オーケストレーション・ツールの必要性 ① Port Binding パイプラインプロセスごとに起動するコンテナに割り当てるポートの管理 SERVICE NAME PORT /XXXX APP:8080 /YYYY APP:8081
70. 70 課題 オーケストレーション・ツールの必要性 ② コンテナおよびサービス稼動確認 (例)SoapUIコンテナ上でスタブが起動しているか︖のチェック • 現状 • Jenkinsfile内では起動時間の実績値を元にsleepで待つ実装（イケテナイ） • 想定する時間内で起動しない場合にはジョブは失敗してしまう • 今後 • オーケストレーション・ツールの提供する機能に応じて実装を⾏う • Liveness Probe︓コンテナが実⾏中でなければ再起動を実施 • Readiness Probe︓サービス提供可能かチェックしエンドポイントに公開 This container is OK! This service is reachable! No response.. Restart!
71. 71 Development Tools Orchestration Tool Pipeline Test Staging Prod Compile UT Package Publish Git Repo コンテナの配置 運⽤監視 リソース割当 バックアップ ログ管理 etc Image Registry Package Repo ITa Deploy オーケストレーション・ツールを⽤いた理想的な構成を作りたい 課題
72. 72 ご静聴ありがとうございました 川沼 ⼤輝 Twitter: @Santea3173 Email: kawanuma@jp.ibm.com 横⼭ 夏実 Email: nykym@jp.ibm.com
73. 73 EOF