Доклад InfostartEvent2014 c дополнениями


#1

Оказывается наш форум прекрасно вставляет slideshare

Последняя презентация с InfostartEvent2014

В презентацию добавлены вопросы из малого зала.
Примеры скриптов можно обнаружить в: https://github.com/xDrivenDevelopment/AutoAdmin1C/tree/develop/Scripts


#2

Всем доброго времени суток! :smile:
Я вновь хотел бы вернуться к обсуждению темы о процессе разработки.
Алексей, ты на докладе не все пункты пояснил, быть может где-то что-то кому-то очевидно, однако, я не вхожу в эту группу и потому мне не все понятно.
Для начала, хочу вернуться к сравнению hotfix = динамическое обновление.
На мой взгляд тут больше hotfix = ручная сборка. Осуществить hotfix на продакшене через динамическое обновление можно при учете только демонтрации релиза или если мы выпускаем релиз под одну конректную базу. А если брать процесс под розничную сеть? Как в таком случае представлен будет hotfix? И вот тут наверно было бы еще интересно услышать Артура ему это должно быть ближе.
Ну, и вот еще один момент, а что если динамического обновления вообще бы не было- вот не придумали его в 1С, как быть тогда?

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


ну, как-то так) не бросайте тапками :smile:


#3

Ну во-первых доклад пришлось совсем ужать и превратить в “подставу-вброс” - обычно на тему доклада я на своих курсах трачу от 4 до 8 часов на ВСЕ объяснения.

Конкретные исходные кода были выложены в репозитории https://github.com/xDrivenDevelopment/AutoAdmin1C/tree/develop/Scripts
Как их писать рассказал @EvilBeaver сразу передо мной.

Поэтому действительно ни один из вопросов не развернут до конца - отсюда и многое непонятно

С другой стороны вернемся к теме с хотфиксами.

Я обычно ссылаюсь на стандарты, есть 2 тезиса:

  1. иногда в процессе разработки любого ПО и не только 1С выявляется необходимость исправить некоторое небольшое поведение кода, приводящее к невозможности работы ПО. Неудобство работы НЕ равно невозможности работы.
  2. считается что такое изменение необходимо производить напрямую на production. В связи с тем что приоритетней обеспечить работоспособность системы, нежели чем идти по стандартному процессу через релизы

Эти 2 тезиса относятся к процессу обеспечения/поддержки систем

с другой стороны есть несколько тезисов из процесса разработки (а не поддержки)

  1. разработку необходимо вести и проводить через последовательные контуры dev -> cert -> prod
  2. поставка кода должна осуществляться через версионированные дистрибутивы (релизить релизы)
  3. любая рутинная деятельность должна быть автоматизирована

в этом и кроется проблема: с одной стороны необходимо разрабатывать по правильному, с другой стороны - иногда приходится нарушать процесс в угоду работоспособности ПО

Теперь если перейти к 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’ов по правильному :wink:


#4

Обсуждать более нечего! :slight_smile:
Теперь все стало ясно, так сказать прояснение снизошло) Премного благодарен.


Типовые сценарии развертывания 1С конфигураций
#6

Согласен - только в качестве крайней меры. Один раз на моей памяти нас с @berezdetsky это спасло, но решится на подобный hotfix мы смогли, только после долгого и мучительного выбора “рисковать или нет”.

C хотфиксами связана одна очень НЕприятная особенность: они действительно быстрые и горячие, но ОЧЕНЬ рискованные… видимо за счет своей быстроты. :wink:

Я же не рекомендовал в докладе их использовать, я говорил что именно это является попыткой “реализовать стандарт” - напомню Microsoft только в особо экстренных случаях может выпустить Hotfix/ Необходимость подобного означает конкретную и системную проблему в работе над продуктом.


#7

Пересмотрел видео выступления. Мне показалось, что все решили каждую ночь, после успешной сборки, сразу же и разворачивать на рабочей базе, так сказать сразу в production. Почему такое впечатление произвело, я не знаю.


#8

а что видео уже выложили ?


#9

Да http://infostart.ru/video/16773/