Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DX: Implement DX for second contact #45

Closed
5 tasks done
BioPhoton opened this issue Apr 28, 2022 · 0 comments
Closed
5 tasks done

DX: Implement DX for second contact #45

BioPhoton opened this issue Apr 28, 2022 · 0 comments
Labels
DX Developer Experience

Comments

@BioPhoton
Copy link
Contributor

BioPhoton commented Apr 28, 2022

The "second contact" focuses on more advanced tests and CI integration.

It should focus on a good user experience from the CLI perspective, as well as a smooth setup of the GitHub action to integrate user-flow into the CI. This means the user should be guided by good documentation and maybe a command with questions and options to set it up.

In general this issue targets direct users of @push-based/user-flows, developer, performance engineers etc. that have user-flow already installed and running, but not implemented a real live integration.
This story is a follow up on #32

Furthermore it will help to separate the CLI and the GH action repositories.

Related repositories:

  • 💻 the CLI - @push-based/user-flow
  • ⚙ the CI Action - CI related code e.g. GitHub Action @push-based/user-flow-gh-action

Persona

Personal Data

Chris, 26, full-stack developer, self educated

Background

Needs an easy way to stop regression on an ongoing JS application. He tried user flow already #32 and remembered it after another uncaught regression in his live system.

Knowledge

He knows lighthouse and puppeteer, also knows user-flow.

Environment and Tooling

There are no performance tests in the application
There are very few tests in the CI

Second contact

Chris already tested out user-flow and was impressed by this new method of testing the performance of user actions. However, he only tested the basics and left it at that point as there was no more time.

Some 1,5 month later, while testing the performance of the application he was working on, he noticed the performance of the application got worse and he had to figure out why.

The app is pretty busy maintained from many developers and there is no good release management in place to track changes, nor any continuous performance measurement, so it was quite a hassle to spot the issue.

After all the issue was found, and additionally, not only the performance that had gotten worse, but had also a couple of SEO critical bugs introduced.
What a nice ending of that Friday... and hello to a weekend of cleaning up others mess.

In the middle of the next week, not quite recovered from the work intense weekend he started to reason about possible solutions to this unfortunately recurring problem and user-flow jumped in his mind again.

He suggested to set up using user-flow to avoid regressions, but the conversation with his CTO was unpleasant.
Just by looking at some GitHub repository and no clear time estimation on how much it takes to get it running it just got zero attention next to all the high priority tickets in the queue.

But Chris's curiosity got the best of him and he keep playing around with it, knowing that he could convince his CTO to implement user-flow if a PoC could catch some regression in the CI.

Problems from test run

To fix for second contact

To fix for third contact

  • Some action required the user to log in and it added unnecessary steps, plus I could figure out how to maintain the user logged in between different user flow test runs - fixed by docs: authenticated pages #20
  • To set up a new test I ended up duplicating a user flow file and modifying it.

DX to Implement

Next steps

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DX Developer Experience
Projects
None yet
Development

No branches or pull requests

1 participant