SI現場のテスト自動化への挑戦〜フルコンテナ構成のCI/CD環境〜
•Descargar como PPTX, PDF•
10 recomendaciones•7,152 vistas
JJUG CCC 2019 Spring登壇資料
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a SI現場のテスト自動化への挑戦〜フルコンテナ構成のCI/CD環境〜
Similar a SI現場のテスト自動化への挑戦〜フルコンテナ構成のCI/CD環境〜 (20)
Último
Último (12)
SI現場のテスト自動化への挑戦〜フルコンテナ構成のCI/CD環境〜
- 1. SI現場のテスト自動化への挑戦 〜フルコンテナ構成のCI/CD環境〜 2019年5月18日 JJUG CCC 2019 Spring #ccc_m4 川沼 大輝 日本アイ・ビー・エム株式会社 横山 夏実 日本アイ・ビー・エム システムズ・エンジニアリング株式会社
- 2. 2 自己紹介 川沼 大輝 日本アイ・ビー・エム株式会社 クラウドデリバリー部門に所属し、インフラからアプリまで幅広く担当 Java/C#/IBM Cloud/AWS 横山 夏実 日本アイ・ビー・エム システムズ・エンジニアリング株式会社 開発プロセスの改善、開発環境の構築運用に関わり10数年 Docker/Kubernetes
- 4. 4 アジェンダ • CI/CDを適用したプロジェクトについて • Javaのテスト実装について • フルコンテナ構成のCI/CD環境について • まとめ
- 6. 6 CI/CDを適用したプロジェクトについて プロジェクト概要 • 既存システムを統合し、新たなサービス基盤を構築するプロジェクト • APIにはMSA(Microservice Architecture)を採用 • ドメイン単位でCI/CDができる開発環境が必要 • 開発手法はWF型 • 想定される仕様変更に耐えられる品質ゲートを設けたい お客様 • CI/CDの必要性を認識されていて、取り組みに積極的 • 他のプロジェクトに横展開できるリファレンスケースを作りたい
- 7. 7 Web Server DB BFF CI/CDを適用したプロジェクトについて システムアーキテクチャ App API External API DB Service １ Service ２ Service N • 既存システムを統合/API化 • APIアーキテクチャにはMSAを採用 • API化に合わせてAppも刷新 • Appアーキテクチャはモノリス
- 8. 8 Web Server DB BFF システムアーキテクチャ App API External API DB Service １ Service ２ Service N CI/CD対象 CI/CDを適用したプロジェクトについて
- 9. 9 Development Tools Orchestration Tool Pipeline Test Staging Prod Compile UT Package Publish Git Repo コンテナの配置 運用監視リソース割当バックアップログ管理 etc Image Registry Package Repo ITa Deploy 以下のようなCI/CD環境を構想 CI/CDを適用したプロジェクトについて
- 10. 10 テスト自動化を考える上での二つの観点 • テスト実装そのもの • 業務や業務データに強く依存し、どんなテストをすれば良いのかを 一般化することは難しい • テスト実装コストと品質の兼ね合いが一つのポイント ➡︎ 今回のプロジェクトの観点を短めに説明する（当然唯一解ではない） • テストを動かす環境 • テスト実装に関わらず、ある程度一般化することが可能 • ポータビリティーとスケーラビリティーがポイント ➡︎ 幅広く適用できる構成を詳しく説明する CI/CDを適用したプロジェクトについて
- 12. 12 Javaのテスト実装について 3つのこだわりポイント 1. テスト実施観点の住み分け 2. 実装方法ごとにテストのレベル感を変える 3. テストデータは全て構造化されたフォーマットを使用する 品 質 コスト • 実装コストと品質が比例しなくなる 損益分岐点のようなものが存在する • 担保しなくてはいけない品質は満たしつつ、 妥当な実装コストを見出したい
- 13. 13 Javaのテスト実装について 1. テスト実施観点の住み分け 対象 観点 内容 CIでの実施 Test 静的 解析 • 全コード 静的コード 解析 • Checkstyle • SpotBugs 必須 UT • Controller • Service • Repository ホワイトボックス • 各レイヤーごとの単体テスト • ホワイトボックスの観点 • C1 100%を目指す 必須 ITa • Functional ブラックボックス • 一気通貫の機能テスト • ブラックボックスの観点 • パラメータ網羅を目指す 部分的
- 14. 14 Javaのテスト実装について Compile Run Unit Test Build Run ITa Test Publish Artifacts • Checkstyle • SpotBugs • JUnit • Jacoco • ITaの正常系のみ実施 • スクリプトのメンテナンスが追いつかなくなり 自動化が回らなくなることも考慮 • シンプルな正常系のみをCI上では自動実行 1. テスト実施観点の住み分け
- 16. 16 自動生成 クラス • 正常系1ケースのみ実装する • カバレッジ網羅が目的 • (UTが書いてある安心感) カスタム実装 クラス • 正常系と異常系を網羅的に実装する • C1 100%を目標にする • C2 は基本的に考慮しない Controller Service Service Client DAO Logic Javaのテスト実装について 2. 実装方法ごとにテストのレベル感を変える
- 17. 17 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が データを把握しやすい テストコードと テストデータを切り離せる 変更箇所が明確になる ⭕️ ⭕️ ⭕️
- 18. 18 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()); }
- 19. 19 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(); }
- 21. 21 フルコンテナ構成のCI/CD環境について プロジェクト概要 • 既存システムを統合し、新たなサービス基盤を構築するプロジェクト • APIにはMSA(Microservice Architecture)を採用 • ドメイン単位でCI/CDができる開発環境が必要 • 開発手法はWF型 • 想定される仕様変更に耐えられる品質ゲートを設けたい お客様 • CI/CDの必要性を認識されていて、取り組みに積極的 • 他のプロジェクトに横展開できるリファレンスケースを作りたい 【再掲】
- 22. 22 フルコンテナ構成のCI/CD環境について CI/CD環境を構築する上で実現したいこと • 実現したいこと 1. 開発中のバグを早期に発見し、品質を担保する品質ゲートの構築 2. 横展開できるリファレンスケース • 他のプロジェクトにも適用可能なポータビリティー • 大規模のプロジェクトにも適用可能なスケーラビリティー
- 23. 23 フルコンテナ構成のCI/CD環境について 1. 開発中のバグを早期発見し、品質を担保する品質ゲートの構築 目標: 正常なコードおよび実行可能なモジュールが常に用意できていること 1.1 実行可能であることが担保できるパイプラインを設定する ➡︎ DBを含むテスト、ITa相当のテストもCIの対象とする 1.2 バグが混在するコードはmasterにマージさせない ➡︎ featureブランチもCIの対象にする
- 24. 24 フルコンテナ構成のCI/CD環境について Compile Run Maven Test Build Run SoapUI Test Publish Artifacts DBを含むUT の実行 下記を公開 • Git tag • Docker image • Maven artifact Maven artifactと Docker Imageを生成 SoapUIによる ITaテスト実行 Gitへのpushを トリガーに起動 1.1 DB/ITaを含めたパイプライン設計
- 25. 25 Linux Open JDK Maven Jenkins Slave フルコンテナ構成のCI/CD環境について Compile Run Maven Test Build Run SoapUI Test Publish Artifacts .class Compileが通ることを確認 mvn compile git clone .java GitLab 1.1 DB/ITaを含めたパイプライン設計
- 26. 26 フルコンテナ構成のCI/CD環境について Compile Run Maven Test Build Run SoapUI Test Publish Artifacts Linux Open JDK Maven mvn test が通ることの確認 mvn test .java Jenkins Slave Linux PostgreSQL DB PostgreSQL docker run 1.1 DB/ITaを含めたパイプライン設計
- 27. 27 フルコンテナ構成の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を含めたパイプライン設計
- 28. 28 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 1.1 DB/ITaを含めたパイプライン設計
- 29. 29 Nexus フルコンテナ構成のCI/CD環境について Compile Run Maven Test Build Run SoapUI Test Publish Artifacts Linux Open JDK Maven GitLab ソースコードのタグをGitLabに格納 テスト済みのモジュールとDockerイメージをNexusに格納 mvn deploy –DskipTests=true docker push … git push –f –tags … Jenkins Slave 1.1 DB/ITaを含めたパイプライン設計
- 30. 30 フルコンテナ構成のCI/CD環境について Compile Run Maven Test Build Run SoapUI Test Publish Artifacts 1.1 DB/ITaを含めたパイプライン設計 Linux PostgreSQL DB PostgreSQL Linux SoapUI Soap UI Linux JDK Wildfly Wildfly Linux PostgreSQL DB PostgreSQL DBテスト、ITa相当のテストをCIに含むことで 品質ゲートのクオリティが向上した
- 31. 31 フルコンテナ構成のCI/CD環境について 1.2 パイプライン実行の対象 master feature/#1 commit feature/#2 commits for feature/#1 commits for feature/#2 merge commits merge commits 常にテスト済みのコードがMerge Requestされる
- 34. 34 フルコンテナ構成のCI/CD環境について 1. 開発中のバグを早期発見し、品質を担保する品質ゲートの構築 目標: 正常なコードおよび実行可能なモジュールが常に用意できていること 1.1 実行可能であることを担保できるパイプラインを設定する ➡︎ DBを含むテスト、ITa相当のテストもCIの対象とする 1.2 バグが混在するコードはmasterにマージさせない ➡︎ featureブランチもCIの対象にする
- 35. 35 フルコンテナ構成のCI/CD環境について 2. 横展開できるリファレンスケース 目標: プロジェクト規模、CI/CD実行環境（オンプレ/クラウド）に関わらず 適用可能なリファレンスケースを作る 2.1 出来るだけ実行環境・テストツールにロックインされないこと ➡︎ OSSとコンテナを用いてポータビリティーを確保 2.2 プロジェクト規模に応じてスケール可能なテスト実行方法 ➡︎ テストにコンテナを用いてスケーラビリティーを確保
- 36. 36 フルコンテナ構成の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で構成されている ➡︎ 実行環境に制約はない
- 37. 37 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 オンプレ/クラウドに関わらず 構築可能
- 38. 38 フルコンテナ構成のCI/CD環境について チケット管理 ジョブ管理 ソース管理 リポジトリ Docker Registry Maven Repository Docker Engine Wildfly PostgresSQL SoapUI Driver Stub Jenkins Slave 2.1 出来るだけ実行環境・テストツールにロックインされないこと テストツールにはあえて自由度を持たせて コンテナのみ流用するという考え方もできる ※ただし、ジョブなどはツールに合わせて一から実装する必要がある
- 39. 39 フルコンテナ構成のCI/CD環境について 2.1 出来るだけ実行環境・テストツールにロックインされないこと チケット管理 ジョブ管理 ソース管理 リポジトリ Docker Registry Maven Repository Wildfly PostgresSQL SoapUI Driver Stub Delivery Pipeline Managed GitLab Cloud Object Storage Container Registry Docker Engine テストのコンセプトと コンテナは流用可能
- 40. 40 フルコンテナ構成のCI/CD環境について 2.2 プロジェクト規模に応じてスケール可能なテスト実行方法 Compile UT Package PublishITa Deploy Compile UT Package PublishITa Deploy Compile UT Package PublishITa Deploy 一つのDB・スタブを共用する ➡︎ パイプラインのプロセスを並列実行できない テスト用 DB テスト用スタブ 【従来の方法】
- 41. 41 フルコンテナ構成のCI/CD環境について 2.2 プロジェクト規模に応じてスケール可能なテスト実行方法 Compile UT Package PublishITa Deploy Compile UT Package PublishITa Deploy Compile UT Package PublishITa Deploy 一連のパイプラインのプロセス１回ごとに独立してコンテナが起動する ➡︎ 並列実行に機能的な制限はない 【今回の方法】
- 42. 42 フルコンテナ構成のCI/CD環境について 2.2 プロジェクト規模に応じてスケール可能なテスト実行方法 Compile UT Package PublishITa Deploy Compile UT Package PublishITa Deploy Compile UT Package PublishITa Deploy Compile UT Package PublishITa Deploy ・ ・ ・ 物理リソースの限界までスケールさせることが可能 ※ただし、オーケストレーション・ツールは必須性が高い（後述） 【今回の方法】
- 43. 43 フルコンテナ構成のCI/CD環境について 2. 横展開できるリファレンスケース 目標: プロジェクト規模、CI/CD実行環境（オンプレ/クラウド）に関わらず 適用可能なリファレンスケースを作る 2.1 出来るだけ実行環境・テストツールにロックインされないこと ➡︎ OSSとコンテナを用いてポータビリティーを確保 2.2 プロジェクト規模に応じてスケール可能なテスト実行方法 ➡︎ テストにコンテナを用いてスケーラビリティーを確保
- 45. 45 フルコンテナ構成の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実行方法 ホスト側で 起動する
- 46. 46 フルコンテナ構成の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
- 47. 47 フルコンテナ構成のCI/CD環境について パイプラインの成果物は全て一意のリリースID持たせて管理する Gitタグ Nexus Maven Artifact ID Dockerイメージのタグ v_x.x.x Git • MavenのArtifact ID、Dockerイメージのタグ、Gitリポジトリのタグを揃える • 問題が発生したとき、以前のリリースにロールバックできる パイプラインの Publish処理で採番
- 48. 48 アジェンダ • SI現場のよくある問題 • Microservice プロジェクトについて • Javaのテスト実装について • フルコンテナ構成のCI/CD環境について • まとめ
- 49. 49 まとめ
- 50. 50 まとめ フルコンテナ構成のCI/CD環境を構築した • DBテスト、ITa相当のテストを含んだパイプラインを構築できた • ポータビリティとスケーラビリティを兼ね備えたリファレンスケースを作成できた 課題 • オーケストレーション・ツールの必要性が高い
- 51. 51 課題 • 現状 • 現在の実装ではGitリポジトリ単位で固定のポートを利用 • Jenkinsの処理実行時に読み込むプロパティを切り替える • ポートも指定してアクセスする • 今後 • オーケストレーション・ツールの提供する機能に応じて実装を行う • サービスはポート指定なしでアクセスできるようにする • ポートとホストを紐付け、デプロイされているアプリケーションは紐付けを変更 するだけで即座にサービスとして公開できる オーケストレーション・ツールの必要性 ① Port Binding パイプラインプロセスごとに起動するコンテナに割り当てるポートの管理 SERVICE NAME PORT /XXXX APP:8080 /YYYY APP:8081
- 52. 52 課題 オーケストレーション・ツールの必要性 ② コンテナおよびサービス稼動確認 (例)SoapUIコンテナ上でスタブが起動しているか？のチェック • 現状 • Jenkinsfile内では起動時間の実績値を元にsleepで待つ実装（イケテナイ） • 想定する時間内で起動しない場合にはジョブは失敗してしまう • 今後 • オーケストレーション・ツールの提供する機能に応じて実装を行う • Liveness Probe：コンテナが実行中でなければ再起動を実施 • Readiness Probe：サービス提供可能かチェックしエンドポイントに公開 This container is OK! This service is reachable! No response.. Restart!
- 53. 53 Development Tools Orchestration Tool Pipeline Test Staging Prod Compile UT Package Publish Git Repo コンテナの配置 運用監視リソース割当バックアップログ管理 etc Image Registry Package Repo ITa Deploy オーケストレーション・ツールを用いた理想的な構成を作りたい 課題
- 54. 54 ご静聴ありがとうございました 川沼 大輝 Twitter: @Santea3173 Email: kawanuma@jp.ibm.com 横山 夏実 Email: nykym@jp.ibm.com
- 55. 55 EOF