Всем доброго времени суток!
Я вновь хотел бы вернуться к обсуждению темы о процессе разработки.
Алексей, ты на докладе не все пункты пояснил, быть может где-то что-то кому-то очевидно, однако, я не вхожу в эту группу и потому мне не все понятно.
Для начала, хочу вернуться к сравнению hotfix = динамическое обновление.
На мой взгляд тут больше hotfix = ручная сборка. Осуществить hotfix на продакшене через динамическое обновление можно при учете только демонтрации релиза или если мы выпускаем релиз под одну конректную базу. А если брать процесс под розничную сеть? Как в таком случае представлен будет hotfix? И вот тут наверно было бы еще интересно услышать Артура ему это должно быть ближе.
Ну, и вот еще один момент, а что если динамического обновления вообще бы не было- вот не придумали его в 1С, как быть тогда?
з.ы. в моем понимании все-таки hotfix – это патч, а патчи собирают руками и уж если мы автоматизируем процесс сборки, тогда мы должны и регламентировать процесс выходов релизов в продакшн, разве не так? А уж если регламентируем подобного рода процесс, тогда мы учитываем, что выход пожарного патча мы собираем руками, а уж не дебажим релиз вышедший на продакшн базе с вероятность положить продакшн диманическим обновлением.
Ну во-первых доклад пришлось совсем ужать и превратить в “подставу-вброс” - обычно на тему доклада я на своих курсах трачу от 4 до 8 часов на ВСЕ объяснения.
Поэтому действительно ни один из вопросов не развернут до конца - отсюда и многое непонятно
С другой стороны вернемся к теме с хотфиксами.
Я обычно ссылаюсь на стандарты, есть 2 тезиса:
иногда в процессе разработки любого ПО и не только 1С выявляется необходимость исправить некоторое небольшое поведение кода, приводящее к невозможности работы ПО. Неудобство работы НЕ равно невозможности работы.
считается что такое изменение необходимо производить напрямую на production. В связи с тем что приоритетней обеспечить работоспособность системы, нежели чем идти по стандартному процессу через релизы
Эти 2 тезиса относятся к процессу обеспечения/поддержки систем
с другой стороны есть несколько тезисов из процесса разработки (а не поддержки)
разработку необходимо вести и проводить через последовательные контуры dev -> cert -> prod
поставка кода должна осуществляться через версионированные дистрибутивы (релизить релизы)
любая рутинная деятельность должна быть автоматизирована
в этом и кроется проблема: с одной стороны необходимо разрабатывать по правильному, с другой стороны - иногда приходится нарушать процесс в угоду работоспособности ПО
Теперь если перейти к 1С - напомню, что “дядьки” авторы платформы всё вышеуказанное знают и им было необходимо дать помимо функционала разработки еще и функционал “быстрых исправлений”
Так вот - функционал динамического обновления “полностью” реализован по Википедии
НО у нас есть законы разработки, все должно разрабатываться, тестироваться, собираться и разворачиваться.
И бэкапироваться … Я не зря сказал, что можно и нужно бэкапить системные таблицы.
Зная это таким образом мы можем автоматизировать процесс Hotfix’ов - только в таком случае сборка будет осуществляться из стабильного ствола/хранилища. И никакого ручного труда не будет.
P.S. Кстати - hotfix’ы совершенно не отменяют тесты, причем такие тесты пишутся достаточно быстро, так как проблемная ситуация чаще всего простая
P.S.S. Не знаю насколько понятно я сейчас написал, можно попробовать еще обсудить
Согласен - только в качестве крайней меры. Один раз на моей памяти нас с @berezdetsky это спасло, но решится на подобный hotfix мы смогли, только после долгого и мучительного выбора “рисковать или нет”.
C хотфиксами связана одна очень НЕприятная особенность: они действительно быстрые и горячие, но ОЧЕНЬ рискованные… видимо за счет своей быстроты.
Я же не рекомендовал в докладе их использовать, я говорил что именно это является попыткой “реализовать стандарт” - напомню Microsoft только в особо экстренных случаях может выпустить Hotfix/ Необходимость подобного означает конкретную и системную проблему в работе над продуктом.
Пересмотрел видео выступления. Мне показалось, что все решили каждую ночь, после успешной сборки, сразу же и разворачивать на рабочей базе, так сказать сразу в production. Почему такое впечатление произвело, я не знаю.