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

[craz]

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

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

 

[AnrDaemon]

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

 

[c0dex]

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

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

 

[craz]

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

В чем конкретно бред?

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

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

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

 

[c0dex]

@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]

выдели только соурс - то что пишется. далее ручками собираешь проект, смотришь что нужно сделать чтоб заработало, описываешь в 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. …
4. git rebase master #переносим на ветку master после сдачи и принятия задачи. Ветка master должна быть актуальной
5. git checkout master # переключаемся на ветку master
6. git merge task1 # сливаем ветку задачи
7. git branch -d task1 # удаляем локально ветку задачи
8. git push origin --delete task1 # удаляем ветку задачи в удаленном репозитории, если она была там опубликована
9. git checkout -b r_01.01.2017 # формируем ветку релиза из master
10. git push origin r_01.01.2017 # отправляем в удаленный сервер новую, релизную ветку

Переходим на боевой сервер

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

Это жизнеспособно?

 

[WMix]

На боевом сервере устанавливается git.

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

 

[craz]

Ну какие тесты на Битриксе...(

 

[WMix]

а в каких случаях, ты убежден, что все работает?

 

[fixxxer]

Ну какие тесты на Битриксе...(

Не вижу никаких проблем в acceptance-тестировании Битрикса.
С юнит-тестированием, конечно, сложнее, но оно наверное там и не надо.

 

[fixxxer]

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

Вот это делается на CI, а на прод rsync или вроде того.

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

 

[Redjik]

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

 

[Breeze]

Это жизнеспособно?

Вполне, у меня так работает на меркуриале.

Есть два НО:

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

 

[Redjik]

а вода мокрее.

главное не забывать, что мокрая кошка и влажная киска - это не одно и то же (с)