-
Notifications
You must be signed in to change notification settings - Fork 918
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
Direct traffic at CRO sandbox versions of pages #7652
Comments
Initial architecture doc for reference: https://docs.google.com/document/d/1RXzBVUk3LSbyBeJOesPrKcekvA5bOUBiUIiQy7frHgQ/edit#heading=h.ui1wp7dez36o |
Depends on #7508 |
Sandbox pages with experimental tool behind
Server-side redirect solution may be preferable? Maybe convo with @jgmize ? |
Please see mozmeao/infra#1050 for some links and an example of how Cloudflare workers might help with this. |
Another requirement for this solution should be that it does not interfere with our functional test runs. Either it should only execute on www.mozilla.org / www.allizom.org domains (where it already won't interfere), or alternatively we could build a mechanism whereby our test runs can opt-out on incurring redirects. |
FYI for anyone without access to the above doc, "CRO" stands for "Conversion Rate Optimization". The more you know 🌈 |
Anyone at Mozilla should have access to this doc ^ |
This page is fully public, and that doc is not. That's why I was trying to keep everyone up to speed. I had to login to look at the doc to learn what "CRO" meant, so I was just trying to help others. |
@pmac the term CRO not being explained in the title of this issue, and the reason this doc is not public are, I feel, two separate issues. I’d be happy to discuss this with you in person, but I don’t feel async here is likely the appropriate place. |
Fair enough. I just assumed since the issue was public and this repo has 115 watchers and 851 stars as of this comment that people would appreciate some explanation, like I wanted since this whole thing made no sense w/o context. If things need to be private that's fine, but it's also a capability we have with confidential bugzilla flags. |
Whether we use confidential bugs in bugzilla, or an employee only gdoc - it will likely turn up here in GitHub, linked in some way, as that’s currently the nature of how we track progress of our work. But as I say, this feels like a different discussion as to why the meaning of CRO was not originally explained. Again, i’d be more than happy to discuss this with you in person, rather than here where we can concentrate on discussing the issue at hand. |
@jgmize just talked to @hoosteeno and we'd like to test out using cloud workers on staging, providing a) you have some time & availability to work on it, and b) it's not a high level of effort / from yourself (it didn't sound like it from our meeting, but just to double check). Happy to discus further in person if it helps. |
@alexgibson and I just had a short pairing session where we experimented with temporarily deploying some code generated with http://sloth.cloud to www.allizom.org. Unfortunately sloth couldn't generate exactly what we wanted for this, so we will need to write a bit of custom code to conditionally return a 302 redirect from https://www.allizom.org/en-US/firefox/new/ to https://www.allizom.org/en-US/exp/firefox/new/ a small percentage of the time while preserving query params. We plan on working on this together again on Monday. |
I wrote some pseudo-ish code that could serve as a redirector here: https://gist.github.com/alexgibson/3425f57088d6fde02b6f0797eb738e08 This is aimed at the browser, but hopefully something we can adapt easily enough for a worker environment. |
Both myself and @jgmize paired on another session today and we we're able to modify the code linked above in the gist to run in a cloudflare worker. We spent some time testing the redirector on stage and it seemed to be performing as expected. Next steps:
Once the above is complete, I think we're good to do a full end-to-end experiment test on stage. |
My apologies for this tangent, but this talk of cloudflare workers has me curious: could such a worker be a better solution for our GEO redirects for whatsnew and others? Can a worker use the country of request origin as a data point in its logic? |
@pmac yes, there's an example of doing exactly that here: https://developers.cloudflare.com/workers/templates/?q=count |
Nice. I'm interested to see how the development and deployment automation for CF workers goes then. It'd be a nice way to accomplish these kinds of things, and much more compatible with moving to a more static deployment w/o sacrificing features. |
We set up a new repo called www-workers, and I've submitted a PR for the redirector code: mozmeao/www-workers#1 |
The code for this now lives at https://github.com/mozmeao/www-workers and is running on stage. @jgmize still has some infra work to do with automation in that repo, which is detailed here: mozmeao/www-workers#2 On that basis, I'm going to close this particular issue and followups can be discussed in the www-workers repo. |
Description
After we have copies of some content in the CRO sandbox, we should build any tooling that we will require to direct some traffic to those copies. This may mean using TrafficCop, perhaps with some standardized settings, or it may mean something else.
💛 Success Criteria 💛
Tasks
The text was updated successfully, but these errors were encountered: