-
Notifications
You must be signed in to change notification settings - Fork 963
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
Stop having a "staging" environment #918
Comments
This is "done" in the sense that warehouse-staging.python.org is no longer staging but is a production environment and committing to |
This is at best a new feature, and is more like an idea. |
@brainwane this will require all kinds of other work to support closing the issue:
It's a bit larger than just "turn it off" we can't do that until there's a way for folks to test workflows on PyPI itself as well as deployment changes internally. |
Thanks for detailing that and sorry for misunderstanding, @ewdurbin. Maybe sometime this spring (maybe at the sprints at PyCon?) we can break this out into sub-issues and spec them out. |
Currently TestPyPI acts as two things, one is an environment for end users to upload copies of their software to to test their release processes and act as a sort of general sandbox for their testing and the other is a staging environment for changes to go through and get tested in.
I'm not going to include the entire post, but in @alex's recently blog post Don't have environments he makes the case that having explicit environments like this is a bad idea. He describes a scenario that truthfully has played out with PyPI legacy multiple times and although it has not happened for Warehouse, it's possible (likely?) that once we start having a large number of users hitting the code and actually caring about errors in production or broken features that we'll run into it here as well.
So in that vein, it may be a good idea to stop using TestPyPI as a staging environment and instead have
master
automatically deploy to both TestPyPI and PyPI. We currently have the ad hoc rule thatmaster
should be able to be deployed to PyPI at any time, but there is nothing really enforcing like.. actually deployingmaster
to production immediately would.If we do this, we'll need a few items to make it actually pratical:
Doing this would mean that TestPyPI only exists for end users to use as a sandbox. We could possibly even get rid of TestPyPI completely if we implemented something like #726 which might (probably?) provide a better UX around testing releases in general.
The text was updated successfully, but these errors were encountered: