[PATCH] Proof-of-concept of a dual PHP–Python stack

[Frédéric Mangano-Tarumi]

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.