Сообщение Re: Автоматизация релиза от 17.07.2020 11:40
Изменено 17.07.2020 11:49 NWP
Re: Автоматизация релиза
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>И как решается вопрос с восстановлением, если в середине процесса что-то пошло не так?
Я как шароварщик-одиночка, однажды осознал, что сборка и публикация дистрибутива стала занимать у меня неприлично много времени. Поэтому я бы настроил себе так: при комите в спец.ветку в гит
— компилируется код и прогоняются все тесты
— из бинарников выдирается номер(версия) релиза
— файлы с отладочными данными копируются в спец папку
— номер версии вносится в скрипты сборки дистрибутивов
— собираются дистрибутивы в msi, в zip и в NuGet
— старые дистрибутиве на сайте копируются в папку для старых дистров
— новы дистрибутивы заменяют старые
— выкладывается пакет в нугет репозитарий
— обновляется новая версия на сайте
— в репозитории ставится метка, что данный коммит опубликован.
Ручная работа:
— Присвоить номер (версию) очередному релизу.
— смержить из рабочей ветки в Дистрибутивную
— пока там все собирается и выкладывается написать на форум release notes
У агрегатора ничего менять не надо вроде. Номера версий я там из описаний убрал.
Когда ломается то приходится смотреть по ситуации. В большинстве случае достаточно перезапустить скрипт. Приходилось и руками править/откатывать что-то. Но это очень редко.
ЕМ>И как решается вопрос с восстановлением, если в середине процесса что-то пошло не так?
Я как шароварщик-одиночка, однажды осознал, что сборка и публикация дистрибутива стала занимать у меня неприлично много времени. Поэтому я бы настроил себе так: при комите в спец.ветку в гит
— компилируется код и прогоняются все тесты
— из бинарников выдирается номер(версия) релиза
— файлы с отладочными данными копируются в спец папку
— номер версии вносится в скрипты сборки дистрибутивов
— собираются дистрибутивы в msi, в zip и в NuGet
— старые дистрибутиве на сайте копируются в папку для старых дистров
— новы дистрибутивы заменяют старые
— выкладывается пакет в нугет репозитарий
— обновляется новая версия на сайте
— в репозитории ставится метка, что данный коммит опубликован.
Ручная работа:
— Присвоить номер (версию) очередному релизу.
— смержить из рабочей ветки в Дистрибутивную
— пока там все собирается и выкладывается написать на форум release notes
У агрегатора ничего менять не надо вроде. Номера версий я там из описаний убрал.
Когда ломается то приходится смотреть по ситуации. В большинстве случае достаточно перезапустить скрипт. Приходилось и руками править/откатывать что-то. Но это очень редко.
Re: Автоматизация релиза
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>И как решается вопрос с восстановлением, если в середине процесса что-то пошло не так?
Я как шароварщик-одиночка, однажды осознал, что сборка и публикация дистрибутива стала занимать у меня неприлично много времени. Поэтому я настроил себе так: при комите в спец.ветку в гит
— компилируется код и прогоняются все тесты
— из бинарников выдирается номер(версия) релиза
— файлы с отладочными данными копируются в спец папку
— номер версии вносится в скрипты сборки дистрибутивов
— собираются дистрибутивы в msi, в zip и в NuGet
— старые дистрибутиве на сайте копируются в папку для старых дистров
— новы дистрибутивы заменяют старые
— выкладывается пакет в нугет репозитарий
— обновляется новая версия на сайте
— в репозитории ставится метка, что данный коммит опубликован.
Ручная работа:
— Присвоить номер (версию) очередному релизу.
— смержить из рабочей ветки в Дистрибутивную
— пока там все собирается и выкладывается написать на форум release notes
У агрегатора ничего менять не надо вроде. Номера версий я там из описаний убрал.
Ключи генерятся через IPN. Что там еще у регистратора?
Когда ломается то приходится смотреть по ситуации. В большинстве случае достаточно перезапустить скрипт. Приходилось и руками править/откатывать что-то. Но это очень редко.
Файлы заливаются по фтп. Обычно только там и ломается. Файлы я вначале заливаю под временным именем и после успешной заливки всех файлов уже произвожу замену. Если сломалось именно на этапе замены, то приходится вручную исправлять и доделывать то, что не сделал скрипт — это гемор. Но бывает слава богу очень редко.
ЕМ>И как решается вопрос с восстановлением, если в середине процесса что-то пошло не так?
Я как шароварщик-одиночка, однажды осознал, что сборка и публикация дистрибутива стала занимать у меня неприлично много времени. Поэтому я настроил себе так: при комите в спец.ветку в гит
— компилируется код и прогоняются все тесты
— из бинарников выдирается номер(версия) релиза
— файлы с отладочными данными копируются в спец папку
— номер версии вносится в скрипты сборки дистрибутивов
— собираются дистрибутивы в msi, в zip и в NuGet
— старые дистрибутиве на сайте копируются в папку для старых дистров
— новы дистрибутивы заменяют старые
— выкладывается пакет в нугет репозитарий
— обновляется новая версия на сайте
— в репозитории ставится метка, что данный коммит опубликован.
Ручная работа:
— Присвоить номер (версию) очередному релизу.
— смержить из рабочей ветки в Дистрибутивную
— пока там все собирается и выкладывается написать на форум release notes
У агрегатора ничего менять не надо вроде. Номера версий я там из описаний убрал.
Ключи генерятся через IPN. Что там еще у регистратора?
Когда ломается то приходится смотреть по ситуации. В большинстве случае достаточно перезапустить скрипт. Приходилось и руками править/откатывать что-то. Но это очень редко.
Файлы заливаются по фтп. Обычно только там и ломается. Файлы я вначале заливаю под временным именем и после успешной заливки всех файлов уже произвожу замену. Если сломалось именно на этапе замены, то приходится вручную исправлять и доделывать то, что не сделал скрипт — это гемор. Но бывает слава богу очень редко.