How do you update one side of a MySQL master-master replication setup?
At my company we run MySQL with circular replication. We do not stop replication during a deploy of either the app or schema changes.
We must restart MySQL Server during upgrades or some configuration changes, and replication naturally stops when the server stops, but we bring it back up immediately.
We use pt-online-schema-change to run schema changes without making the app lose access to the database. Apps can still run read or write queries while the schema change is running. It's not perfect; it requires a brief lock at the beginning and end of the task, and you can't have triggers on your table. Also it adds a significant query load to the database server while it's restructuring a table, and this may be enough to slow down the app (it depends on how sensitive the app is to load). But mostly it allows the app to continue working without requiring any downtime.
For the app deployments, we use multiple app servers in each datacenter. A deployment knows how to stop the app instances in a &quot;rolling&quot; manner so there's always a minimum number of them running during the deploy. So there's no need to swing traffic to the opposite datacenter.
Because app deployments and schema deployments are both asynchronous and hard to run absolutely together, the code and schema changes must be designed carefully so both the old and new code versions will work with both the old and new schema versions. For example:

No code can use SELECT * ... or INSERT INTO mytable VALUES(...) because if the schema change adds or drops a column, it would break the code.
Some schema deployments must be done in stages, for example add a new column and finish that deployment before any code can reference the new column.
Renames of columns or tables are forbidden, because it causes a chicken-and-egg problem.

With redundant app servers, online schema change tools, and a few modest restrictions on code style, almost all deployments can be done without downtime.