\u00a0<\/span><\/p>\nI<\/span>\u00a0will try to address most of these<\/span>\u00a0questions with an approach that we call<\/span>\u00a0\u201cQuality Gates model as a<\/span>\u00a0strategy to test<\/span>\u00a0microservices\u201d.<\/span>\u00a0This approach involves construction of<\/span>\u00a0quality gates into the CI\/CD\u00a0<\/span>pipeline\u00a0<\/span>for which we take the<\/span>\u00a0help of our development teams, build teams, deployment<\/span>,<\/span>\u00a0<\/span>and<\/span>\u00a0infrastructure teams.<\/span>\u00a0As the construction of quality gates is a test architecture activity that requires highly technical QA resources, it is essential that all the members across different teams work very closely. More importantly, you should first propose the Quality gates strategy to your stakeholders and obtain the required support from them.<\/span>\u00a0<\/span><\/p>\nThe following flow diagram offers a bird\u2019s eye view to the overall architecture with Quality gates established within the CI\/CD pipelines. I will explain each stage of\u00a0<\/span>the\u00a0<\/span>Quality gate<\/span>\u00a0strategy<\/span>\u00a0one by <\/span><\/p>\none:<\/span>\u00a0<\/span><\/p>\n<\/p>\n
Quality Gate 1:<\/span><\/b>\u00a0<\/span><\/b>Execute\u00a0<\/span><\/b>Unit Tests<\/span><\/b>\u00a0<\/span><\/p>\nAt this stage, developers\u00a0<\/span>commit<\/span>\u00a0and push<\/span>\u00a0<\/span>the<\/span>\u00a0code to their branch<\/span>es<\/span>\u00a0where it<\/span>\u00a0undergoes reviews and merges. When the code is merged to a master copy<\/span>,<\/span>\u00a0we ensure that a build pipeline is triggered to run all<\/span>\u00a0the<\/span>\u00a0unit tests against the master copy.<\/span>\u00a0<\/span><\/p>\nThings to consider:<\/span><\/b>\u00a0<\/span><\/p>\n\n- This must be\u00a0<\/span>a<\/span>\u00a0part of\u00a0<\/span>the\u00a0<\/span>CI process<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
\n- A CI environment is the best place to execute<\/span>\u00a0<\/span><\/li>\n
- Mock data is often used in building the tests<\/span>\u00a0<\/span><\/li>\n
- Test component is microservice (scope is limited to a microservice)<\/span>\u00a0<\/span><\/li>\n
- Junit and NUnit are\u00a0<\/span>the\u00a0<\/span>best examples\u00a0<\/span>of\u00a0<\/span>tools\/frameworks<\/span>\u00a0<\/span><\/li>\n
- Recommended exit criteri<\/span>on<\/span>\u00a0is 100% pass rate<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
Quality Gate 2 (Optional): Static code analysis\/Code coverage<\/span><\/b>\u00a0<\/span><\/p>\nThis is an optional quality gate that must be<\/span>\u00a0a<\/span>\u00a0part of your CI process<\/span>,<\/span>\u00a0if you choose to introduce it.\u00a0<\/span>The gate<\/span>\u00a0is not enforced by QA<\/span>. It is, in fact, a<\/span>\u00a0collaborative decision from\u00a0<\/span>the involved<\/span>\u00a0team<\/span>s<\/span>\u00a0(build, development, QA etc.).\u00a0<\/span>People usually go for commerc<\/span>ial solutions that\u00a0<\/span>offer<\/span>\u00a0great reporting on number of lines, blocks,<\/span>\u00a0and<\/span>\u00a0<\/span>methods<\/span>\u00a0covered and to\u00a0<\/span>analyse<\/span>\u00a0the code quality, unit test coverage<\/span>,<\/span>\u00a0and violations.<\/span>\u00a0<\/span><\/p>\nThings to consider:<\/span><\/b>\u00a0<\/span><\/p>\n\n- This must be a part of\u00a0<\/span>the\u00a0<\/span>CI process<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
\n- A CI environment is the best place to execute<\/span>\u00a0<\/span><\/li>\n
- Test component is microservice (scope is limited to a microservice)<\/span>\u00a0<\/span><\/li>\n
- SonarQube and Kiuwan<\/span>\u00a0are best examples tools\/frameworks<\/span>\u00a0<\/span><\/li>\n
- Exit criteria is as per the tool or team recommendations but surely without blocker\/critical issues<\/span>\u00a0and<\/span>\u00a0with\u00a0<\/span>fewer<\/span>\u00a0violation<\/span>s<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
Quality Gate 3: Publish the Consumer Contracts<\/span><\/b>\u00a0<\/span><\/p>\nThis is the first step of contract testing where you will generate the contract as a consumer and publish them to the provider.<\/span>\u00a0<\/span><\/p>\nThings to consider:<\/span><\/b>\u00a0<\/span><\/p>\n\n- This must be\u00a0<\/span>a<\/span>\u00a0part of\u00a0<\/span>the\u00a0<\/span>CI process<\/span>\u00a0<\/span><\/li>\n
- A CI environment is the best place to execute<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
\n- PACT is the best tool\/framework, it acts as a mock<\/span>\u00a0<\/span><\/li>\n
- Exit criteri<\/span>on<\/span>:\u00a0<\/span>I<\/span>t must\u00a0<\/span>undoubtedly achieve\u00a0<\/span>100% pass\u00a0<\/span>rate\u00a0<\/span>as you cannot let the provider verifying the previous versions of contracts<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
Post this Quality Gate, the Docker images<\/span>\u00a0or the build and artefacts<\/span>\u00a0for the service<\/span>,<\/span>\u00a0and its dependant modules are generated so that the\u00a0<\/span>build\/<\/span>image is used to deploy into various environments.<\/span>\u00a0<\/span>CI can\u00a0<\/span>be\u00a0<\/span>automated such that the\u00a0<\/span>Docker<\/span>\u00a0image<\/span>\/build<\/span>\u00a0<\/span>is\u00a0<\/span>automatically deployed to the\u00a0<\/span>other<\/span>\u00a0environments.<\/span>\u00a0<\/span><\/p>\nQuality Gate 4: Execute Integration Tests<\/span><\/b>\u00a0<\/span><\/p>\nOnce\u00a0<\/span>you<\/span>\u00a0have the\u00a0<\/span>build(s)<\/span>\u00a0of a microservice and its dependencies<\/span>,<\/span>\u00a0it is good to deploy all of them\u00a0<\/span>for getting\u00a0<\/span>integrated into a Dev environment or Integration Test Environment<\/span>. Here<\/span>\u00a0QA\u00a0<\/span>teams must ensure th<\/span>at the<\/span>\u00a0infrastructure team helps\u00a0<\/span>with the setup<\/span>\u00a0to run Integration Test Suites.<\/span>\u00a0<\/span><\/p>\n