Настройка vcs для проекта

craz

Нестандартное звание
Описываю как я хотел бы, чтобы у меня было:
Есть проект на боевом хосте, у меня доступ по sftp из PhpStrom я правлю код, при сохранении код автоматом попадает на сервер, на сервере(CentOS) что-то как-то настроено, что контролирует изменение кода и делает commit в локальный репозиторий, после этого сразу делает push в удаленный репозиторий.
Удаленный разработчик берет код проекта из удаленного репозитория, подключается к хосту, где размещен dev проекта по sftp, выполняет задание, сохраняет файл, он автоматом попадает на хост и также коммит и пуш в ветку dev.
Я проверяю работу, забираю себе код сохраняю его на хост, и все происходит тоже самое.

1. Я вообще жизнеспособную схему описываю?
2. Вот это что-то как-то настроено - подскажите мне, что это и где почитать как настроить?
3. Если схема не верна, опишите как мне лучше это организовать.
 

AnrDaemon

Продвинутый новичок
Бред собачий. Возьми git и напиши пару триггеров.
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
Настройте git с ветками и правами на них.

Gitolite вроде бы давал разграничивать права на ветки
 

craz

Нестандартное звание
Бред собачий. Возьми git и напиши пару триггеров.
В чем конкретно бред?

Настройте git с ветками и правами на них.

Gitolite вроде бы давал разграничивать права на ветки
Мне по большому счету все равно как будет выполняться задача с точки зрения версионирования, главное для меня отслеживать не изменили код из браузера и чтобы я мог вернуться к какому-то из коммитов.
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
@craz, при чем тут вообще браузер? В любом нормальном IDE есть просмотр истории репозитория, веток, коммитов и если надо - чекаут нужного коммита
 

craz

Нестандартное звание
@craz, при чем тут вообще браузер? В любом нормальном IDE есть просмотр истории репозитория, веток, коммитов и если надо - чекаут нужного коммита
Да при том, что это долбанный КП от Битрикса(((( и мне надо как-то подрядчиков организовать на работы. А я не могу схему взаимодействия придумать.


Больше скажу я не могу найти подрядчика, который такую схему предложит(
 

AnrDaemon

Продвинутый новичок
Если подрядчик начинает мычать и хлопать глазками на слово "VCS", гони такого в шею…
 

fixxxer

К.О.
Партнер клуба
CircleCI в базовом варианте бесплатный, bitbucket тоже ;)

Есть проект на боевом хосте, у меня доступ по sftp из PhpStrom я правлю код, при сохранении код автоматом попадает на сервер
Поубывав бы.
И не надо про битрикс рассказывать, нет никакой разницы в этом плане.
Сделайте vagrant-образ и пусть все с ним работают. Поработал, закоммитил в веточку, запушил, сделал пул-реквест, смержили в мастер, CI по хуку на мастер раздеплоил хоть бы по этому вашему sftp.
 

craz

Нестандартное звание
Ок,
CircleCI в базовом варианте бесплатный, bitbucket тоже ;)


Поубывав бы.
И не надо про битрикс рассказывать, нет никакой разницы в этом плане.
Сделайте vagrant-образ и пусть все с ним работают. Поработал, закоммитил в веточку, запушил, сделал пул-реквест, смержили в мастер, CI по хуку на мастер раздеплоил хоть бы по этому вашему sftp.
Где бы это почитать именно от А до Я, опыта 0 в любом из направлений.

Вот я кстати когда описывал, то имел ввиду именно битбакет почему-то...
 

fixxxer

К.О.
Партнер клуба
в гугле
git flow
continuous integration

А самый простой способ - устроиться в нормальную команду, где люди не представляют себе, как работать иначе ;)

Это такая штука, что все просто, но объяснять сложно и долго, проще показать.
 

WMix

герр M:)ller
Партнер клуба
выдели только соурс - то что пишется. далее ручками собираешь проект, смотришь что нужно сделать чтоб заработало, описываешь в makefile или phing там и bower/yarn и grunt/gulp и packages и composer.. ну те этот труд нужно совершить и разбить на детальки. это (соурс + скриптики необходимые для создания апп) и только это в контроль версий.
 

craz

Нестандартное звание
в гугле
git flow
continuous integration

А самый простой способ - устроиться в нормальную команду, где люди не представляют себе, как работать иначе ;)

