What to read in order to collect as few rakes as possible during deployment?

Question

git

In general, I set out to make a normal deployment of the application to production in the company.
Now the work is going like this:
1) Do I need to change something?
2) We go to the server and change. As an option - we change through all sorts of PhpStorm connecting via sftp / ftp.
The project itself is written in PHP.
Agree - not a very good option.
What I want:
1) All developers work through git. It basically is. Raised bitbucket - I don't see anything complicated.
2) Laying out changes if they are available in the repository. TeamCity does a great job with this. there is not much load, so there is no problem. One side. But on the other hand, I'm interested in HOW to make sure that the project does not stop? So far, I have settled on the option with deployment to the left folder and rsync between these two folders. Not sure if it's a good option either. But it seems to work as it should.
3) Rollback of changes in case of a jamb. Here, there are no thoughts at all. Rollback should be available "on the button". Those. pressed the button - rollback occurred. If necessary (ideally) - you can choose the version to which to roll back.
A good friend advised me to look at Docker. But I'm interested in what and how to look there.
On the one hand, it seems to be convenient. On the other hand, it is not entirely clear how it all works and how different project modules are connected to each other.
Hmm... and what to do with rollbacks of changes? How should it look?

Answer 1

Make version folders
Project folder symlink to version folder
Instant symlink change

Answer 2

You can use the service deploybot.com

Answer 3

2 and 3 are easily solved by specifying the nginx / apache rotation through a symlink, with the storage of all or the latest deployed versions in separate nearby directories, as Evgeny Bezymyannikov pointed out , but only in cases where there is no database schema, or if it does not change, or if the application works fine with different versions of the schema, without crashing with errors like "no table / field" (within reason).
Otherwise, you can quickly resolve the issue only with stopping the project for the duration of the migration, if the database does not support a non-blocking schema change or supports it, but not for multiple changes in one transaction, and the project requires multiple ones, such as moving a column from one table to another. In such cases, for SQL databases, I did not find a way to implement zero-downtime without reworking the application (triggers, storages, views, etc. are also part of the application) such that it either temporarily (while the old data is syncing in the background) writes in two bases, reading from the old one, or determines which version of which tables is available to it.
The problem is that in any loaded application that constantly writes something to the database, you cannot instantly get the mapping of the old one in the new database without intermediate versions of the application working with two databases at the same time. That is, in essence, the zero-downtime deployment of a new version of the application is divided into a deployment of two versions - the first (intermediate) works with two versions of the database (of course, with a drop in performance), in the second, work with the old ones is disabled when the data of the two databases are completely synchronous ..