Searching a nice way to update my two servers after a new git commit

TL;DR: Newbie question: Is there any best practice for updating my servers after having pushed a new commit from my IDE to my git repo?

Hi all,

knowing that there are several great documentations about packaging and deployment, I’m not really sure how my configuration - and steps on rolling out new versions shall look like.

I have…
…a git repo for versioning the whole project. It might happen that I start another one or two really small projects which shall all run on the same server(s) later.

I will have…
…two VMs, a test environment and a production environment (both Linux, Apache). I won’t do any changes on the source-code on these two servers.

I would like to have…
…a nice way to update both servers after I made a new commit.

Of course I could initially do a git clone on both servers while running a git pull each time there is a new commit. But what happens if I want to add another app to the project that was developed / forked / modified to the project? Not really sure if that’s the way things are done… :roll_eyes:

So is there any best practice I could follow for updating my servers after having pushed a new commit from my IDE to my git repo?


Keep in mind that git itself works on a “pull” model, not a push. That means that something running on the client needs to be triggered when the commit occurs.

(We use gitlab, which means we have the gitlab runner available to us.)

Our system is set up that on a certain type of tag being applied to the main branch, it runs a process that does the pull / merge, does a migrate and collectstatic, then builds a docker container. (That’s for our test environment. Moving to production still requires manual steps.)

No idea if this fits anyone’s idea of “best practices”, but it works for us.