Hacker News new | ask | show | jobs
by swaranga 1436 days ago
Onebox deployment typically deploys the new revision of the application code to a single host/box and leaves the rest of the fleet in the older revision and then you run your tests against the new revision running in that single box. You also might monitor the metrics from that single box and attempt to find regressions from the rest of the fleet.

If the code is deployed to the database (version controlled or not) all application servers will start using the new code immediately which is not what we would want from a onebox deployment first strategy. Usually all the servers will share the same database and thus the code in the code in database model. What am I missing.
2 comments
anonymous23801 1436 days ago
You could easily create a new revision of the function you want to change, and have the first box to use the new revision while the rest keep using the old one.

In postgres that would be trivial with revision schemas and a clever usage of the SEARCH_PATH.

link
swaranga 1432 days ago
Sure, it works for a narrow use-case like a pure function that just queries and returns data. What about stored procedures/triggers that mutate data on insert/delete etc?

With one-box, you can assign a specific set of customers/canaries to be served by the new 1-box and validate your results. If there is a problem you rollback and only your canary data was affected. It is just not very simple IMO.

link
Smeevy 1436 days ago
That is a neat idea. I was sort of thinking of that, but was concerned about invalid and unused database objects.

You'd avoid name collisions pretty handily, though. I'm guessing that you would just need some policy to drop all of the old versions after some period.

You'd also just need to bundle grant exec statements with the procedure DDL.

That would work well with Oracle and DB2 as well. I'm not totally sure about SQL Server, though.

link
Smeevy 1436 days ago
Ah. I see my misunderstanding. This is my fault for trying to think at 4am.

That is a bit trickier. You will absolutely not be able to do that without computing stored procedure names using a version number, which seems awful and not worth the trouble.

That said, you can avoid application errors during rollout by keeping procedure signatures the same and not removing columns from returned result sets. The unfortunate side effect is that errors in your procedures can work with the new nodes and cause errors in the previously functional ones. Although, I guess you already had that potential exposure with any other database schema change that was made, right?

link