Андрей Панфилов, CD как раз и решает все эти проблемы одним нажатием кнопки. Я даже часто это нажатие на плечи QA перекладываю, ведь они решают что сборка достойна.
Андрей Панфилов- сформировать ранлист, где указаны определенные вехи и продолжительность операцийЭто все в скрипте.
Андрей Панфилов- согласовать (ну и назначить) время среди всех заинтересованных владельцев систем, а не только целевойКак правило нет никакой необходимости. Разве что функционал сильно поменялся и мы хотим тренинг провести для сотрудников.
Андрей Панфилов- оповестить пользователей о предстоящей недоступности (мне вот, к примеру, банк присылает оповещения что онлайн-кабинет не будет работать в определенный промежуток времени)CD предполагает zero-downtime deployment (blue-green deployment, canary releases). Я последний раз деплоил с даунтаймом 10 лет назад (не, ну лукавлю - у меня были несколько релизов с даунтаймом даже во времена CD, но это большое исключение).
Андрей Панфилов- согласовать доступность ключевых сотрудников на случай если что-то пойдет не по плануС трудом припоминаю случаи когда что-то шло не так (CD от этого защищает), но наверно может быть. Для этого нужен либо деплой новой версии с фиксом (т.е. нужно это делать в рабочее время когда есть разрабы) если фикс быстрый, либо просто деплой предыдущей версии. Если база меняется только аддитивно (никаких rename/drop используемых колонок), то это piece of cake.
Андрей Панфилов- убедиться что из резервных копий можно-таки восстановитьсяЭто тоже легко автоматизируется и должно проверяться на постоянной основе. Где позволительно, резервные копии нужно накатывать на какие-то из дев окружений (PREPROD?), это же защитит от плохих миграций которые проходят везде кроме PROD'a.
Андрей Панфилов- в час Х создать резервные копии, если необходимо
- что-то куда-то накатить
- прогнать смок-тесты
Автоматизируется
Андрей Панфилов- оповестить, что систему можно проверятьНе знаю кому и зачем это надо. Это просто "пресс релиз".
Андрей Панфилови вот с моей точки зрения шаг "что-то куда-то накатить" даже не имеет смысла автоматизировать:
- во-первых, он не особо-то и много времени занимает
Во-первых времени это занимает прилично, т.к. это не единоразовая активность. Особенно учитывая все шаги с бекапами и пр. Во-вторых это очень ответственная процедура и в ней не должно быть ошибок. Для этого мы описываем ее в скриптах, которые тестируются на всех окружениях прежде чем будет применяться на проде.
Андрей Панфилов- во-вторых, за это кто-то получает зарплатуСтранный аргумент, за ковку подков тоже когда-то получали зарплату.
Андрей Панфилов- в-третьих, от релиза к релизу шаги меняются и нет никакого смысла это автоматизироватьПоследний раз менял скрипты даже не знаю когда.. 4 года назад наверно. И так в каждом проекте в которых я реализовывал CI/CD - скрипты создаются на начальных этапах и про них забывают. Разве что захотелось на какой-то новый софт перейти.
Андрей Панфиловоднако все что сейчас существует на рынке, и в особенности в опенсорсе, даже эту задачу автоматизировать толком не в состоянии, здесь не особо вижу смысла накидывать кучу примеров в качестве подтверждения мысли, но в целом видится так, что все эти "автоматизации" зиждятся на трех китах:
- у заказчика неправильный дизайн приложения и нужно его менять
- у заказчика кривая архитектура и нужно ее менять
- ну мы тут у себя что-то запускали, а на проде внезапно что-то пошло не так, виноват дизайн и архитектураНе понимаю о каких инструментах речь. CI/CD - это больше культурная и процессуальная вещь, изменения должны произойти в головах людей. Скрипты нужно самим написать, не знаю какие бы инструменты тут могли помочь. Скрипты прийдется скорей всего в каждом проекте заново писать, как и код (эх..).

