villiwalla
@villiwalla
HTML-верстка

Схема CI сборки и публикации проектов, верно ли?

Скажите, на сколько верно я понимаю схему CI, при том раскладе что тестов на данный момент внедрить в процесс просто не реально, но очень острая нехватка именно в нормальном деплое результатов работы.

Сейчас, деплой и разработка брр, такая, папка на дев сервере в ней все и работают (>_<), ну и руками выкатывают файлы с правками, конец.

Но при всем при этом есть возможность, все проекты засунуть в гит и разделить на нужные ветки (prod, dev, stable), всех перевести на локальную разработку, настроить jenkins но пока увы без тестов.

Я пока понимаю схему работы доставки с дев на продакшен так:

1. Разработчик копирует себе проект из гита (дев-ветки)
2. Ведут локальную разработку
2.1 Делает локальный комит
2.2 Завершая задачу делает пуш в ветку разработки
2.2.1 Закрывает так в трекере
3. Jenkins собирает проект из dev ветки
3.1 После успешной сборки публикует проект на девелоп сервер
4. После удачной сборки, публикует в локальный доступ на дев сервер сборку
4.1 Оповещает о публикации сборки
4.2 Отправляет сборку в стабильную ветку гита (тут наверное ручной контроль и далее?)
5. После отправки в гит, jenkins собирает проект из стабильной ветки
5.1 Отправка собранной версии на продакшен (Здесь, должно быть дифференцированное копирование?)

Что посоветуете, как вернее составить план действий?
  • Вопрос задан
  • 1551 просмотр
Решения вопроса 1
e-antonov
@e-antonov
Если вы все возитесь в одной папке для разработки, то у вас не только проблемы с CI\CD, но и в целом с культурой командной разработки.
Думаю вам можно начать со схемы попроще, чтобы люди в команде пообвыклись, поняли как улучшается коллективная разработка и потом уже на необходимый рабочий минимум вам нужно начать накручивать дополнительные фичи.
Только без лишнего оверхеда, ибо легко увлечься всеми современными трендовыми подходами для проекта, на котором оно не сильно надо.

Предложу вам необходимый на мой взгляд минимум:
1. проект загоняется под гит
2. каждому разработчику выделяется отдельный дев сервер, склонированный с прода (сильно желательно повторяющий окружение продакшена). Можно локально разворачивать вагранты, просто локально у себя проект поднимать, но мне больше нравится какой-то пак удаленных серверов для разработки, ибо часто разработчики сами не очень понимают как что правильно на сервере надо настроить и удаленный пак этих серверов может легко админить ваш сисадмин, а если у всех всё локально, да еще команда распределена географически - то это будет большое мучение и потеря времени
3. в мастере либо не работает вообще никто, либо там делают какие-то срочные хотфиксы. под каждую задачу выделяется отдельная ветка, в ней разрабатывается, и когда разработка протестирована и проверена - сливается в мастер
4. как смержили изменения в мастер - пуллите мастер на продакшене.
всё, это самый минимальный вариант, с чего надо начинать, чтобы люди привыкли. как только люди привыкнут и вы поймете что вашим разработчикам не хватает дисциплины и на прод в мастер коммитят что попало - делайте отдельную stage ветку и stage сервер. куда будете сливать наработки из веток-фич и проверять там за тем что
наразрабатывали. если изменения одобрены - stage вливайте в мастер и пулльте на продакшен.

Когда поймете что устали ходить и руками пуллить на продакшене и запускать там всякие скрипты сборки фронтенда и прочее - можете пойти дальше. заводите отдельный сборочный сервер (он либо всегда висит статичный либо для каждой сборки можно развернуть например докер контейнер) на котором установлен весь софт необходимой для сборки. например все node-modules для сборки фронта.
И когда вы пушнули в мастер, то дженкинс или тимсити или еще что-то видит это, стягивает на сервер сборки ваш код, запускает все команды для сборки и после этого запаковывает собранный код. затем наступает время деплоя, когда деплойный скрипт переносит вашу сборку на продакшен, распаковывает ее и определенным образом делает ее активной, вместо той сборки, что была у вас (это может быть переключение симлинков, переключение докер-контейнеров и т.д.)

Мне кажется уже этой схемы вам хватит надолго. А если и этого будет мало - можете продолжить плодить git-flow полный набор веток. Но для этого вы себе должны серьезно аргументировать их необходимость
Может быть для понимания CI\CD схемы на конкретном примере поможет такая статья antonov-dev.ru/blog/11
Там хоть и про битрикс, но общей идеи это не меняет особо
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
OnYourLips
@OnYourLips
2.2 Завершая задачу делает пуш в ветку разработки
2.2.1 Закрывает так в трекере

Не правильно. Таск закрывается только при мёрже фича-бренча в мастер. Между этими событиями очень много действий.

Надо задеплоить на один из девбоксов эту ветку и проверить её. Прогнать нужные по ней тесты, сделать ревью.
И только после этого мёржить.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы