У кого-нибудь сделана полная автоматизация релиза — от сборки бинарников до обновления данных на сайте и у регистратора? Если да, то какими средствами, насколько геморройно было сделать и потом поддерживать? Если нет, то какие действия остались ручными?
И как решается вопрос с восстановлением, если в середине процесса что-то пошло не так?
ЕМ> У кого-нибудь сделана полная автоматизация релиза — от сборки бинарников до обновления данных на сайте и у регистратора? Если да, то какими средствами, насколько геморройно было сделать и потом поддерживать?
А в чём проблема-то? Средство штатное — msbuild,
книжка есть, где написано, как прикручивать любой тулчейн (C++)
— 2011, Sayed Ibrahim Hashimi & William Bartholomew, Inside the Microsoft Build Engine. Using MSBuild
ЕМ> Если нет, то какие действия остались ручными?
Про регистраторов не знаю, но должно тоже автоматизироваться по-идее.
ЕМ> И как решается вопрос с восстановлением, если в середине процесса что-то пошло не так?
Полная пересборка, частичная пересборка, в книжке описано как их делать.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>У кого-нибудь сделана полная автоматизация релиза — от сборки бинарников до обновления данных на сайте и у регистратора? Если да, то какими средствами, насколько геморройно было сделать и потом поддерживать? Если нет, то какие действия остались ручными?
ЕМ>И как решается вопрос с восстановлением, если в середине процесса что-то пошло не так?
Сначала автоматизационный bat-ник
Потом пришлось коснуться питона, показалось интересным, теперь у меня автоматизационный py-тник
Один раз все сделать и потом ничего не трогать, ибо работает.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>А в чём проблема-то? Средство штатное — msbuild, ЭФ>книжка есть, где написано, как прикручивать любой тулчейн (C++)
Хм, мне казалось, что я достаточно ясно сформулировал вопрос. То, что можно прикрутить любой тулчейн, ясно и ребенку — вопрос в том, как именно этот тулчейн должен работать, чтобы при сбое посреди процесса не получилось неразберихи.
ЭФ>Про регистраторов не знаю
Так в этом и заключается бОльшая часть задачи. Сборка бинарников — процесс полностью локальный, это можно делать разными способами, и ни один не чреват рассинхронизацией глобальных состояний (сайт, регистратор и все остальное в интернете).
Здравствуйте, CyberDemon, Вы писали:
CD>Сначала автоматизационный bat-ник CD>Потом пришлось коснуться питона, показалось интересным, теперь у меня автоматизационный py-тник CD>Один раз все сделать и потом ничего не трогать, ибо работает.
А если в очередной раз не сработает? Например, при обновлении сайта отвалился интернет, и часть файлов/ссылок осталась необновленной. Или у регистратора файл с продуктом обновили, а ключи обновить не получилось.
ЕМ>А если в очередной раз не сработает? Например, при обновлении сайта отвалился интернет, и часть файлов/ссылок осталась необновленной. Или у регистратора файл с продуктом обновили, а ключи обновить не получилось.
после обновления, все проверяется, автоматизировано скачиваются файлы, проверяются хэши, загружаются страницы (в моем случае запрашиваются сервисы) проверяется на соответсвие версий, текста и т.п.
ЕМ> чтобы при сбое посреди процесса не получилось неразберихи.
В случае сбоя процесс завершится с кодом ошибки и о наличии ошибки станет известно.
ЕМ> рассинхронизацией глобальных состояний (сайт, регистратор и все остальное в интернете)
Если процесс закончится успешно — рассинхронизаций не будет.
А ошибки автоматически исправить нельзя, надо разбираться, в чём их суть.
Здравствуйте, Crimson, Вы писали:
C>после обновления, все проверяется, автоматизировано скачиваются файлы, проверяются хэши, загружаются страницы (в моем случае запрашиваются сервисы) проверяется на соответсвие версий, текста и т.п.
А если что-то пойдет не так, оно в автоматическом режиме сумеет все исправить, или уже нужно будет руками?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>В случае сбоя процесс завершится с кодом ошибки и о наличии ошибки станет известно.
Я правильно понимаю, что конкретно у Вас автоматизация заключается только в сборке через MSBuild, но Вам нравится давать абстрактные и универсальные советы?
Здравствуйте, Черный Властелин, Вы писали:
ЧВ>Выглядит примерно так
Из этого все, кроме заливки, у меня уже сделано на скриптах. Основной геморрой возникает при ручном обновлении продуктов у регистраторов (PayPro и Avangate). Так что прежде всего интересует, насколько удобно/надежно обновлять через их API.
Здравствуйте, Евгений Музыченко, Вы писали: ЕМ>Из этого все, кроме заливки, у меня уже сделано на скриптах. Основной геморрой возникает при ручном обновлении продуктов у регистраторов (PayPro и Avangate). Так что прежде всего интересует, насколько удобно/надежно обновлять через их API.
Хм, а что там нужно обновлять у регистратора? Я как завел продукты, туда больше не лазил.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>У кого-нибудь сделана полная автоматизация релиза — от сборки бинарников до обновления данных на сайте и у регистратора? Если да, то какими средствами, насколько геморройно было сделать и потом поддерживать? Если нет, то какие действия остались ручными?
ЕМ>И как решается вопрос с восстановлением, если в середине процесса что-то пошло не так?
Пользуемся Bamboo: сборка, тестирование, выкладывание на FTP.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>У кого-нибудь сделана полная автоматизация релиза — от сборки бинарников до обновления данных на сайте и у регистратора? Если да, то какими средствами, насколько геморройно было сделать и потом поддерживать? Если нет, то какие действия остались ручными?
похопэ скрипт, написал 15 лет назад, все работает, ну и не трогаю
ребилд, защита, инсталлеры, подписи, новости, сайт, и т.д.
релиз выглядит как:
— написание списка "что нового" по мотивам лога SVN
— указание нового номера версии
— запустить скрипт
— коммит в SVN
— апдейт из SVN на сервере
5 минут на всё, не понимаю смысла всех этих систем сборки
ЕМ>И как решается вопрос с восстановлением, если в середине процесса что-то пошло не так?
если что-то пошло не так (билд не сбыдлился или подписью не подписалось),
то все упадет с ошибкой — ну исправил, перезапустил, какое там восстановление и зачем
ЕМ>А если что-то пойдет не так, оно в автоматическом режиме сумеет все исправить, или уже нужно будет руками?
Можно еще раз запустить если проблемы технические, а если проблемы действительно проблемы то только руками
может быть все что угодно. на то они и проблемы
А почему в самом инносетапе не настроишь подпись?
В твоем варианте анинсталлер остается неподписанным.
сам инно умеет подписывать как анинсталлер так и сам инсталлер.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>И как решается вопрос с восстановлением, если в середине процесса что-то пошло не так?
Я как шароварщик-одиночка, однажды осознал, что сборка и публикация дистрибутива стала занимать у меня неприлично много времени. Поэтому я настроил себе так: при комите в спец.ветку в гит
— компилируется код и прогоняются все тесты
— из бинарников выдирается номер(версия) релиза
— файлы с отладочными данными копируются в спец папку
— номер версии вносится в скрипты сборки дистрибутивов
— собираются дистрибутивы в msi, в zip и в NuGet
— старые дистрибутиве на сайте копируются в папку для старых дистров
— новы дистрибутивы заменяют старые
— выкладывается пакет в нугет репозитарий
— обновляется новая версия на сайте
— в репозитории ставится метка, что данный коммит опубликован.
Ручная работа:
— Присвоить номер (версию) очередному релизу.
— смержить из рабочей ветки в Дистрибутивную
— пока там все собирается и выкладывается написать на форум release notes
У агрегатора ничего менять не надо вроде. Номера версий я там из описаний убрал.
Ключи генерятся через IPN. Что там еще у регистратора?
Когда ломается то приходится смотреть по ситуации. В большинстве случае достаточно перезапустить скрипт. Приходилось и руками править/откатывать что-то. Но это очень редко.
Файлы заливаются по фтп. Обычно только там и ломается. Файлы я вначале заливаю под временным именем и после успешной заливки всех файлов уже произвожу замену. Если сломалось именно на этапе замены, то приходится вручную исправлять и доделывать то, что не сделал скрипт — это гемор. Но бывает слава богу очень редко.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>У кого-нибудь сделана полная автоматизация релиза — от сборки бинарников до обновления данных на сайте и у регистратора? Если да, то какими средствами, насколько геморройно было сделать и потом поддерживать? Если нет, то какие действия остались ручными?
Я сейчас все на Azure Pipelines перевел (yaml + powershell скрипты). Все работает, все бесплатно
Автоматически делается
— Обновление версии в исходниках из конфига,
— сборка бинарников из исходников,
— тесты,
— сборка инсталляторов,
— подписывание,
— выкладывание на сайт по FTP и на части github (через GIT, понятно)
— генерируется заготовка release notes на основе коммитов (у меня код на GH, в закрытом репозитории)
— на сайте обновляется страница скачки.
Вручную
— задается мажорный номер версии в yaml (build проставляется текущей датой + номер сборки)
— Пишется release notes на сайте.
А что именно обновлять у регистратора? У меня PP, ключ генерируется на моем сервере.
ЕМ>И как решается вопрос с восстановлением, если в середине процесса что-то пошло не так?
Можно пример, что там восстанавливать.. Просто запустить процесс еще раз да и все?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Хм, мне казалось, что я достаточно ясно сформулировал вопрос. То, что можно прикрутить любой тулчейн, ясно и ребенку — вопрос в том, как именно этот тулчейн должен работать, чтобы при сбое посреди процесса не получилось неразберихи.
Я думаю тут важно, что версия например должна задаваться строго вручную, тогда процесс можно перезапускать сколько угодно раз с тем же результатом.
Релиз ноты не должны автоматом аппендиться, ну и т.п. Иденпотентность важна в общем
