Filipe Laíns [2020-03-15 13:50:39 +0000]
Not really, we just put it in maintenance mode -- no more features just bugfixes.
That won’t benefit the end user, but if we manage to port the code fast enough I guess it’s a compromise. There’s still the second point though: stability.
We can deploy it to aur-dev.archlinux.org and have users test it before we deploy it to the real website.
Staging deployments help detect the bigger bugs, but we should still expect a little portion to be discovered only in production. How about a 2-month release cycle where aur-dev is one release ahead production?
The reason I don't want to deploy it to the real installation right away is mainly because we are changing the database structure. The plan is to move to SQLAlchemy (you already have a patch for this) and then start implementing the Flask app. If we mess something up in the database backend and it does not become apparent at me moment, we are screwing up the production database.
So far aurweb only uses SQLAlchemy Core, which is a neutral Pythonic wrapper over SQL. Unlike SQLAlchemy ORM, it does not make decisions on the structure of the database or the operations to perform. For that reason, I doubt SQLAlchemy will ever be a cause of screw up, but if we’re uncertain we can pass it the raw SQL PHP currently uses, and modernize it later on. When I made the SQLAlchemy schema, I double-checked to make sure SQLAlchemy uses the exact same structure as before, though I must admit I can’t guarantee the production database is perfectly identical to my local deployment. I can check it if you send me a structure dump of the production database. In any case, we won’t run initdb on the production server, and even if the new schema were to differ, at worst we’d get an SQL error. Databases are good at detecting that. Alembic is probably a much bigger factor of risk since database migrations do alter the structure. However, regardless of when we deploy it, every single new migration is equally risky. Please also note that Alembic uses the SQLAlchemy only for assisting migration generation, and that the SQLAlchemy migration of our Python code is completely independent from the use of Alembic as far as production is concerned. More generally, I think deploying everything at once or incrementally won’t affect the possibility of data screw ups. It’s mostly a matter of how thoroughly each individual piece of code is tested. Deploying incrementally helps focus on specific parts at a time, which I believe is an advantage over having users test everything without a plan. If our testers are overwhelmed by changes, it’s gonna make it harder for them to notice oddities.