сокращение шагов в рабочем процессе git - PullRequest
Новая
       8

сокращение шагов в рабочем процессе git

0 голосов
/ 28 августа 2018

У меня есть следующие настройки 

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

Вышеуказанный результат в следующем рабочем процессе

  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 изображений и других двоичных файлов между dev и prod

Как я могу уменьшить количество вышеуказанных шагов? Вот что я подумал:

  1. избавиться от gitlab между ними, чтобы я git push прямо с моего dev-ноутбука на prod-сервер . Но я не знаю, как это сделать или даже можно ли это сделать.

  2. настроить git hooks на gitlab , поэтому, когда я git push к нему, на post-receive, gitlab git push(es) изменения прод-сервер . И добавьте post-receive git hook на prod-server , который перезапускает pm2. Конечно, я не совсем знаю, как это сделать.

Обновление: В идеале, так как я являюсь единственным разработчиком в этом проекте, мне бы хотелось иметь рабочий процесс, подобный этому 

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

Вышеприведенное, в сочетании с несколькими git hooks, как описано выше, значительно упростит мою жизнь. Конечно, опасность состоит в том, что у меня больше нет центрального репо, поэтому в случае, если мой dev ноутбук или prod server обанкротится, у меня нет резервной копии. Но это опасность, с которой я могу жить.

Обновление 2: безопасность центрального репо очень привлекательна.

1 Ответ

0 голосов
/ 22 сентября 2018

Чем заняться:

1) сначала заставьте ваш продукт развернуть один шаг. Я видел много производственных сайтов, использующих git pull для обновления, но я думаю, что это ошибка - они просят, чтобы они как-то конфликтовали в производственном репо, вызывая проблемы. Вместо этого напишите скрипт, который делает что-то вроде 

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

Это отключает его достаточно долго, чтобы очень быстро переключиться на новый код, который получается из снимка текущего главы мастера.

2) Теперь, когда у вас есть один deploy скрипт на вашем производственном сервере, у вас есть опции:

  1. запустите его вручную, когда будете готовы к развертыванию
  2. запускайте его периодически в запланированное время обновления (понедельник в 5 часов утра хорош, потому что он дает вам всю неделю, чтобы исправить любые перебои, не сокращая выходных)
  3. запустить его автоматически через (безопасный!) gitlab webhook
...