How do you develop and maintain sites on Worpdress?

Question

Software Deployment

I want to set up a convenient and automated process for creating, deploying and maintaining sites on WP.
Below I will describe how I imagine it.
All automation is done using Ansible
. We have 3 servers:
development - this is Linux running in virtuabox on the developer's local machine
staging - hosting server on which the site / changes will be expressed before uploading to production
production - this is the combat server from which the site will be available.
The servers have the same configuration, which is configured using Ansible.
Each server has 2 users:
admin - with superuser rights. It is needed to configure and administer the server
developer - without superuser rights. It is needed to upload the site / changes to the server.
Steps to create a new site:
1) Using the CLI, enter the site name, url (the only step is manual, the rest is done automatically)
2) A GIT repository is created
3) An Nginx / Apache host is created on each server
4) Databases are created, on the development server - 1 , for staging and production 3 each (active, inactive, wait).
5) Deploy copies of Wordpress using wp-cli on each server.
6) Done.
On production and staging servers, backups of code, images and plugins and databases are made before each deployment.
Backups (releases) are stored on the server for the last two weeks.
host root points to the desired release directory with a link.
The rest of the backups are stored in Yandex.Disk, which is connected via WebDAV.
Steps for a full deployment (project files and database) to production/staging:
1) On the development server, a database dump and an archive with all project files
are created 2) On the production server, a backup of all files is made, an active database is dumped (the database that is destroyed on the site), all this is placed in the releases directory and in the cloud
3) On production, the project files from development are copied and unpacked into the releases directory and the host root link points to the directory of this release
4) The database dump from development is imported into the database with the name wait on the production server.
5) On the production server, the active database is renamed to inactive
6) On the production server, the wait database is renamed to active
7) Done
I don't really like the leapfrog with renaming databases. There is an idea to have 2 databases and switch between them using wp-config
I'd love to hear suggestions and suggestions for improvement.
I also want to know how others do it.

Answer 1

In general, everything is ok, the difference will always be in some nuances. Depending on the type of project, there will be more or less nuances. We have a plus or minus like this:
- Local development on macOS + Laravel/Valet (Nginx, PHP 7+, MariaDB, Redis/Memcached).
-Staging/production can be either separate servers or located on the same server, and there can also be many sites on the same server, or it may not be our server, but some kind of Kinsta or even a client infrastructure to which we do not have access . Therefore, the devops kitchen is generally separated. From our side, only auto-deploy from turnip via CI / CD. branch develop -> staging, branch master -> production.
- WordPress, plugins, theme, and all custom code are project dependencies managed by Composer.
- Working with WordPress functionality is built entirely on the command line using WP-CLI. If necessary, write your own commands for it.
- The entire project configuration in .env (base, keys, licenses, etc. that does not fall into git) and in the config folder in the form of PHP configurations (everything that already affects the functionality).
- Media files on the local are either not stored at all (Valet proxies requests for staging/production), or are synchronized with staging/production. This is done using a separate cli script that uses rsync under the hood.
- Databases - a separate story that depends very much on the specifics of the project. Somewhere it's a simple push/pull using WP Migrate DB, somewhere the same push/pull using WP-CLI, somewhere it's whole migrations. Ideally, you should try to take content from sale to stage and avoid publishing from dev / staging to production. But situations and projects are different, there is no one right answer.

Answer 2

it is enough for you to add wp-cli to your workflow,
this will greatly simplify the algorithm and there will be no need to change anything drastically