Андрей Панфиловну вот ваши цитирования по строчке не вызывают никакого желания вступать в дальнейшую дискуссиюНе понял - ожидается что я просто пропущу половину из написанного и не прокомментирую?
Андрей ПанфиловДавайте так: если все по вашему мнению "автоматизируется", то, будте добры, назовите хотя бы название продукта, где все что я хочу реализовано (а не то что какой-то шаг якобы не нужен потому что вы с ним не сталкивались), а не слово "Jenkins" где все откровенно лепится из говна и палокДак ты против того что "все автоматизируется" или против скриптов? Я не утверждал что есть какой-то мифический инструмент который за нас все сделает. Нам нужно написать скрипты , магии не существует. Будет ли говно и палки или что там еще - ну это кто как напишет. Но работающую автоматизацию можно сделать даже из говна и палок. Это все равно будет намного лучше ручного вмешательства.
Андрей Панфиловну или по крайней мере попробуйте доказать свое утверждение, что шаги инсталляции никогда не меняютсяЭт что за выдумки, я где-то писал что они никогда не меняются? Я говорил про "редко".
Андрей Панфиловс учетом того что бывают миграции данных, которые идут довольно долго и для ускорения процесса что-то может запускаться параллельно, а что-то должно выполняться строго последовательноУ меня были миграции по неделе и ничего не пришлось менять в скриптах, все решалось исключительно поддержкой обратной совместимости в новых релизах пока шла миграция. Наверняка бывают какие-то исключения когда прийдется что-то вручную промигрировать или что-то в этом роде, но это все же исключения, я бы на них внимания не заострял.

Вообще удивительно что в 2021ом мы ведем такие дискуссии. Уже 5 лет назад казалось что ручные манипуляции во время деплоя - это каменный век.

В такой постановке - никакой. Вот где есть разница:
1. push to branch -> push to branch -> push to branch -> review -> master
2. push to branch -> review -> master -> push to branch -> review -> master -> push to branch -> review -> master

Т.е. мы не доводим фичу до конца в ветке, а потом вливаем. А стараемся вливать периодически то что есть, что-то что еще не закончено. Это апогей Continuous Integration'а.

Андрей Панфилов , я наверно повторюсь, но безотносительно того говно или не говно bash, хорошо на нем пишут или плохо - это все равно лучше ручного вмешательства.
Андрей ПанфиловСо стороны ДИТ деплой наверное уже лет как 30 полностью автоматизирован: создается work order, он кем-то закрывается, каким именно образом он закрывается - это уже проблема вполне конкретного подразделения, они могут хоть пляски с бубном устраивать, главное чтобы work order был закрыт.Многие путаются в термине DevOps - кто-то думает что это люди. На самом деле этот термин значит Devs & Ops команды работающие вместе . В более широком смысле это значит культуру компании, где не "моя хата с краю", а разные роли и департаменты работают друг с другом совместно чтоб получить хороший результат. Не каждый работает на свою метрику, а наоборот - он может пожертвовать своим временем ради других если это повышает производительность организации в целом . Т.е. мы боремся не за локальный, а именно за глобальный оптимум.

Это именно то к чему IT пришло чуть больше 10 лет назад - такая схема приводит к более успешным проектам и компаниям. А "заводится work order - они там пусть че хотят, то и делают" - это что-то из 90ых. Программисты должны разбираться на каких OS у них деплой, с какой конфигурацией. И без их помощи Ops инженеры не смогут сделать свою работу хорошо, ведь одна из их основных задач - полностью автоматизировать деплой. Именно от разработчиков зависит можно ли реализовать blue-green deploy, будут ли они релизить маленькие куски (с помощью branching by abstraction, feature toggles и пр) или большие (после которых возникает намного больше проблем), как что логируется и пр, пр.

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

Да и в целом это повышает мораль, CI/CD - это спокойные проекты, без стрессов, где релиз всегда проходит гладко.