Начну с истории. Устроился на новую работу и одно из первых, серьезных заданий было обновить Бухгалтерию (4 по идее идентичных базы и 1 немного отличалась). Кроме того что было добавлено субконто 4, информации о том что изменено, где и почему я не получил. Сравнивать с конфигурацией поставщика смысла не было, потому что ей было уже ~2года и с тех пор нормального обновления не было. Сравнив с той версией, которая якобы была на базах, я понял, что это тоже бессмысленно. Спросил про комментирование кода, своими подписями, напарник сказал, что оно было, но не всегда.
Долго думал что делать, читал разные статьи. Делал следующим образом: набросал по быстрому конфу с отображением изменений, назвал «Конфигурация для хранения изменений типовых конфигураций», которая во вложении. Прошел по всем бухгалтерам, менеджерам, посидел, посмотрел что делают, записывал, что нетиповое встречается. Все собранные изменения завел в справочнике своей конфигурации. Потом сел и глобальным поиском в старой конфе добавлял во все комментарии (конфу меняли несколько человек, комментарии у всех разные) свой глобальный комментарий, советую не свой псевдоним, а например сокращение компании, чтобы не кому обидно не было и еще хорошо добавлять причину изменений.
Скопировал старую конфигурацию, накатил на нее обновление, назвал ее новой. Потом открыл старую конфигурацию и запустил на ней обновление, чтобы увидеть окно сравнения объединения, но не накатывал, это необходимо только чтобы увидеть что изменили.
В старой конфигурации запустил глобальный поиск на добавленный комментарий, потом открыл новую конфигурацию и стал перетаскивать код по измененным модулям, что видно в окне сравнения объединения в старой конфигурации. Очень помогает сочетание – «Ctrl + G», смотришь номер строки в модуле старой конфы, ищешь эту строку в новой, зачастую изменение количества строк при обновлении незначительные. Так же по отчету из своей конфигурации смотрел, что изменено в обновленных метаданных, помимо кода. Советую после переноса всех своих изменений результат глобального поиска по глобальному комментарию в старой и обновленной конфигурации перекидывать в Excel и проверять совпадение количества строк, ну и разбираться, если не совпадает что где. Так же хорошо помогает ведение таблицы, что необходимо проверить после обновления, дабы не накатить обновление на рабочую базу с явными ошибками. Я перепровел квартал в двух тестовых конфигурациях, на новой и старой конфигурации, сравнил дебиторки и решил пробовать на базе с самым маленьким количеством отгрузок в день. Я не поверил, но все было нормально. Никто даже не заметил, что обидно, ну или наоборот. С поддержки рабочие базы необходимо снять!, потому что при сравнении объединении надо удалять типовые метаданные которые удалили при обновлении, особенно подписки на события и т.п.
Потом обновления делать проще, кратко — распечатываешь себе лист с изменениями, копируешь старую конфигурацию называешь Новая и на нее накатываешь обновление. Потом открываешь старую, делаешь сравнение объединение, без вполнить и смотришь какие объекты изменились, исходя из этого в новую из старой перетаскиваешь свои изменения согласно отчету из конфигурации и распечатанному листу изменений кода.
Так я делал 2,5 года, время обновления сократилось с недели до половины дня, не было косяков после обновления. Осенью 2012г. бухгалтерию ПРОФ 2.0 переводил на КОРП 2.0, сделал все по этой схеме, работает. Весь первый квартал 2014 года перетаскивал все изменения на бухгалтерию 3.0 ПРОФ, кстати в 3.0 все изменения формы надо делать в коде, при создании на сервере и чтение на сервере, подписку к сожалению, путевую, пока не сделали. Недавно уволился из той компании и передал свою базу и данную технологию напарнику, это было намного круче чем то, как передали эти изменения мне – «там много изменений, что где не знаем».
Надеюсь моя писанина кому то поможет).
Совет, а может просьба, всегда комментируйте и ведите в каком-то виде изменения. Которые потом передавайте руководителю или начальнику отдела, иначе придёт человек и как я, с трясущимися руками) будет делать опыты. Это касается и баз УТ и т.п., о которых думают не Бух, не ЗУП, обновлять не буду.
В моей конфигурации удобно вести сколько угодно измененных типовых конфигураций, иногда возникает задача узнать что менялось под определенную задачу, это легко посмотреть в отчете моей конфигурации, с помощью отбора по проекту.
Кстати советую сразу 2 монитора)
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Читали, может быть, и много, но не то, судя по всему..
Для ведения изменений я бы все же взял хранилище, а не отдельную конфу, хотя это дело вкуса.
Вроде все это было уже…
Я читал много разных методов, тот который в комментарии выше я тоже читал(очень много написано и как то все сложно) у меня метод простой, есть 1 конфигурация на поддержке и я просто на каждый новый релиз ее копирую, обновляю, открываю прошлый релиз(+мойФункционал) запускаю обновление, смотрю какие объекты обновились и в обновленный релиз перетаскиваю свой функционал из прошлого релиза(+мой функционал).
В основном история про то как ты устраиваешься на новую работу, там разные люди в бухгалтерии что то делали, нету списка изменений, и как я вышел из этой ситуации.
Как по мне, так велосипед.
Проще сравнением с типовой накидать изменённые объекты (либо кратким отчетом о сравнении выдернуть дерево, и потом дополнить), дополнить своими комментариями — и вперёд.
(4) cratos2, 1) повторю, типовая была древней, обновления делались простым сравнением, без замены типовой, но при сравнении с версией конфы было много отличий, у меня 3 версии Бухгалтерии, 2 версии ПРОФ, 1 версия КОРП, я делаю обновление в среднем 1 рабочий день. За год не разу не накосячил. Мой отчет очень информативен что, для чего, где. Я вижу что объект изменен смотрю что менял в реквизитах формах итп. по отчету. Потом нажимаю построчно на результат поиска по своей подписи и копипастом перетаскиваю в обновленную конфу из прошлой. Ты код из Excel предлагаешь перетаскивать? Как вести свои изменения все равно, я лишь предложил самый удобный для меня вариант. Как ты будешь проверять после обновления ? я просто сравниваю в Excel количество вставок кода поиском в конфе до обновления и в конфе после обновления.
(5) rar_xxx, согласен. Ещё раз перечитал твой пост — ох и сложно его читать, этот поток мыслей…
Согласен, мой комментарий для тех случаев, когда ты внешний сотрудник, и надо по-быстрому окучить эти необкомментированные дописки — и карта последующих обновлений готова (типа открыть эксель и пройтись по всем этим выноскам), и заказчику предоставить отчет.
Однако, так и не понял, зачем в отдельную конфу выносить пояснения, когда их легче в основной вставить?
И да, из экселя легко копировать при надобности куски кода, обычным ctrl-C ctrl+V. Или ты имеешь в виду какие-то другие сложности?
И не понял про количества вставок кода… Попроцедурное сравнение не катит?
В общем, подход больше напоминает изготовление конфигурации обновления, а не само обновление конфигурации. Так можно нормально обновляться, используя «свою» измененныую cf-ку. Первый раз, все же, надо пройти болезненный путь обновления до типовой с дописками. Я бы делил изменения в типовой на изменения в структуре конфигурации(добавление реквизитов, изменения разрядности реквизитов) и на изменение модулей объектов, форм и т.д. В первом случае нужно обновлять и до записи изменений возвращать в исходное положение измененные объекты конфигурации, чтобы не потерять набранные данные. Во втором — безболезенно «накатывать» типовую, а потом вносить поверху сделанные изменения. Кому как удобно, пусть решает самостоятельно …
Есть несколько баз(по количество различных конфигураций, у меня 3), нерабочих, только для обновления, находятся на текущей поддержке. Перед обновлением копируешь базу, одну обновляешь, вторую нет. Из той которую не обновлял перетаскиваешь текст модулей и т.п. ориентируешься по дереву сравнения конфигураций, которое появляется после начала обновления базы. Надо перетащить только то что изменилось после обновления.
А я знаю эту организацию, проработал там 1,5 месяца. Столкнулся как со сбитыми id, так с ошибками уникальности объектов, ошибками удаления, жуткими тормозами сервака и тд. На мой взгляд процедуры обновления хорошо описаны в книге «Профессиональное программирование в среде 1с» и не всегда интересно изобретать велосипед
(9) fenixnow, слышал отзывы о вашей работе, мягко говоря меньше нуля, из всех отделов компании, наверно все вокруг было косячным, глючило и все дураки.
Книга называется «Профессиональная разработка в системе «1С:Предприятие 8″»,при написании статьи я предполагал что читающий умеет полноценно работать с сравнением объединением и в частности, я разбираю ситуацию изменения типовых модулей, при обновлении объединять модули крайне не советую и утверждаю что лучше заново перетащить все свои изменения в полностью замененный типовой модуль, при этом необходимо анализировать, а не поменялся ли алгоритм типового модуля, из за чего будет либо не работать, либо глючить ваша вставка. Так же к сожалению, подписки на события пока не работают, как хотелось бы и пока 1с идет к созданию слоев как в Axapta и т.п., приходится менять типовые модули.
(1) ситуации разные бывают… хранилище не всегда возможно использовать. Поэтому, как всегда начинаем с табличного файлика и заканчиваем собственной конфигурацией, ну или СППР 🙂