Оказывается наш форум прекрасно вставляет slideshare
Последняя презентация с InfostartEvent2014
В презентацию добавлены вопросы из малого зала.
Примеры скриптов можно обнаружить в: https://github.com/xDrivenDevelopment/AutoAdmin1C/tree/develop/Scripts
Всем доброго времени суток! 
Я вновь хотел бы вернуться к обсуждению темы о процессе разработки.
Алексей, ты на докладе не все пункты пояснил, быть может где-то что-то кому-то очевидно, однако, я не вхожу в эту группу и потому мне не все понятно.
Для начала, хочу вернуться к сравнению hotfix = динамическое обновление.
На мой взгляд тут больше hotfix = ручная сборка. Осуществить hotfix на продакшене через динамическое обновление можно при учете только демонтрации релиза или если мы выпускаем релиз под одну конректную базу. А если брать процесс под розничную сеть? Как в таком случае представлен будет hotfix? И вот тут наверно было бы еще интересно услышать Артура ему это должно быть ближе.
Ну, и вот еще один момент, а что если динамического обновления вообще бы не было- вот не придумали его в 1С, как быть тогда?
з.ы. в моем понимании все-таки hotfix – это патч, а патчи собирают руками и уж если мы автоматизируем процесс сборки, тогда мы должны и регламентировать процесс выходов релизов в продакшн, разве не так? А уж если регламентируем подобного рода процесс, тогда мы учитываем, что выход пожарного патча мы собираем руками, а уж не дебажим релиз вышедший на продакшн базе с вероятность положить продакшн диманическим обновлением. 
ну, как-то так) не бросайте тапками
Ну во-первых доклад пришлось совсем ужать и превратить в “подставу-вброс” - обычно на тему доклада я на своих курсах трачу от 4 до 8 часов на ВСЕ объяснения.
Конкретные исходные кода были выложены в репозитории https://github.com/xDrivenDevelopment/AutoAdmin1C/tree/develop/Scripts
Как их писать рассказал @EvilBeaver сразу передо мной.
Поэтому действительно ни один из вопросов не развернут до конца - отсюда и многое непонятно
С другой стороны вернемся к теме с хотфиксами.
Я обычно ссылаюсь на стандарты, есть 2 тезиса:
Эти 2 тезиса относятся к процессу обеспечения/поддержки систем
с другой стороны есть несколько тезисов из процесса разработки (а не поддержки)
в этом и кроется проблема: с одной стороны необходимо разрабатывать по правильному, с другой стороны - иногда приходится нарушать процесс в угоду работоспособности ПО
Теперь если перейти к 1С - напомню, что “дядьки” авторы платформы всё вышеуказанное знают и им было необходимо дать помимо функционала разработки еще и функционал “быстрых исправлений”
Так вот - функционал динамического обновления “полностью” реализован по Википедии
НО у нас есть законы разработки, все должно разрабатываться, тестироваться, собираться и разворачиваться.
И бэкапироваться … Я не зря сказал, что можно и нужно бэкапить системные таблицы.
Зная это таким образом мы можем автоматизировать процесс Hotfix’ов - только в таком случае сборка будет осуществляться из стабильного ствола/хранилища. И никакого ручного труда не будет.
P.S. Кстати - hotfix’ы совершенно не отменяют тесты, причем такие тесты пишутся достаточно быстро, так как проблемная ситуация чаще всего простая
P.S.S. Не знаю насколько понятно я сейчас написал, можно попробовать еще обсудить
Если кто-то знает английский посмотрите http://blogs.endjin.com/2013/04/a-step-by-step-guide-to-using-gitflow-with-teamcity-part-3-gitflow-commands/ в конце есть описание hotfix’ов по правильному 
Обсуждать более нечего! 
Теперь все стало ясно, так сказать прояснение снизошло) Премного благодарен.
Согласен - только в качестве крайней меры. Один раз на моей памяти нас с @berezdetsky это спасло, но решится на подобный hotfix мы смогли, только после долгого и мучительного выбора “рисковать или нет”.
C хотфиксами связана одна очень НЕприятная особенность: они действительно быстрые и горячие, но ОЧЕНЬ рискованные… видимо за счет своей быстроты.
Я же не рекомендовал в докладе их использовать, я говорил что именно это является попыткой “реализовать стандарт” - напомню Microsoft только в особо экстренных случаях может выпустить Hotfix/ Необходимость подобного означает конкретную и системную проблему в работе над продуктом.
Пересмотрел видео выступления. Мне показалось, что все решили каждую ночь, после успешной сборки, сразу же и разворачивать на рабочей базе, так сказать сразу в production. Почему такое впечатление произвело, я не знаю.
а что видео уже выложили ?