Сейчас имеем три конфигурации с включенной возможностью внесения измений:
В данный момент учет внесенных измений ведется в Excel файле с внешними ссылками на картинки, тексты модулей(HTML) и т.д.(прикреплен скриншот).
Интересует вопрос, кто чем пользуется и нет ли готового решения?
Есть желание написать конфигурацию для ведения подобного учета. Но велосипед изобретать не хочется
- УПП 1.3
- Документооборот
- Управление автотранспортом
В данный момент учет внесенных измений ведется в Excel файле с внешними ссылками на картинки, тексты модулей(HTML) и т.д.(прикреплен скриншот).
Интересует вопрос, кто чем пользуется и нет ли готового решения?
Есть желание написать конфигурацию для ведения подобного учета. Но велосипед изобретать не хочется
Прикрепленные файлы:
По теме из базы знаний
- Стандартизация внесения изменений в конфигурацию
- Учет внесенных изменений в конфигурацию.
- Печатная форма ИНВ-8а "Инвентаризационная опись драгоценных металлов, содержащихся..." и организация учета драгоценных металлов в ОС на предприятии для типовых конфигураций 1С, обычное приложение
- Краткое руководство по внесению изменений в конфигурацию
- Внесение изменений в выгрузку торгового каталога из 1С: УПП (обычные формы, платформа 8.3) на сайт с помощью стандартной обработки 1С Битрикс
Как вы ведете учет изменений внесенных в типовую КОНФИГУРАЦИЮ
В бумажном виде(в журнале, тетради, ...) (27.86%, 112 голосов)
27.86%
В виде excel-файла (33.33%, 134 голосов)
33.33%
В вид другой программе офисного пакета (11.69%, 47 голосов)
11.69%
Использую специальную программу не на платформе 1С:Предприятие (4.98%, 20 голосов)
4.98%
Использую специальную конфигурацию на платформе 1С:Предприятие (22.14%, 89 голосов)
22.14%
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(22) alexpa2005, разве линейная история хранилища позволяет понять что и где и кем изменено? Конечно лучше хранилище использовать чем вообще ничего.
(23) Lerka2611, разве так можно? У вас сферический конь в вакууме? Я понимаю что надо стремится к такому, но прямо что-бы все доработки так вот раз и типового не задели - не верю.
(0) ждите 8.3 там можно будет использовать альтернативные системы контроля версий и тогда трехуровневое сравнение вам поможет.
(23) Lerka2611, разве так можно? У вас сферический конь в вакууме? Я понимаю что надо стремится к такому, но прямо что-бы все доработки так вот раз и типового не задели - не верю.
(0) ждите 8.3 там можно будет использовать альтернативные системы контроля версий и тогда трехуровневое сравнение вам поможет.
(29) echo77,
Да не вопрос. 700 руб/час, даешь заранее конфигу (лучше конечно базу), Я заранее подготавливаю обновленную конфигу, ставится за час (ну или больше - зависит от кол-ва пропущенных обновлений), дальше вопрос только в реструктуризации данных. Насчет массовости ошибок - какие-то ошибки все равно вылезут, все баги отловить нереально, естественно постараюсь чтобы их было как можно меньше. Насчет заплачу - не заплачу, заключим договор ГПХ, все распишем... Велкам в личку.
ЗЫ Напугал ежа голой попой. Если вариант сравнения с конфигурацией поставщика не устраивает - так и пиши, не подходит потому и поэтому, сложно отслеживать это и то...
Да не вопрос. 700 руб/час, даешь заранее конфигу (лучше конечно базу), Я заранее подготавливаю обновленную конфигу, ставится за час (ну или больше - зависит от кол-ва пропущенных обновлений), дальше вопрос только в реструктуризации данных. Насчет массовости ошибок - какие-то ошибки все равно вылезут, все баги отловить нереально, естественно постараюсь чтобы их было как можно меньше. Насчет заплачу - не заплачу, заключим договор ГПХ, все распишем... Велкам в личку.
ЗЫ Напугал ежа голой попой. Если вариант сравнения с конфигурацией поставщика не устраивает - так и пиши, не подходит потому и поэтому, сложно отслеживать это и то...
(51) Lerka2611, не знаю чем это отличается от нетленки. Мне кажется, у вас безпроблемное обновление иногда может вылится в проблемы с логикой работы в базе, т.к. автоматическое обновление (пропуск не дважды изменненых) может поменять логику работы, а подписки забудите сменить и через некоторое время могут полезьт проблемы.
Може у вас активно используются тесты и вы можете провести функциональное тестирование?
Може у вас активно используются тесты и вы можете провести функциональное тестирование?
(1) echo77, самое простое - штатное хранилище конфигурации. Но тут нужно аккуратно вести записи, т.е. заставлять народ который работает с вами ставить нормальные комментарии при изменениях.
Работает всё просто - есть ваша конфигурация, есть хранилище. Подключаясь к хранилищу вы замещаете свою конфигурацию той из хранилища.
Далее при изменениях "захватываете" объект из хранилища, и работаете с ним. Как только закончили - помещаете его обратно в хранилище (кстати пока вы его захватили, никто другой с ним работать не может, в смысле изменять). При помещении можно оставить метку и комментарий.
У каждого разработчика должен быть свой пользователь, под именем которого и помещаются изменения. Затем историю этих изменений можно свободно смотреть в том же хранилище, кто где и когда менял (если ещё все снабжается комментариями, то ещё и что конкретно менял). Можно захватывать объект не целиком, а например только одну форму документа.
По каждому разу, когда вы помещаете что-то туда, содержится запись. С этой записью кстати можно и сделать стандартное сравнение и объединение. Можно смотреть историю только одного объекта к примеру. + если ещё и в коде оставлять комментарии, то будет ещё удобнее.
П.С. ИМХО самая удобная вещь в плане сохранения изменений, только работать с ней нужно аккуратней.
Работает всё просто - есть ваша конфигурация, есть хранилище. Подключаясь к хранилищу вы замещаете свою конфигурацию той из хранилища.
Далее при изменениях "захватываете" объект из хранилища, и работаете с ним. Как только закончили - помещаете его обратно в хранилище (кстати пока вы его захватили, никто другой с ним работать не может, в смысле изменять). При помещении можно оставить метку и комментарий.
У каждого разработчика должен быть свой пользователь, под именем которого и помещаются изменения. Затем историю этих изменений можно свободно смотреть в том же хранилище, кто где и когда менял (если ещё все снабжается комментариями, то ещё и что конкретно менял). Можно захватывать объект не целиком, а например только одну форму документа.
По каждому разу, когда вы помещаете что-то туда, содержится запись. С этой записью кстати можно и сделать стандартное сравнение и объединение. Можно смотреть историю только одного объекта к примеру. + если ещё и в коде оставлять комментарии, то будет ещё удобнее.
П.С. ИМХО самая удобная вещь в плане сохранения изменений, только работать с ней нужно аккуратней.
(1) echo77,
в наличии полтора десятка ИБ (УСО, УПП, Бух, ЗУП, Управление Автотранспортом). Учет изменений ведем в servicedesk. Для этого создана категория заявок с типом "Изменение".
Перед началом обновления 1С формируем в сервисдеске отчет по изменениям в виде таблицы. Отчет содержит краткое описание изменения, ссылку на подробное описание изменения, исполнителя. Формируется за любой удобный период в разрезе подразделений предприятия(информационных баз). В отчет по желанию можно добавить такие поля как "Инициатор", "Затраченное время", "Время выполнения изменения" и т.п.
Если есть интерес, могу поделиться опытом внедрения такого решения.
Простейший вид отчета:
в наличии полтора десятка ИБ (УСО, УПП, Бух, ЗУП, Управление Автотранспортом). Учет изменений ведем в servicedesk. Для этого создана категория заявок с типом "Изменение".
Перед началом обновления 1С формируем в сервисдеске отчет по изменениям в виде таблицы. Отчет содержит краткое описание изменения, ссылку на подробное описание изменения, исполнителя. Формируется за любой удобный период в разрезе подразделений предприятия(информационных баз). В отчет по желанию можно добавить такие поля как "Инициатор", "Затраченное время", "Время выполнения изменения" и т.п.
Если есть интерес, могу поделиться опытом внедрения такого решения.
Простейший вид отчета:
Прикрепленные файлы:
+1
Практически ничем не пользуюсь в этом направлении.
Платформа "1С:Предприятие 8" неплохо анализирует изменения в процессе сравнения конфигураций.
Не идеально, конечно, но в целом терпимо.
Но протоколировать подробно внесенные изменения - это, на мой взгляд, все-таки есть хорошо и правильно.
Удачи Вам!
Практически ничем не пользуюсь в этом направлении.
Платформа "1С:Предприятие 8" неплохо анализирует изменения в процессе сравнения конфигураций.
Не идеально, конечно, но в целом терпимо.
Но протоколировать подробно внесенные изменения - это, на мой взгляд, все-таки есть хорошо и правильно.
Удачи Вам!
(6) Выложите пожалуйста свою самописную конфигурацию, интересно посмотреть как сделано и на чем сделан акцент.
Согласен, что когда сам вносишь изменения в конфигурацию и кроме тебя туда больше никто не лезет - то обновлять "по памяти" не тяжело. В случае, когда изменения вносят разные программисты, а накатывает обновления типовых администратор базы данных - тут тяжело по памяти что-то вносить.
Суть, конфигурации, которую я хочу разработать - это создать систему, которая позволит ответить на вопрос:
Что? и куда? нужно дописать после обновления типовой конфигурации.
Согласен, что когда сам вносишь изменения в конфигурацию и кроме тебя туда больше никто не лезет - то обновлять "по памяти" не тяжело. В случае, когда изменения вносят разные программисты, а накатывает обновления типовых администратор базы данных - тут тяжело по памяти что-то вносить.
Суть, конфигурации, которую я хочу разработать - это создать систему, которая позволит ответить на вопрос:
Что? и куда? нужно дописать после обновления типовой конфигурации.
Я обычно пользуюсь комментами в самой конфигурации, описанные подробнейшим образом, и еще как то видел как люди создают общий модуль со всеми преписками по изменению конфигурации. А вообще в конфигурациях 1с совместимо например конфигурация Агрософта Бухгалтерия сельскохозяйственного предприятия, она написана на основе БП, они все свои изменения подписывают как //Agrosoft. Всё таки стоит добавить вариант ответа "Не пользуюсь ничем" я выбираю его!
(8) imbaZeratul, не, ну комментарии к своей писанине в модулях - это уж основы основ.
Про это я даже не упоминаю...
Всегда пишу свои ФИО в начале изменений и "//конец" в конце.
Так и найти свой код можно быстро, если что...
Изменения формах описываю кратко в модулях этих форм.
Изменения предопределенных в модулях объектов.
И т.п.
Автор темы имел ввиду, видимо, именно подробное описание изменений...
Про это я даже не упоминаю...
Всегда пишу свои ФИО в начале изменений и "//конец" в конце.
Так и найти свой код можно быстро, если что...
Изменения формах описываю кратко в модулях этих форм.
Изменения предопределенных в модулях объектов.
И т.п.
Автор темы имел ввиду, видимо, именно подробное описание изменений...
(9) Martinian, а куда еще подробнее?)))
Если конечно какие то глобальные изменения в конфигурации которые спустя определенное время можно забыть....типа смотришь в изменения и думаешь а зачем это было сделано))) для таких случае тоже подробное описание пишу, когда это было сделано и в связи с чем.
Если конечно какие то глобальные изменения в конфигурации которые спустя определенное время можно забыть....типа смотришь в изменения и думаешь а зачем это было сделано))) для таких случае тоже подробное описание пишу, когда это было сделано и в связи с чем.
Кстати, для любителей изменять формы типовых доков и справочников - рисую все изменения программно. Также назначаю обработчики если надо. Т.е. всё в коде, сама форма остается неизменяемой. очень удобно, но затратно по времени (при создании).
(11) ZergKRSK,
Написать пару своих процедур в общем модуле, которые добавляют колонки, поля, надписи итд и все затраты времени будут уходить только на копирование вызовов этих процедур с различными параметрами. Правда я так и не придумал как упростить установку привязок, по объёмам получается всё одно.
очень удобно, но затратно по времени
Написать пару своих процедур в общем модуле, которые добавляют колонки, поля, надписи итд и все затраты времени будут уходить только на копирование вызовов этих процедур с различными параметрами. Правда я так и не придумал как упростить установку привязок, по объёмам получается всё одно.
рисую все изменения программно. Также назначаю обработчики если надо. Т.е. всё в коде, сама форма остается неизменяемой. очень удобно, но затратно по времени (при создании).
Неплохо...
Можно попробовать попрактиковать...
Ибо получается, что один раз "паришься" при внесении изменений, и не паришься много-много раз при обновлениях...
ставлю инициалы в комментариях и дату изменения, если есть время, пишу зачем делаю.
Прежде чем делать что-то с новой, не типовой конфигурацией, банально сравниваю со стандартной версией релиза, выписываю изменения: объект, функция, процедура, форма. Записываю сначала банально в тетрадь, потому что мне так удобнее ;). Потом что-то переношу в Excel, что-то так и остается в тетради.
Прежде чем делать что-то с новой, не типовой конфигурацией, банально сравниваю со стандартной версией релиза, выписываю изменения: объект, функция, процедура, форма. Записываю сначала банально в тетрадь, потому что мне так удобнее ;). Потом что-то переношу в Excel, что-то так и остается в тетради.
Все изменения комментирую в коде 1С.
ставлю дату, мое фио, и в двух словах что изменено.
больше нигде изменения не веду.
Всеравно когда идет обновление релиза - все мои "изменения" просматриваю.
Пробовал отдельно вести - всеравно ниразу не потребовались записи изменений.
ставлю дату, мое фио, и в двух словах что изменено.
больше нигде изменения не веду.
Всеравно когда идет обновление релиза - все мои "изменения" просматриваю.
Пробовал отдельно вести - всеравно ниразу не потребовались записи изменений.
Средства предоставленные 1с более чем достаточно. отчет сравнения с конфой поставщика все покажет.
Поправки в коде отмечаю //МоиМетки
после обновления распечатываю краткий отчет сравнения с конфой поставщика с перечнем спр. док. модули. отчеты...только тип и место , модуль форма макет(ну обычно раз на 5-9 релизов, т.к. добавляются новые доки).
Для быстрой проверки затронутых документов. все.
Последующее обновление обычно не затрагивает более 5 % модификаций.
Поправки в коде отмечаю //МоиМетки
после обновления распечатываю краткий отчет сравнения с конфой поставщика с перечнем спр. док. модули. отчеты...только тип и место , модуль форма макет(ну обычно раз на 5-9 релизов, т.к. добавляются новые доки).
Для быстрой проверки затронутых документов. все.
Последующее обновление обычно не затрагивает более 5 % модификаций.
Сперва тоже пытался завести что-то подобное, но меня быстро направили на путь истинный.
Изменения - комментирую. Реквизиты заведенные - соответственно именую, чтобы было понятно. Элементы формы стараюсь создавать программно.
В базе хранятся ТРИ конфигурации - рабочая, сохраненная и поставщика. Для того, чтобы понять что изменено в конфигурации - можно в любой момент прогнать сравнение с конфигурацией поставщика.
Изменения - комментирую. Реквизиты заведенные - соответственно именую, чтобы было понятно. Элементы формы стараюсь создавать программно.
В базе хранятся ТРИ конфигурации - рабочая, сохраненная и поставщика. Для того, чтобы понять что изменено в конфигурации - можно в любой момент прогнать сравнение с конфигурацией поставщика.
Отражая мнение (31)(36) и им подобным, хочется заметить:
Я понимаю, что уже позно что-либо изменить в параметрах опроса ....
НО ОПРОС ПО ВОЗМОЖНОСТИ ДОЛЖЕН ПОЛНЫМ, то есть он исчерпывающим образом
должен удовлетворять все возможные варианты ответов.
---
нет варианта ответов для тех разгильдяев, которые
никак не ведут учет изменений внесенных в типовую КОНФИГУРАЦИЮ.
Я понимаю, что уже позно что-либо изменить в параметрах опроса ....
НО ОПРОС ПО ВОЗМОЖНОСТИ ДОЛЖЕН ПОЛНЫМ, то есть он исчерпывающим образом
должен удовлетворять все возможные варианты ответов.
---
нет варианта ответов для тех разгильдяев, которые
никак не ведут учет изменений внесенных в типовую КОНФИГУРАЦИЮ.
Согласен с автором, что нужно вести изменение в конфе, это очень поможет если не тебе то следующему сотруднику(так как работу можно и с менить), а вот программист после тебя не сразу войдет в курс дела, у меня сложилась такая ситуация. пришел на новое место работы там естественно 1с была переписана и не обновлялась уже 8 месяцев и на бумажном листке есть перечень изменений штук 5 наверное, при условии что я еще потом нашел штук 15
По моему прежде чем создавать что-то надо понять сколько трудозатрат=времени будет требоваться на подержание подобной базы знаний/обработок.
На практике в какой-то момент времени вы поймете что вы забыли что-то зафиксировать в базе и времени на поддержание данной базы в актуальном состоянии тратится больше чем собственно на разработку.
Для обеспечения качественной документации изменений хватает совокупности предложенных в данной теме средств:
1.Примите стандарт разработки в котором бы описывались правила написания комментариев к коду, правила установки префиксов к новым объектам, реквизитам и т.д.
2.Заставьте всех разработчиков в том числе и внешних придерживаться вашего стандарта.
3.Обеспечите приемку доработок не только на уровне работает/не работает новый функционал но и на соответствие его оговоренным стандартом (все изменения обязаны содержать комментарии.
4. Если у вас еще не установлена какая-либо система help desk или Service desk установите ее и при внесении изменений в конфигурацию обяжите в комментариях делать ссылки на задачи в данной системе чтобы было понятно зачем и кто заказчик.
При правильной организации процесса даже при крупных разработках этих мер достаточно.
Что касается обновлений, то вероятность ошибки останется т. к. при новом обновлении может быть полностью переписан текст того или иного модуля и перенос изменений может быть приравнен к разработке заново, если вы используете свои роли, то в обновлении могут появится дополнительные объекты которые вы использовать не собираетесь, а в используемых вами документах на них появились ссылки и возникают ошибки прав доступа.
На практике в какой-то момент времени вы поймете что вы забыли что-то зафиксировать в базе и времени на поддержание данной базы в актуальном состоянии тратится больше чем собственно на разработку.
Для обеспечения качественной документации изменений хватает совокупности предложенных в данной теме средств:
1.Примите стандарт разработки в котором бы описывались правила написания комментариев к коду, правила установки префиксов к новым объектам, реквизитам и т.д.
2.Заставьте всех разработчиков в том числе и внешних придерживаться вашего стандарта.
3.Обеспечите приемку доработок не только на уровне работает/не работает новый функционал но и на соответствие его оговоренным стандартом (все изменения обязаны содержать комментарии.
4. Если у вас еще не установлена какая-либо система help desk или Service desk установите ее и при внесении изменений в конфигурацию обяжите в комментариях делать ссылки на задачи в данной системе чтобы было понятно зачем и кто заказчик.
При правильной организации процесса даже при крупных разработках этих мер достаточно.
Что касается обновлений, то вероятность ошибки останется т. к. при новом обновлении может быть полностью переписан текст того или иного модуля и перенос изменений может быть приравнен к разработке заново, если вы используете свои роли, то в обновлении могут появится дополнительные объекты которые вы использовать не собираетесь, а в используемых вами документах на них появились ссылки и возникают ошибки прав доступа.
(38) navire,
Золотые слова.
Если есть отдел, который занимается постановкой задачи, ее методологией, есть несколько программистов, серьезные изменения в типовых модулях - конечно такой учет нужен. Кто, зачем, по чьей заявке сделал. Вполне может быть, что в связи с решениями методологов какие-то вещи запрещено делать, хотя вполне допустимо по ПБУ и законодательству...
А где-то посередине между полным отсутствием документации и полным ее присутствием живет золотая середина.
Мне н.п. хватает:
Но в
(26) echo77,
были высказаны следующие требования:
На это требование сравнение с конфигурацией поставщика отвечает на 95%.
(35) beldieff,
Можно, еще как... У нас БП 1.6, изломана до неузнаваемости, но мы ее правда и не обновляем типовыми обновлениями.
По моему прежде чем создавать что-то надо понять сколько трудозатрат=времени будет требоваться на подержание подобной базы знаний/обработок.
На практике в какой-то момент времени вы поймете что вы забыли что-то зафиксировать в базе и времени на поддержание данной базы в актуальном состоянии тратится больше чем собственно на разработку.
На практике в какой-то момент времени вы поймете что вы забыли что-то зафиксировать в базе и времени на поддержание данной базы в актуальном состоянии тратится больше чем собственно на разработку.
Золотые слова.
Если есть отдел, который занимается постановкой задачи, ее методологией, есть несколько программистов, серьезные изменения в типовых модулях - конечно такой учет нужен. Кто, зачем, по чьей заявке сделал. Вполне может быть, что в связи с решениями методологов какие-то вещи запрещено делать, хотя вполне допустимо по ПБУ и законодательству...
А где-то посередине между полным отсутствием документации и полным ее присутствием живет золотая середина.
Мне н.п. хватает:
Изменения - комментирую. Реквизиты заведенные - соответственно именую, чтобы было понятно. Элементы формы стараюсь создавать программно.
Но в
(26) echo77,
были высказаны следующие требования:
Мне нужно тупо перечень объектов, в которые необходимо внести изменения после обновления с указанием в каком месте и что вставить.
На это требование сравнение с конфигурацией поставщика отвечает на 95%.
(35) beldieff,
Можно, еще как... У нас БП 1.6, изломана до неузнаваемости, но мы ее правда и не обновляем типовыми обновлениями.
(56) echo77,
ИМХО - примерно так же, как вести в Excel.
Как Я делаю:
Если изменения в конфигурации незначительны - просто на копии базы запускаю поиск по своим меткам и копирую изменения в обновленную конфигурацию.
При значительных изменениях:
Создаю копию базы, прогоняю на ней сравнение с конфигурацией поставщика. Вижу список внесенных изменений.
Создаю базу с типовой новой конфигурацией, прогоняю сравнение со старой конфигурацией поставщика. Вижу, что изменилось в конфигурации. 1С любит периодически перетаскивать команды из одного модуля в другой, это в основном стреляет с внешними обработками.
Сперва прохожу по общим модулям, потом потихоньку по остальным объектам... Сохранил конфигурацию, черкнул на листочке на чем остановился, в следующий раз продолжил...
ИМХО - примерно так же, как вести в Excel.
Как Я делаю:
Если изменения в конфигурации незначительны - просто на копии базы запускаю поиск по своим меткам и копирую изменения в обновленную конфигурацию.
При значительных изменениях:
Создаю копию базы, прогоняю на ней сравнение с конфигурацией поставщика. Вижу список внесенных изменений.
Создаю базу с типовой новой конфигурацией, прогоняю сравнение со старой конфигурацией поставщика. Вижу, что изменилось в конфигурации. 1С любит периодически перетаскивать команды из одного модуля в другой, это в основном стреляет с внешними обработками.
Сперва прохожу по общим модулям, потом потихоньку по остальным объектам... Сохранил конфигурацию, черкнул на листочке на чем остановился, в следующий раз продолжил...
(38) Пункты 1,2 есть, по п. 3, 4 у нас, конечно, дыра - умело раздавать песдов пока не получается.
На счет организационных мер - точно! Издадим распоряжение по отделу, за невыполнение будем карать.
(39) Покажите пример, скриншоты что ли. А тот тут несколько людей рассказывают что каким-то образом ведут изменения, а посмотреть на что ориентироваться не дают. Покажите.
Привязываться к номерам строк - гиблое дело. Вывали случаи когда процедура сильно изменена, кусок кода вроде в документации отражен, а куда его вставлять - хз.
На счет организационных мер - точно! Издадим распоряжение по отделу, за невыполнение будем карать.
(39) Покажите пример, скриншоты что ли. А тот тут несколько людей рассказывают что каким-то образом ведут изменения, а посмотреть на что ориентироваться не дают. Покажите.
Привязываться к номерам строк - гиблое дело. Вывали случаи когда процедура сильно изменена, кусок кода вроде в документации отражен, а куда его вставлять - хз.
Не веду никакой учет. Изменения комментирую в тексте модулей на память, формы дорисовываю програмно. Проблем при обновлении никаких не возникает. Может у меня изменений немного (около 100) или я что то делаю ни так?
1. Если конфа типовая и все далется внешними отчетами и обработками, то в них обязательно добавляю макет "ИсторияИзменений" в котором описываю версию, когда, кем, для кого, для какого релиза и какие действия были выполнены. Если используется типовой код, то комментирую блоками изменения, если свой - просто подробные комментарии. Помогает решить проблемы когда нужно обновить код отчета/обработки до нужного релиза или когда код дописывает другой разработчик.
2. Если конфа сильно нетиповая, то стараюсь изменения на форме вносить программно, иначе, опять же добавляю макеты с историей изменений либо в общие макеты, либо в конкретные объекты с аналогичной структурой описания.
2. Если конфа сильно нетиповая, то стараюсь изменения на форме вносить программно, иначе, опять же добавляю макеты с историей изменений либо в общие макеты, либо в конкретные объекты с аналогичной структурой описания.
и в его справочную информацию вношу все изменения с номерами строк и названием модулей
Это очень порочная практика. Объяснить почему? :-) Мы как стандарт приняли всё-таки документирование изменённых процедур полностью с выделением вставок.
Все изменения внесенные в конфигурацию фиксируем в Microsoft OneNote. По максимуму стараемся использовать типовые вещи. Если же не вписываемся в типовые алгоритмы то используем свои объекты. Для синхронизации наших объектов и типовых , используем внешние обработки и типовые обработчики события с минимальными изменениями.
Никогда не вёл никакой документации к доработанным конфигурациям, так как на фиксацию изменений уходит много времени, а если что-то один раз пропустишь или дорабатывается конфигурация несколькими программистами, то этот документ теряет всякий смысл - можно что-то пропустить. Встроенные средства конфигурации довольно хороши. Однако, были случаи на практике, когда такой файл пригодился бы ...
(58) echo77,
Неверная логика и неправильная голосовалка провоцирует даватьнеправильный мёд неправильные ответы.
Судя по тому, что 37 человек ответили что использую специальную конфигурацию на 1С и не показали что за конфигурация - они используют Хранилище конфигурации
Неверная логика. Специальное хранилище - да, это штатный механизм.
Неверная логика и неправильная голосовалка провоцирует давать
Ни один из вариантов не подошёл, ибо дело это неблагодарное и бесполезное.
Когда клиентов много, местные админы периодически выдают подобные портянки.
Кроме как поржать, с них толку мало.
Короче, Вариант такой: Умею пользоваться средствами платформы.
Когда клиентов много, местные админы периодически выдают подобные портянки.
Кроме как поржать, с них толку мало.
Короче, Вариант такой: Умею пользоваться средствами платформы.
(62) Опишите поподробнее "как" вы умеет пользоваться средствами платформы.
Согласен, когда для толпы клиентов, в конфигурации которых вносишь изменения не только ты - это приводит только к увеличению времени.
Хотя, был у меня случай, когда нужно было перенести доработанный функционал УПП 1.2, в УПП 1.3. Конфигурация поставщика в УПП 1.2 просто отсутствовала. С чем сравнивать?
Согласен, когда для толпы клиентов, в конфигурации которых вносишь изменения не только ты - это приводит только к увеличению времени.
Хотя, был у меня случай, когда нужно было перенести доработанный функционал УПП 1.2, в УПП 1.3. Конфигурация поставщика в УПП 1.2 просто отсутствовала. С чем сравнивать?
Здравствуйте.
Если Вы серьезно задумываетесь о качестве сопровождения Ваших решений и качественном документировании, то тогда имеет смысл разбить задачу на несколько составляющих, которые между собой связаны:
1. Используйте СППР (Система проектирования прикладных решений)от 1С:
2. Разработайте нормальный регламент работы с хранилищем (часть описывали в посте 47)
3. Разработайте регламент комментирования кода (указывая в метках признак своей организации + признак программиста + ссылка на требования)
4. Рассмотрите возможность четкого определения своих внутренних стандартов разработки, о которых отрывочно многие здесь также указывали:
- Стандарт разработки модулей
- Стандарт разработки форм
и т.п.
Почитайте на ИТС "Стандарты и методики разработки":
Если Вы серьезно задумываетесь о качестве сопровождения Ваших решений и качественном документировании, то тогда имеет смысл разбить задачу на несколько составляющих, которые между собой связаны:
1. Используйте СППР (Система проектирования прикладных решений)от 1С:
2. Разработайте нормальный регламент работы с хранилищем (часть описывали в посте 47)
3. Разработайте регламент комментирования кода (указывая в метках признак своей организации + признак программиста + ссылка на требования)
4. Рассмотрите возможность четкого определения своих внутренних стандартов разработки, о которых отрывочно многие здесь также указывали:
- Стандарт разработки модулей
- Стандарт разработки форм
и т.п.
Почитайте на ИТС "Стандарты и методики разработки":
(74) Это все хорошо или даже отлично, но не хватает отчета, который покажет куда и конкретно в каком месте были внесены изменения. Например:
Справочник.Валюты.МодульФормы ПриОткрытии():
Справочник.Номенклатура.МодульОбъекта ПриЗаписи():
Справочник.Валюты.МодульФормы ПриОткрытии():
Процедура ПриОткрытии()
<... типовой код>
// Наша вставка от 2013.06.01
<Какой-то код>
// КонецМоейВставки
<... типовой код>
КонецПроцедуры ПоказатьСправочник.Номенклатура.МодульОбъекта ПриЗаписи():
Процедура ПриЗаписи()
<Какой-то код>
// Наша вставка от 2013.01.01
фывавыаыва
// КонецМоейВставки
КонецПроцедуры
(75) echo77,
Зачем корёжить типовые процедуры, когда можно все это сделать в своей, названной так, что сразу ясно она не типовая?
Процедура ПриОткрытии()
<... типовой код>
// Наша вставка от 2013.06.01
<Какой-то код>
// КонецМоейВставки
<... типовой код>
КонецПроцедуры ПоказатьЗачем корёжить типовые процедуры, когда можно все это сделать в своей, названной так, что сразу ясно она не типовая?
(74) German,
У вас есть возможность вести учет изменений нескольких конфигураций в одной базе?
Или для каждой изменяемой конфигурации свое "хранилище изменений". Насколько я понял, Ei создает доп таблицу в изменяемой конфигурации, то есть т.н единого хранилища изменений всех подшефных конфигураций нет.
Так?
У вас есть возможность вести учет изменений нескольких конфигураций в одной базе?
Или для каждой изменяемой конфигурации свое "хранилище изменений". Насколько я понял, Ei создает доп таблицу в изменяемой конфигурации, то есть т.н единого хранилища изменений всех подшефных конфигураций нет.
Так?
Встроенные средства конфигурации довольно хороши. Никогда не вёл никакой документации к доработанным конфигурациям, так как на фиксацию изменений уходит много времени, а если что-то один раз пропустишь или дорабатывается конфигурация несколькими программистами, то этот документ теряет всякий смысл - можно что-то пропустить. Однако, были случаи на практике, когда такой файл пригодился бы ...
Отслеживать изменения может и сама платформа при сравнении. При изменения в формах и макетах пишу комментарии в модуле со списком изменений - это упрощает жизнь в 8, а в 77 это единственный способ. Полезный совет - писать в комментариях к вставкам имя пользователя-инициатора изменения. Помогает при разборках "раньше всё работало, кто просил менять?!".
Типовое хранилище. Правда с ним бывают траблы - уже пару раз оказалось битым. Для восстановления хранилища использовал файл .cf, который постоянно пишу при изменениях, вот только историю хранилища не восстановить. Еще минус хранилища - медленно работает в локалке, если хранилище на сервере, а подключаешься с локальной машины - это про УПП. Минут 15 висишь минимум, и ресурсы вроде не заняты, а 1С еле-еле работает.
Мож настроили криво. Но уж лучше типовое хранилище, чем иначе. Подключился с любой базы и все боевые изменения автоматом грузятся.
Мож настроили криво. Но уж лучше типовое хранилище, чем иначе. Подключился с любой базы и все боевые изменения автоматом грузятся.
храню в специально структурированном по объектам файле excel, пару раз не заносил изменения в файл, приходилось пользоваться данными хранилища. Если начинаю работать с новой базой первое что делаю сравнение со стандартной конфигурацией и записывание списка изменний. При обновление помогает анализ дважды измененых объектов.
Перед обновлением делаю сравнение с конфигурацией поставщика, сохраняю в файл.
Обновляю.
Пробегаюсь по измененным объектам, поскольку мои изменения всегда комментированы - их хорошо видно.
В крайнем случае делаю объединение модулей с разным приоритетом - по ситуации, чаще всего - оставляю "взять из новой конфигурации" или снимаю галку вообще.
Применяю обновление.
Делаю сравнение с конфигурацией поставщика, сохраняю в файл.
Сравниваю два файла (например, В ТоталКомандере), до и после. Если есть различия - правлю новую конфу, снова сравниваю с конфой поставщика и так далее, пока различий не останется.
Как правило, достаточно одной итерации. БП, изменено несколько десятков объектов - отчеты, обработки, справочники и документы.
Плюс метода в том, что акцент ставится именно на отличие от конфигурации поставщика, вне зависимости от массивности обновления. Никакого учета внесенных изменений не веду.
Обновляю.
Пробегаюсь по измененным объектам, поскольку мои изменения всегда комментированы - их хорошо видно.
В крайнем случае делаю объединение модулей с разным приоритетом - по ситуации, чаще всего - оставляю "взять из новой конфигурации" или снимаю галку вообще.
Применяю обновление.
Делаю сравнение с конфигурацией поставщика, сохраняю в файл.
Сравниваю два файла (например, В ТоталКомандере), до и после. Если есть различия - правлю новую конфу, снова сравниваю с конфой поставщика и так далее, пока различий не останется.
Как правило, достаточно одной итерации. БП, изменено несколько десятков объектов - отчеты, обработки, справочники и документы.
Плюс метода в том, что акцент ставится именно на отличие от конфигурации поставщика, вне зависимости от массивности обновления. Никакого учета внесенных изменений не веду.
В тексте проставляю комментарии заданного шаблона. Так как конфигурацию правят обычно несколько людей, то после этого шаблона указываются инициалы внесшего изменения. В начале наименования добавляемых реквизитов указываю сокращенное наименование организации-заказчика, в комментарии указываю, кто добавил этот реквизит. Изменения общих макетов, интерфейсов и т.п. описываю в модуле приложения.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот