Git on a production server?

S

Sergey Durov2017-09-13 23:19:52

Web development

Sergey Durov, 2017-09-13 23:19:52

The current situation with updating the production server is tormenting me.
At the moment it looks like this -
- development in a separate branch, push to the production branch
- go to the server (or through factories) do git pull, roll migrations if necessary, and collect statics.
But if something goes wrong, then the server is down, users complain, so I'm doing everything wrong.
I already thought how to do everything with archives, but it’s absolutely not convenient, plus migrations still need to be rolled.
Question - how do you update the application on the production server and how do you make database migrations painless?

Reply

Answer the question

In order to leave comments, you need to log in

6 answer(s)

D

developer_as, 2017-09-13
@developer_as

Convenient for using Capistrano. I can't judge for others. closely only worked with this system. Release versions are stored on the server and, if necessary, you can quickly roll back the code. Also, with each release, you do not need to go to the server and do a pull.

A

Alexey Kotenko, 2017-09-13
@k0t3n

There is such a wonderful thing as CI (continuous integration). I use TravisCI myself, great solution. Musthave for the modern developer.

H

hOtRush, 2017-09-14
@hOtRush

for simple projects, it’s perfect for example https://github.com/deployphp/deployer
there is also https://github.com/REBELinBLUE/deployer
well, or different pipelines in gitlab / bitbucket, but there you need to bother a lot more

I

Igor Vorotnev, 2017-09-21
@HeadOnFire

I already thought how to do everything with archives

Now, this was embarrassing! :)
To the point - use automatic deployment. The “wisely” scheme itself looks like this:
- it’s not the master that is deployed, but the tag / release
- each such release is deployed to a separate folder
- you test this stuff on a subdomain
- if everything is ok, then on the prod switch the server to the new release folder
- profit
When With this approach, you get obvious advantages:
- you don’t need to climb the server with handles, monkey work should be automated
- deployment occurs without downtime
- you retain the previous stable state, in case of problems with the new version, you can easily switch the server to the previous folder, thus rolling back to last stable
- if you wish, you can even do a/b testing

A

Anton, 2017-09-14
@karminski

I usually deploy to www-dev first, and then www. www-dev before each deployment is fully synchronized with www, including the database. Accordingly, before deployment, you have 2 absolutely identical projects. You check everything on one, and then - Let's go!

D

Dimitri, 2017-09-21
@Kvarkas

Jenkins is our everything :)