How to deploy edits?

Question

Software Deployment

How to upload edits to the server that affect the code and the database?
For example, you changed some block on the page, corrected the code, changed the content in the admin panel.
Now all this needs to be uploaded to the server. The code without a base will not work, the block that you ruled will be clumsily displayed. Conversely, the new version of the database will not work well with the old code. Yes, and the database cannot be completely updated, since since the dump was created, changes have been made to the production database (new articles, new comments have been added). I don’t really want to manually re-make changes to the database in production.
It turns out that you need to upload the new code and the database almost simultaneously (with a minimum interval) (only what has changed).
How do you solve this issue? How is deployment of new project features automated?

Answer 1

First, remember once and for all 2 simple truths:
1. The production database should only be in production and nowhere else. This data cannot be used as-is locally - including for legal and privacy reasons (hello customer logins and passwords, their personal data, etc.). Roughly speaking, for this you can suffer.
2. Local/development database only works with test/seed data.
There should never be any synchronization between them. From the word at all. And WordPress has nothing to do with it at all - this problem exists in Laravel, Symfony, Ruby on Rails, etc. It's just that from scratch they are immediately taught to solve it correctly. However, production data can (and even should) be used as an example for generating local data. For example, in a production database, you can see what real first name and last name are used by users to improve validation and / or display.
How to live with it?
1. Migrations are used to transfer database structure changes. WordPress has dbDelta() for this .
2. To transfer seed datacrops (seeds) are used. For example, if you need to fill in a list of terms in a glossary (custom taxonomy), fill in a list of company departments, etc. - all this is sown.
3. Everything else (mouse settings in the admin panel, adding content, etc.) is done by hand. Locally, you should not even think about creating some kind of 1 in 1 pages with the expectation that later you will somehow "synchronize" them to the production server. This is the fundamentally wrong mindset that led you to this problem. On the local version, you test everything with test data. Even if you do not use lorem ipsum, but insert real text provided by the client, this is still test data.
4. So that the site does not break in the process of rolling out changes (when the code is uploaded, and the content is still being done), the code must be written taking into account this logic (again, it's a matter of mindset). For example, there is such a thing as feature flags, there is function_exists(), there is isset(). Your code should always work correctly - for example, if the data for some block is not filled in, then the block is not displayed at all.

Answer 2

wordpress development with git

Answer 3

Envoy, deployer etc...
A new version is automatically created from the turnip and the link is updated.
You don’t have to climb into the database at all.
If you added a field / table, etc., this is done through migrations.
Of course, you can set up some kind of data replicas.
Naturally, everything should be tested by competent people on the dev server.

Answer 4

The database update is rolled and rolled back by migrations. There are plenty of mechanisms and tools for migrations, you can choose the right one.
Migrations can be rolled both with code and separately.
There is one useful rule that people like to neglect - the code must support the v and v-1 version base. Migration should also not break v-1 code compatibility when rolling. In this case, we can talk about a safe rollout of a new version, and a safe way to roll back.