skyANAАлексей Кпропущено...
Это не фигня, а попытка найти интересную тему для обсуждения, коих в последнее время практически нет.CI и CD - это вполне себе интересная тема для обсуждения, но ты почему-то решил поглумиться :) Ну... Дело твоё.Жизненный цикл проекта - что может быть скучнее? Да и что там можно обсуждать? :-)

skyANAАлексей Кпропущено...
Жизненный цикл проекта - что может быть скучнее? Да и что там можно обсуждать? :-)Ну да, у вас же этого нет, как ты можешь что-то обсуждать :)Всё, что нам не надо, у нас нет, да. :-)

skyANAАлексей Кпропущено...
Всё, что нам не надо, у нас нет, да. :-)Да никто и не спорит. Не раз уже писал, что в корпоративе того-то и сего-то нет. :) Просто не надо на всё смотреть с колокольни своего корпоратива.А я никогда и не настаиваю, и не навязываю, и не осуждаю. :-)

А правда, что для того, чтобы наладить распространение новых версий, нужно прочитать много книг? Я вот ничего на эту тему не читал, но новые версии, и заплатки к ним, выпускаем регулярно. Может я что-то делаю не так? :-)

skyANAАлексей Кпропущено...
А я никогда и не настаиваю, и не навязываю, и не осуждаю. :-)

А правда, что для того, чтобы наладить распространение новых версий, нужно прочитать много книг? Я вот ничего на эту тему не читал, но новые версии, и заплатки к ним, выпускаем регулярно. Может я что-то делаю не так? :-)Смотря что ты подразумеваешь под "наладить распространение новых версий".
Материалы (книги, статьи, доклады) по CI и CD посвящёны в основном разработке методологии и автоматизации процесса. И тому, что это даёт, в том числе и какие конкурентные преимущества.А чего там автоматизировать? Батник написать? Для этого умная книга не нужна. :-)

skyANAУ вас скорее всего проблема решена на административном уровне: договорились выпускать новую версию по вторникам, до 14:00 все должны выложить свои изменения в репозиторий, Вася возьмёт оттуда и будет собирать ручками, а потом публиковать ручками.У нас дата новой версии обычно планируется заранее, или внезапно, если обнаружены критические ошибки. Внезапно бывает редко.

skyANAЕсли к тому моменту, как Вася словил первую ошибку, Петя уже ушёл с работы и пошёл в кино, то будем звонить Пете по среди сеанса.

Вообщем процесс обозначается твоим термином "весело" :)Скучно! :-)

Во время сборки версии все причастные находятся на рабочем месте, лишний экстрим мне не нужен. :-)

skyANAАхаха, батник. Ну ты вообще я смотрю профан. Даже не PowerShell скрипт.Давно ищу причины, чтобы переписать батники на PowerShell. Пока не нашёл. Зачем трогать то, что работает?

skyANAНапиши-ка мне батник для этого (всё что не начинается не с WA-Live - это тестовые среды для разных веток, которые необходимо регулярно пересобирать и конфигурировать):Батник в scheduler вставить что ли?

skyANAАлексей КУ нас дата новой версии обычно планируется заранее, или внезапно, если обнаружены критические ошибки. Внезапно бывает редко.А у нас сейчас релиз раз в месяц и мы хотим чаще.Бывает, несколько дней подряд по релизу в день собираю. Ну не могут они с первого раза сделать всё по человечески.

skyANAАлексей КВо время сборки версии все причастные находятся на рабочем месте, лишний экстрим мне не нужен. :-)А зачем? Если тесты уже успешно пройдены, скрипты конфигурации в репозитории и в случае ошибки откат на предыдущую стабильную версию - это дело 5 минут максимум?Дата релиза назначена, значит релиз должен быть выпущен и передан заказчику. Если программиста не будет на месте, кто будет исправлять его ошибки?
skyANAАлексей КБатник в scheduler вставить что ли?Вставь. Во ремя сборки упадёт ошибка и даже залогируется в текстовый файлик. Но кто её увидит и отреагирует?У меня не гигантский проект. При сборке релиза он полностью перекомпилируется, на этом этапе ошибки будут замечены. Так же время от времени проект полностью перекомпилируется для выкладывания trunk-а в тестирование тестировщиками.

В ночных автобилдах в моих условиях смысла не вижу.

skyANAАлексей Кпропущено...
Бывает, несколько дней подряд по релизу в день собираю. Ну не могут они с первого раза сделать всё по человечески. Ахаха. Это называется не по релизу в день, а выпустили релиз с багами, и неделю в режиме ошпаренной кошки патчим, стресс, срач, новые баги.
Нормальный процесс CI и CD избавляет от этого. В результате и клиенты довольны, и мы пьём пиво в пабе по поводу очередного релиза и не обсуждаем то как бл*, вот это достало и это, а то как мы покатались на картинге.От этого никакая автоматизация и менеджмент не спасут. Максимум, что можно сделать, это назвать такую сборку Release Candidate и вынести еботню с ним в отдельный период жизненного цикла проекта, и дать этому периоду какое-нибудь страшное название RCY (Release Candidate Yebotnya). На диаграмме отобразить это отдельным квадратиком и стрелочками. :-)

зы: От перемены мест слагаемых сумма...

skyANAАлексей Кпропущено...
Дата релиза назначена, значит релиз должен быть выпущен и передан заказчику. Если программиста не будет на месте, кто будет исправлять его ошибки?Какие ошибки? Зачем исправлять?

При грамотном процессе инциденты, когда критическую ошибку обнаружили после релиза, возникают 1 раз в год. Релиз откатывается за 5 минут, ошибка спокойно правится и также спокойно выходит релиз уже с исправлением.Да мне уже сегодня релиз отдать надо. Сроки назначены. Последние доработки, как всегда, делаются в ужасе, в последний момент. :-)

skyANAНу вот и не предлагай фигню всякую: батник запихать в планировщик. Да ты release master 98-го левела :)Ну да, кто-то утром должен парсить логи джобов компиляторов. Можно даже заглянуть в консольку шедулера, она не такая зелёная, как у тебя на картинке, но джобы с ошибками видно. :-)