Это такая штука, что все просто, но объяснять сложно и долго, проще показать.
Ну я уже устроен, и хочу как раз это реализовать для "команды"(которой пока нет).


Обеспечение версионности при работе с порталом


  1. На боевом сервере устанавливается git.
  2. Все необходимые файлы добавляются в репозиторий. Это будет ветка master.
  3. После этого формируется ветка релиза из master - v0.1.
  4. Далее каждый, новый (старый) программист выполняя отдельную задачу, создаёт ветку из мастера.
  5. После того, как задача выполнена и принята, она сливается с master и создаётся новый релиз.
  6. После этого на боевом сервере необходимо скачать новую, релизную ветку и переключиться на неё.

Что обеспечивает такой подход?

  1. Изолированность разработки каждым программистом от других задач.
  2. Сохранение разных версий разработки. Если в новом релизе была замечена ошибка после опубликования, то всегда можно переключиться на предыдущий.
  3. Нет лишних веток.

Что необходимо сделать на боевом сервере, чтобы получить новую версию?

  1. В консоли на боевом сервере выполняется команда git fetch. Она скачает с удаленного репозитория новые ветки.
  2. Переключиться на новую, релизную ветку, используя команду git checkout <названия ветки>.

Пример:


На сервере для разработки.

0. git checkout master # переключаемся на ветку мастер

  1. git checkout -b task1 # создаём из ветки master новую task1 для выполнения задачи
  2. git commit -a # фиксируем изменения
  3. git rebase master #переносим на ветку master после сдачи и принятия задачи. Ветка master должна быть актуальной
  4. git checkout master # переключаемся на ветку master
  5. git merge task1 # сливаем ветку задачи
  6. git branch -d task1 # удаляем локально ветку задачи
  7. git push origin --delete task1 # удаляем ветку задачи в удаленном репозитории, если она была там опубликована
  8. git checkout -b r_01.01.2017 # формируем ветку релиза из master
  9. git push origin r_01.01.2017 # отправляем в удаленный сервер новую, релизную ветку
Переходим на боевой сервер

  1. git fetch # скачиваем новые ветки из удаленного репозитория
  2. git checkout r_01.01.2017 # переключаемся на релизную ветку - на сервере работает новая версия портала.
Это жизнеспособно?
 

WMix

герр M:)ller
Партнер клуба
На боевом сервере устанавливается git.
я не стал бы так делать. я собирал бы на отдельном сервере хоть даже на локальном, (тесты не забываем), а дальше уже проверенный апп через scp или rsync на сервер кидал бы. все остальное may be ну опять же с учетом вышенаписанного
 

WMix

герр M:)ller
Партнер клуба
а в каких случаях, ты убежден, что все работает?
 

fixxxer

К.О.
Партнер клуба
git fetch # скачиваем новые ветки из удаленного репозитория
git checkout r_01.01.2017 # переключаемся на релизную ветку - на сервере работает новая версия портала.
Вот это делается на CI, а на прод rsync или вроде того.

Посмотри CircleCI, говорю ж. Бесплатного тарифа тебе хватит.
 

Redjik

Джедай-мастер
+1 к CircleCI - сделал на нем подобные схемы с нуля за 3-4 часа на говнопроект (при том что видел CIrcleCI в первый раз тогда)
 

Breeze

goshogun
Команда форума
Партнер клуба
Это жизнеспособно?
Вполне, у меня так работает на меркуриале.

Есть два НО:

1. На боевых машинах запущены свои агенты, которым через веб-морду ставятся таски на что апдейтиться, а те качают, распихивают и потом синхронно переключают. Выкатка релиза занимает примерно минуту.
2. Делалось это во времена, когда деревья были зеленее, а вода мокрее.
 
Сверху