Телеграмм чат группы devops

к примеру

- репо backend
- репо frontend
- репо project (submodule backend; submodule frontend; deploy/cd.sh)

принимаются pr's в отдельных ветках
далее в "project" обновляют сабмодули в отдельном pr'е
далее стартует CD (изменения в мастере)
CD чекает хеши отдельных сабмодулей?

и допустим если изменился хеш только фронта, то в CD передаем параметр (мол онли фронт билд), верно?

источник

14:18пожаловаться #4

XN

Xeon Null in DevOps — русскоговорящее сообщество

Daryl

к примеру

- репо backend
- репо frontend
- репо project (submodule backend; submodule frontend; deploy/cd.sh)

принимаются pr's в отдельных ветках
далее в "project" обновляют сабмодули в отдельном pr'е
далее стартует CD (изменения в мастере)
CD чекает хеши отдельных сабмодулей?

и допустим если изменился хеш только фронта, то в CD передаем параметр (мол онли фронт билд), верно?

как вариант

источник

14:19пожаловаться #5

D

Daryl in DevOps — русскоговорящее сообщество

Xeon Null

как вариант

нормальной практикой считается?

источник

14:19пожаловаться #6

D

Daryl in DevOps — русскоговорящее сообщество

или костыльно?)

источник

14:19пожаловаться #7

XN

Xeon Null in DevOps — русскоговорящее сообщество

нормальная практика это версионирование апи на бэке)

источник

14:19пожаловаться #8

XN

Xeon Null in DevOps — русскоговорящее сообщество

а не вот это вот все)

источник

14:20пожаловаться #9

D

Daryl in DevOps — русскоговорящее сообщество

Xeon Null

нормальная практика это версионирование апи на бэке)

я понял, да, так и думал
чтобы лайтово в любое время выкатывать фронт и не думать, что апи на беке уже изменено

источник

14:21пожаловаться #10

D

Daryl in DevOps — русскоговорящее сообщество

но скажем что специфика бизнеса такая🤪

источник

14:21пожаловаться #11

D

Daryl in DevOps — русскоговорящее сообщество

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

источник

14:22пожаловаться #12

D

Daryl in DevOps — русскоговорящее сообщество

но я понял, @xeonnull @kirill_muhin спасибо вам

источник

14:23пожаловаться #13

DS

Dmitry Sergeev in DevOps — русскоговорящее сообщество

Daryl

к примеру

- репо backend
- репо frontend
- репо project (submodule backend; submodule frontend; deploy/cd.sh)

принимаются pr's в отдельных ветках
далее в "project" обновляют сабмодули в отдельном pr'е
далее стартует CD (изменения в мастере)
CD чекает хеши отдельных сабмодулей?

и допустим если изменился хеш только фронта, то в CD передаем параметр (мол онли фронт билд), верно?

можно просто CD разделить, и выкатывать независимо фронт с бэком

источник

14:24пожаловаться #14

D

Daryl in DevOps — русскоговорящее сообщество

Dmitry Sergeev

можно просто CD разделить, и выкатывать независимо фронт с бэком

условие задачи другое)
важно чтобы фронт и бек были обновлены в одно время

источник

14:25пожаловаться #15

DS

Dmitry Sergeev in DevOps — русскоговорящее сообщество

Daryl

условие задачи другое)
важно чтобы фронт и бек были обновлены в одно время

а как это обеспечивается? Каким образом гарантируется, что новые файлы на фронте появятся в ту же секунду когда поднимется новый бэкенд?

источник

14:26пожаловаться #16

DS

Dmitry Sergeev in DevOps — русскоговорящее сообщество

А что делать со старыми пользователями, которые загрузили фронт за 10 секунд до апдейта, если такое условие, то получается у этих людей ничего не будет работать пока они не обновят страницу, так как старый фронт не работает с новым бэком

источник

14:28пожаловаться #17

DS

Dmitry Sergeev in DevOps — русскоговорящее сообщество

> логика чего-то может измениться прям сильно и никак не поддержать то, что было, иначе бизнес сгорит
Бизнес не сгорает, от того что при апдейтах у многих пользователей ломается приложение?

источник

14:29пожаловаться #18

DS

Dmitry Sergeev in DevOps — русскоговорящее сообщество

Daryl

к примеру

- репо backend
- репо frontend
- репо project (submodule backend; submodule frontend; deploy/cd.sh)

принимаются pr's в отдельных ветках
далее в "project" обновляют сабмодули в отдельном pr'е
далее стартует CD (изменения в мастере)
CD чекает хеши отдельных сабмодулей?

и допустим если изменился хеш только фронта, то в CD передаем параметр (мол онли фронт билд), верно?

а в этой схеме, как проверяется что хэш изменился? Получается надо знать какой был старый хэш при посдеднем запуске CD? Где хранится эта инфа? Если храним его локально в файлах на агенте сборок, получается если мы перенакатим агент, и потеряем файл, то получим передеплой обоих сервисов, но не факт что в них что-то изменилось?

источник

14:33пожаловаться #19

V

Vladimir in DevOps — русскоговорящее сообщество

Dmitry Sergeev

а в этой схеме, как проверяется что хэш изменился? Получается надо знать какой был старый хэш при посдеднем запуске CD? Где хранится эта инфа? Если храним его локально в файлах на агенте сборок, получается если мы перенакатим агент, и потеряем файл, то получим передеплой обоих сервисов, но не факт что в них что-то изменилось?

Почему бы просто постоянно не деплоить мастер?

источник

14:35пожаловаться #20