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

Stop having a "staging" environment #918

Open
2 tasks
dstufft opened this issue Jan 19, 2016 · 5 comments
Open
2 tasks

Stop having a "staging" environment #918

dstufft opened this issue Jan 19, 2016 · 5 comments
Labels
admin Features needed for the Admin UI (people running the site) feature request testing Test infrastructure and individual tests

Comments

@dstufft
Copy link
Member

dstufft commented Jan 19, 2016

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 that master should be able to be deployed to PyPI at any time, but there is nothing really enforcing like.. actually deploying master to production immediately would.

If we do this, we'll need a few items to make it actually pratical:

  • We'll need to enable Heroku Review Apps (however we'll need to ensure this is done safely). This will be made a bit more difficult since we tend not to use very many Heroku addons and instead bring our own services (often donated). Possibly we can just use free tier addons for this.
  • A solution to database migrations (Automatically Run Database Migrations #661).

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.

@dstufft
Copy link
Member Author

dstufft commented Jan 22, 2016

This is "done" in the sense that warehouse-staging.python.org is no longer staging but is a production environment and committing to master auto deploys to both it, and to warehouse.python.org. The other issues from above still need addressed.

@brainwane brainwane added this to the 4) Shut down legacy site milestone Jun 30, 2016
@nlhkabu nlhkabu modified the milestones: 4: Shut down legacy site, 3: Feature parity with PyPI Jul 1, 2016
@dstufft dstufft removed this from the 3: Shut Down Legacy PyPI milestone Jul 1, 2016
@dstufft
Copy link
Member Author

dstufft commented Jul 1, 2016

This is at best a new feature, and is more like an idea.

@nlhkabu nlhkabu added the requires triaging maintainers need to do initial inspection of issue label Jul 2, 2016
@brainwane brainwane added feature request testing Test infrastructure and individual tests admin Features needed for the Admin UI (people running the site) and removed requires triaging maintainers need to do initial inspection of issue labels Feb 5, 2018
@brainwane
Copy link
Contributor

@ewdurbin now that we've fixed #661, the only checkbox remaining from Donald's original post in this issue is the Heroku stuff. Is that still applicable? Can we close this?

@brainwane brainwane added this to the 6. Post Legacy Shutdown milestone Feb 5, 2018
@ewdurbin
Copy link
Member

ewdurbin commented Feb 6, 2018

@brainwane this will require all kinds of other work to support closing the issue:

  • Feature Deploys/Review Labs functionality
  • Staged releases for users
  • Doc purge of "testpypi" and "test.pypi.org"
  • Possibly a deprecation window

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.

@brainwane
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
admin Features needed for the Admin UI (people running the site) feature request testing Test infrastructure and individual tests
Projects
None yet
Development

No branches or pull requests

4 participants