feat(posts): add blog post to expose the architecture of our web homologation stack#480
Conversation
|
This pull request is automatically being deployed by Amplify Hosting (learn more). |
| title: "Building a Scalable, Multi-Tenant Homologation Stack at Bedrock Streaming" | ||
| description: "We share here QA context,key takeaways and architecture decisions and reveal the architecture of the Web homologation stack." | ||
| tags: [frontend, playwright, qa, web] | ||
| author: [m_bayard] |
There was a problem hiding this comment.
| --- | ||
| layout: post | ||
| title: "Building a Scalable, Multi-Tenant Homologation Stack at Bedrock Streaming" | ||
| description: "We share here QA context,key takeaways and architecture decisions and reveal the architecture of the Web homologation stack." |
There was a problem hiding this comment.
| description: "We share here QA context,key takeaways and architecture decisions and reveal the architecture of the Web homologation stack." | |
| description: "We share here QA context, key takeaways and reveal the architecture of the Web homologation stack." |
| description: "We share here QA context,key takeaways and architecture decisions and reveal the architecture of the Web homologation stack." | ||
| tags: [frontend, playwright, qa, web] | ||
| author: [m_bayard] | ||
| cover: /assets/images/ |
| feature-img: "/images/posts/" | ||
| thumbnail: "/images/posts/" |
| QA engineers are therefore a critical resource responsible for assessing product quality and ensuring high standards through continuous validation and homologation\*. | ||
|
|
||
| \*For clarity, homologation specifically involves the rigorous, final assessment of a release candidate (RC). This process entails fully testing the RC across a matrix of multi-client configurations (customer-specific data/settings) and multi-browser environments on an iso-production environment before deployment. |
There was a problem hiding this comment.
I would remove the *, which I think disrupts the reading
| QA engineers are therefore a critical resource responsible for assessing product quality and ensuring high standards through continuous validation and homologation\*. | |
| \*For clarity, homologation specifically involves the rigorous, final assessment of a release candidate (RC). This process entails fully testing the RC across a matrix of multi-client configurations (customer-specific data/settings) and multi-browser environments on an iso-production environment before deployment. | |
| QA engineers are therefore a critical resource responsible for assessing product quality and ensuring high standards through continuous validation and _homologation_. | |
| In your context, _homologation_ specifically involves the rigorous, final assessment of a release candidate (RC). This process entails fully testing the RC across a matrix of multi-client configurations (customer-specific data/settings) and multi-browser environments on an iso-production environment before deployment. |
| │ ├── interactivity.steps.ts | ||
| │ ├── visibility.steps.ts | ||
| │ │── ... | ||
| │ └── utils/ # Utility functions for steps (getValue() for multi-tenant config) |
There was a problem hiding this comment.
Speaking about getValue() function at this step can be confusing as we doesn't know what's its purpose
| │ ├── m6web/ # M6+ specific config | ||
| │ ├── .../ | ||
| │ ├── .../ | ||
| │ └── clientN/ # client N specific config |
There was a problem hiding this comment.
Don't include real customer code
| │ ├── m6web/ # M6+ specific config | |
| │ ├── .../ | |
| │ ├── .../ | |
| │ └── clientN/ # client N specific config | |
| │ ├── .../ | |
| │ ├── .../ | |
| │ └── clientN/ # client N specific config |
| │ └── translations.config.ts | ||
| ``` | ||
|
|
||
| ## 🔄 Data Flow Example: Multi-Tenant Magic |
There was a problem hiding this comment.
More a sub part of the architecture
| ## 🔄 Data Flow Example: Multi-Tenant Magic | |
| ### 🔄 Data Flow Example: Multi-Tenant Magic |
|
|
||
| Step receives the abstract key `"translation.account.menu.logout"`. | ||
|
|
||
| Step calls `getValue("translation.account.menu.logout")`. |
There was a problem hiding this comment.
| Step calls `getValue("translation.account.menu.logout")`. | |
| Step calls a utils function `getValue("translation.account.menu.logout")`. |
| **What's next:** | ||
|
|
||
| More AI and bring the automated testing to the age of agentic. | ||
|
|
||
| Merge the testing approach with our developers. |
There was a problem hiding this comment.
| **What's next:** | |
| More AI and bring the automated testing to the age of agentic. | |
| Merge the testing approach with our developers. | |
| **What's next:** | |
| - More AI and bring the automated testing to the age of agentic. | |
| - Merge the testing approach with our developers. |
| @@ -0,0 +1,167 @@ | |||
| --- | |||
| layout: post | |||
| title: "Building a Scalable, Multi-Tenant Homologation Stack at Bedrock Streaming" | |||
There was a problem hiding this comment.
I fear that "Homologation" is not well understood (admittedly it is defined further on, but it can be confusing here). What do you think about :
"Building a Scalable, Multi-Tenant QA Automation Stack at Bedrock Streaming"
It emphasizes that the post focuses on QA teams and automation.
There was a problem hiding this comment.
Yes that makes sense for the title of the blog post 💯
| | [Playwright](https://playwright.dev/) | Browser Automation Engine | Speed and Reliability: Unified API for all major browsers (Chromium, Firefox, WebKit), mobile emulation, and excellent DX. | | ||
| | [playwright-bdd](https://vitalets.github.io/playwright-bdd/#/) | BDD Framework (Gherkin) | Collaboration and Readability: Enables tests to be written in a natural, shared language while managing Playwright test generation. | | ||
|
|
||
| Note: our dictionary of steps is greatly inspired by [uuv](https://github.com/Orange-OpenSource/uuv) which aims to provides an ecosystem that simplifies the writing of End-to-End tests in a BDD approach and a user-centric way and accessibility-first selectors. |
There was a problem hiding this comment.
To have a more dynamic layout like

| Note: our dictionary of steps is greatly inspired by [uuv](https://github.com/Orange-OpenSource/uuv) which aims to provides an ecosystem that simplifies the writing of End-to-End tests in a BDD approach and a user-centric way and accessibility-first selectors. | |
| > ℹ️ Note: our dictionary of steps is greatly inspired by [uuv](https://github.com/Orange-OpenSource/uuv) which aims to provides an ecosystem that simplifies the writing of End-to-End tests in a BDD approach and a user-centric way and accessibility-first selectors. |
| **1. Feature Files (BDD Layer)** | ||
| Path: `features/@desktop/` & `features/@webview/` | ||
| Categorized by domain: `@core` (navigation), `@player` (VOD/Live), and `@ulc` (account/payment). | ||
|
|
||
| **2. Step Definitions (Glue Layer)** | ||
| Path: `features/steps/\*.steps.ts` | ||
| Standardized user actions (When) and assertions (Then) such as visibility.steps.ts or authentification.steps.ts. | ||
|
|
||
| **3. Utilities (Implementation Layer)** | ||
| Path: `features/steps/utils/\*.utils.ts` | ||
| The "brains" of the operation, including config.utils.ts for multi-tenant data retrieval and player.utils.ts for video interactions. | ||
|
|
||
| **4. Configuration (Multi-Tenant Layer)** | ||
| Path: `config/{customer}/` | ||
| Where the magic happens. This layer stores customer-specific account.config.ts, translations.config.ts, and environment URLs. |
There was a problem hiding this comment.
Try this:
| **1. Feature Files (BDD Layer)** | |
| Path: `features/@desktop/` & `features/@webview/` | |
| Categorized by domain: `@core` (navigation), `@player` (VOD/Live), and `@ulc` (account/payment). | |
| **2. Step Definitions (Glue Layer)** | |
| Path: `features/steps/\*.steps.ts` | |
| Standardized user actions (When) and assertions (Then) such as visibility.steps.ts or authentification.steps.ts. | |
| **3. Utilities (Implementation Layer)** | |
| Path: `features/steps/utils/\*.utils.ts` | |
| The "brains" of the operation, including config.utils.ts for multi-tenant data retrieval and player.utils.ts for video interactions. | |
| **4. Configuration (Multi-Tenant Layer)** | |
| Path: `config/{customer}/` | |
| Where the magic happens. This layer stores customer-specific account.config.ts, translations.config.ts, and environment URLs. | |
| **1. Feature Files (BDD Layer)** | |
| Path: `features/@desktop/` & `features/@webview/` | |
| Categorized by domain: `@core` (navigation), `@player` (VOD/Live), and `@ulc` (account/payment). | |
| **2. Step Definitions (Glue Layer)** | |
| Path: `features/steps/\*.steps.ts` | |
| Standardized user actions (When) and assertions (Then) such as visibility.steps.ts or authentification.steps.ts. | |
| **3. Utilities (Implementation Layer)** | |
| Path: `features/steps/utils/\*.utils.ts` | |
| The "brains" of the operation, including config.utils.ts for multi-tenant data retrieval and player.utils.ts for video interactions. | |
| **4. Configuration (Multi-Tenant Layer)** | |
| Path: `config/{customer}/` | |
| Where the magic happens. This layer stores customer-specific account.config.ts, translations.config.ts, and environment URLs. |
|
|
||
| **3. Utilities (Implementation Layer)** | ||
| Path: `features/steps/utils/\*.utils.ts` | ||
| The "brains" of the operation, including config.utils.ts for multi-tenant data retrieval and player.utils.ts for video interactions. |
There was a problem hiding this comment.
I don't think it's relevant to mention the filename config.utils.ts and player.utils.ts which can be quite confusing for the reader. I suggest:
| The "brains" of the operation, including config.utils.ts for multi-tenant data retrieval and player.utils.ts for video interactions. | |
| The "brains" of the operation, including some functions for multi-tenant data retrieval and video interactions. |
|
|
||
| **Requirements and rationale behind** | ||
|
|
||
| - Natural Language BDD (Gherkin): This is a key enabler for collaboration. |
There was a problem hiding this comment.
For dynamic reading:
| - Natural Language BDD (Gherkin): This is a key enabler for collaboration. | |
| - **Natural Language BDD (Gherkin)**: This is a key enabler for collaboration. |
|
|
||
| - Easy Review: Allows QA Engineers, Product Owners (POs), and Developers (DEVs) to easily read, review, and contribute to the test specifications without needing deep coding knowledge. | ||
|
|
||
| - Multi-Client / Multi-Platform Support: Leveraging Playwright's power, our stack should inherently supports validation across: |
There was a problem hiding this comment.
| - Multi-Client / Multi-Platform Support: Leveraging Playwright's power, our stack should inherently supports validation across: | |
| - **Multi-Client / Multi-Platform Support**: Leveraging Playwright's power, our stack should inherently supports validation across: |
| - Multiple Platforms (desktop and mobile browsers). | ||
| - Multiple apps / projects. | ||
|
|
||
| - Codebase Integration (the shift): The homologation application is part of the main Web codebase. |
There was a problem hiding this comment.
| - Codebase Integration (the shift): The homologation application is part of the main Web codebase. | |
| - **Codebase Integration (the shift)**: The homologation application is part of the main Web codebase. |
| Step receives the abstract key `"translation.account.menu.logout"`. | ||
|
|
||
| Step calls a utils fonction `getValue("translation.account.menu.logout")`. | ||
|
|
||
| Config resolves to the specific customer's value (e.g., `"Kijelentkezés"` for one customer, `"Logout"` for another). | ||
|
|
||
| Playwright locates the element with that specific text and validates visibility. |
There was a problem hiding this comment.
Maybe more readable:
| Step receives the abstract key `"translation.account.menu.logout"`. | |
| Step calls a utils fonction `getValue("translation.account.menu.logout")`. | |
| Config resolves to the specific customer's value (e.g., `"Kijelentkezés"` for one customer, `"Logout"` for another). | |
| Playwright locates the element with that specific text and validates visibility. | |
| - Step receives the abstract key `"translation.account.menu.logout"`. | |
| - Step calls a utils fonction `getValue("translation.account.menu.logout")`. | |
| - Config resolves to the specific customer's value (e.g., `"Kijelentkezés"` for one customer, `"Logout"` for another). | |
| - Playwright locates the element with that specific text and validates visibility. |
| - AI and BDD: The structured, human-readable format of Gherkin makes it an ideal input for future AI agents. | ||
| - CI/CD In Action: Automated tests are integrated into our CI pipeline, ensuring quality gates are enforced before any release proceeds. | ||
| - The Human Factor: We’ve transformed the QA role. By transitioning to "Quality Architects," our engineers now own the automated patrimony, supported by targeted training to bridge the gap between manual testing and code. |
There was a problem hiding this comment.
| - AI and BDD: The structured, human-readable format of Gherkin makes it an ideal input for future AI agents. | |
| - CI/CD In Action: Automated tests are integrated into our CI pipeline, ensuring quality gates are enforced before any release proceeds. | |
| - The Human Factor: We’ve transformed the QA role. By transitioning to "Quality Architects," our engineers now own the automated patrimony, supported by targeted training to bridge the gap between manual testing and code. | |
| - **AI and BDD**: The structured, human-readable format of Gherkin makes it an ideal input for future AI agents. | |
| - **CI/CD In Action**: Automated tests are integrated into our CI pipeline, ensuring quality gates are enforced before any release proceeds. | |
| - **The Human Factor**: We’ve transformed the QA role. By transitioning to "Quality Architects," our engineers now own the automated patrimony, supported by targeted training to bridge the gap between manual testing and code. |
|
|
||
| - More AI and bring the automated testing to the age of agentic. | ||
|
|
||
| - Merge the testing approach with our developers. |
There was a problem hiding this comment.
| - Merge the testing approach with our developers. | |
| - Align the testing approach with our developers, who already have an automated E2E testing stack for Pull Request validation (currently based on [WebdriverIO & CucumberJS](https://tech.bedrockstreaming.com/2021/09/06/web-best-practices.html#our-e2e-tests)). |
Co-authored-by: Florent Dubost <florent.dubost@gmail.com>

🎭 First QA blog post about our homologation stack