Bridging the Gap from backend to frontend with Datadog RUM | Part 3

Part 3: Shifting left to be more proactive in frontend monitoring with CI/CD integration

This is part 3 of a 3 part series in my attempt to learn more about frontend development through observability. If you have not read part 1 and part 2, it is recommended to get started there before continuing here.

Shifting Quality Assurance (QA) Left in CI/CD

The “Shift Left” approach in CI/CD is transforming software development. Instead of waiting until the end of the pipeline, QA activities are moved earlier in the process. This shift catches issues sooner, improves code quality, and streamlines software delivery. This article explores the principles, benefits, and real-world applications of “Shift Left” in QA.

Connecting the Dots

In Part 1, we’ve seen how RUM is able to give performance, analytical insights to your frontend application.

I started off wanting to bridge the gap from backend to frontend. In Part 3, we will take a look at how easy it is to “build this bridge” by using Datadog’s Browser Synthetics and integrating it to CI/CD workflows.

Synthetics UX Test

Synthetics Browser Test serves as a way to help organisations to be more proactive in testing/monitoring your applications.

There is Synthetics for API tests as well, but in this post, we will be focusing on browser testing. There are many tools out there when it comes to the automation of your browser tests. For instance, Selenium, Cypress, BrowserStack, PlayWright, Puppeteer, etc. This post is not meant to deep dive into Datadog’s Synthetics Browser Test, but you could read more about it here. It is interesting that Datadog offers a “Self-maintaining browser test”. This is going to help with your team’s refactoring effort when it comes to QA testing.

For the TicTacToe application, I’ve created a really simple “golden flow” to test that if user wins, there should be a prompt showing “Player Wins”.

GIF showing Synthetics Test Details

• Support for various browsers and device types. This is especially useful for browser and device compatibility tests where it is important to test if your application behaves as expected on various browsers and device tests.
• Support for various managed locations. This allows you to not manage the synthetics location. Having various locations also allows you to conduct performance related testing from various geographical locations to understand latency.
• Test scheduling. You will be able to run this test on a schedule if you want to trigger it on a time basis.
• Notifications. You will be able to set up notifications to your communication channels like Slack, JIRA, Teams, PagerDuty, just to name a few to get alerted if a synthetics test fails.

Datadog’s Synthetic Browser Test

• From the image above, you can see a low code approach (recording based approach) when it comes to scripting the user flow.
• At step 6, I am asserting that the content should have “Player X wins!”
• Notice how there is an option to collect RUM data at the top left. This allows me to collect RUM related telemetry (including everything we saw earlier in part 1 and 2) through synthetics testing.

Datadog RUM through Synthetic Browser Test

• As we’ve indicated to collect RUM data for test, we will also be able to utilise the RUM feature on synthetics browser test to understand frontend vitals, analytics, performance during your QA cycle. This will allow you to capture any optimisation opportunities before releasing your application to production.

RUM from Synthetics Browser Test

Shifting Left with CI/CD integrations — Datadog Continuous Testing

• Instead of triggering the tests with Datadog’s scheduler, you could also trigger synthetics test through a CI/CD provider. This will allow you to incorporate QA tests into your CI/CD pipelines to achieve a more proactive approach in monitoring.

For example, you could use the asserted result to decide if you want to trigger a rollback as part of your CD process. This is going to help save time and automate your CD flows.

• In this example, I will be using GitHub Actions to show you how easy it is to achieve this. But you can also refer to this documentation to learn more about how Datadog can integrate with other CI provider.

• Every synthetic test comes with a public_id, you will just need to configure the Github Actions workflow to call a public_id.

Step from Github Actions — Triggering Synthetics

Continuous Testing UI from Datadog

• Execution Rule “blocking” in this case means that if the Synthetics Test returns as fails, the next part of the CI/CD workflow can be blocked. You can read more here.
• With this integration set up, you’ve seen how easy it is to achieve Shift Left for your QA with the usage of Synthetics.
• On top of that, you will still be able to obtain RUM data from the Synthetics Browser Test that was ran.

Conclusion

Thank you for staying throughout the 3 part series. I hope that it gives you more insight into frontend observability, as well as how this can actually complement your current DevOps processes.

That’s all folks. Till then!