0

I have the following setup

[dev laptop] -- git push --> [gitlab]
                                 |
                              git pull
                                 |
                                 V
                          [prod server]

The above result in the following workflow

  1. dev-laptop$ git push gitlab
  2. dev-laptop$ ssh prod-server
  3. prod-server$ cd app
  4. prod-server$ git pull gitlab
  5. prod-server$ pm2 restart app
  6. prod-server$ exit
  7. dev-laptop$ rsync images and other binary files between dev and prod

How can I reduce the number of the above steps? Here is what I've thought:

  1. get rid of gitlab in between so that I git push directly from my dev-laptop to the prod-server. But I don't know how to do this or if it can even be done.

  2. set up some git hooks on gitlab so when I git push to it, on post-receive, gitlab git push(es) the changes to the prod-server. And, add a post-receive git hook on the prod-server that restarts pm2. Of course, I don't quite know how to do this as well.

Update: Ideally, since I am the only developer in this project, I would like to have a workflow like so

[dev laptop] -- git push --> [prod server]

The above, in conjunction with a few git hooks as described above, would simplify my life considerably. Of course, the danger is that I don't have a central repo anymore, so in case my dev laptop or prod server go belly up, I don't have a backup. But that is a danger I can choose to live with.

Update2: the safety of having a central repo is very attractive.

punkish
  • 13,598
  • 26
  • 66
  • 101
  • Hi, is there a reason you don't use a standardized CI/CD Process and tool like e.g. VSTS? – Thrawn Aug 29 '18 at 06:47
  • yeah, for one, I have no idea what is VSTS. Two, I want to keep the process as simple as possible. Perhaps if I learned about CI/CD and VSTS, I might be convinced to use them, but it seems unlikely. I have thought of getting rid of `git` completely and just using `rsync` (only for projects where I am the sole developer) but haven't dared down that path yet. – punkish Aug 29 '18 at 07:44

1 Answers1

0

Things to do:

1) first make your prod deploy a single step. I've seen lots of production sites using git pull to do updates, but I think it's a mistake - it's asking for their to somehow be conflicts in the production repo, causing issues. Instead write a script that does something like

mkdir deploydir-next
git archive master https://gitlab.com/me/myproject.git | tar -x -C /deploydir-next
pm2 stop app
mv deploydir deploydir-prev ; mv deploydir-next deploydir
pm2 start app
(cd deploydir-prev ; tar czv ../rollback_`date +%Y%m%d%H%M%S`.tar.gz . )
rm -rf deploydir-prev

This shuts it down long enough to make a very fast switch to the new code, which is derived from a snapshot of the current head of master.

2) Now that you have a single deploy script on your production server, you have options:

  1. run it manually when you're ready to deploy
  2. run it periodically at a planned upgrade-time (5am Monday is good because it gives you all week to fix any outages without cutting into your weekend)
  3. run it automatically via a (secure!) gitlab webhook
pjz
  • 41,842
  • 6
  • 48
  • 60