Size: a a a

JavaScript.Ninja

2021 April 18

M

Michael in JavaScript.Ninja
У нас довольная крупная компания. Несколько десятков команд. Так что я не думаю, что такой флоу случайный
источник

IK

Illya Klymov in JavaScript.Ninja
У нас стейджинг тоже льется напрямую из мастера
источник

IK

Illya Klymov in JavaScript.Ninja
Это позволяет непрерывно его тестировать руками
источник

M

Michael in JavaScript.Ninja
Без стейджа ведь каждый выкат на прод - это лотерея
источник

IK

Illya Klymov in JavaScript.Ninja
Суть continius delivery как раз в способности быстро выкатывать на прод и быстро роллбекаться
источник

IK

Illya Klymov in JavaScript.Ninja
Что же касается поиска руками - это странно, почему просто не сделать manual job в пайплайне которая раскатала бы код на мастер
источник

M

Michael in JavaScript.Ninja
А имеет смысл при таком флоу создать еще одну ветку - стейдж - в нее делать мердж с мастера, протестить все на стейдже и потом это уже на прод?
источник

IK

Illya Klymov in JavaScript.Ninja
Мы делаем релиз ветки по одной простой причине - туда может возникнуть необходимость бэкпортировать фиксы какие-то
источник

IK

Illya Klymov in JavaScript.Ninja
Последние 3 релиза в гитлабе получают секьюрити обновления
источник

IK

Illya Klymov in JavaScript.Ninja
Но у нас специфика - у нас же продукт который люди ставят
источник

M

Michael in JavaScript.Ninja
Создается релизный тикет в жире, который делает все сам, но в этом тикете нужно указать нужный артефакт
источник

IK

Illya Klymov in JavaScript.Ninja
А не только саас
источник

DZ

D Z in JavaScript.Ninja
В моем случае он не возможен. Зря вообще упомянул. Есть только ручное тестирование из-за релиз раз в неделю.
источник

IK

Illya Klymov in JavaScript.Ninja
невозможен CI или CD? Cd от вас никто не ждет
источник

DZ

D Z in JavaScript.Ninja
В моем видение оба из них невозможны
источник

IK

Illya Klymov in JavaScript.Ninja
Почему? Если нет деплоя - стоимость реверта мержа ветки достаточно дешевая, а польза велика - вместо АДСКОГО мержа осьминога - получается размазанная по времени активность и люди решают конфликты заранее. Согласно современной теории управления это сильно повышает надежность, чем разрешение "многолапого" конфликта в ограниченное время
источник

IK

Illya Klymov in JavaScript.Ninja
(я не настаиваю, спрашиваю)
источник

DZ

D Z in JavaScript.Ninja
С ручным тестированием проблема может выявлиться только непосредственно перед деплоем, тк чаще тыкать цепочки чисто физически невозможно. А на этот момент от ветки, которую нужно ревертать могли наделать еще изменений. (я не отрицаю, что наш подход плохой, хочу понять как сделать его лучше)
источник

Е

Евгений in JavaScript.Ninja
Хз как лучше) но у нас на мастере стоит автодеплой на бой, беру таск, ответвляюсь от актуального мастера, делаю задачу, в менеджером проверяем на наличие проблем (тестов у нас тоже нет), если все ок - делаю MR на мастер, в случае конфликтов - разрудиваю, тимлид смотрит, если есть замечания, добавляю коммит с исправлениями, если все ок - мержит и улетает на бой, я обновляю мастер у себя, ответвляюсь с новым таском и выполняю дальше) так получается мало конфликтов и все вроде норм))
источник

DZ

D Z in JavaScript.Ninja
Мне кажется, это даже хуже чем у нас.
источник