Управление релизами 1С

15.09.20

База данных - Обновление 1С

При непрерывном развитии сложных информационных систем на 1С возникает потребность управлять процессом обновления релизов их конфигураций. Необходим инструмент, предоставляющий полную информацию о вносимых в конфигурацию изменениях и полном жизненном цикле каждого из них, начиная от обращения пользователя до реализации и документирования функциональности. О принципах работы такого инструмента и полученных в ходе его внедрения преимуществах на конференции Infostart Event 2019 Inception рассказала директор департамента информационных систем «Иркутской нефтяной компании» Екатерина Шушина.
 

Меня зовут Екатерина, я возглавляю департамент информационных систем в Иркутской нефтяной компании. Сегодня я расскажу вам, как мы навели порядок в процессе выпуска обновлений в наших информационных базах.

 

 

Мой доклад будет построен следующим образом.

  • Сначала я расскажу о компании, в которой я работаю.
  • Затем - о нашей собственной разработке – о системе, которую мы назвали Service Desk.
  • Потом мы с вами поговорим непосредственно о формировании релиза.
  • После этого будет несколько слов о результатах внедрения.
  • И в конце расскажу о перспективах развития нашей системы.

 

О компании

 

 

Иркутская нефтяная компания – одна из крупнейших независимых нефтегазодобывающих компаний в России.

  • Она насчитывает более 8000 сотрудников, и по прогнозам через пять лет нас будет уже не менее 15 тысяч.
  • Деятельность компании представлена в Восточной Сибири. Это – Иркутская область, республика Саха, Якутия, а также Красноярский край.
  • Количество информационных баз, используемых в режиме промышленной эксплуатации, исчисляется десятками. В них работает более 1000 пользователей, и это число постоянно растет. Также есть крупные базы на платформе 1С, которые включают в себя несколько функциональных блоков.

Задача моего департамента – обеспечить сопровождение и развитие существующих систем, а также внедрить новые информационные системы.

В департаменте информационных систем есть три отдела:

  • отдел сопровождения, который является первой линией поддержки пользователей;
  • отдел внедрения информационных систем – в нем работают консультанты;
  • и отдел разработки, в котором трудятся сами программисты, которых в народе называют «кодерами».

 

Система Service Desk

 

 

Ни для кого не секрет, что базы периодически нужно обновлять. Какие-то базы обновляются чаще, какие-то – реже, но в целом такое событие, как выпуск релиза, для нашей компании весьма частое явление. Раньше разработчики тратили кучу времени на сбор релизов, установку, потом на сбор исправительных релизов, так как «что-то лишнее зацепили» или наоборот «не обновили какой-то нужный объект».

Теперь механизм управления релизами реализован в нашей системе «Service Desk». Но обо всём по порядку!

 

 

В далёком 2014-м году проблем с релизами у нас не было, компания была намного меньше и баз было не более 5.

Но в какой-то момент мы осознали потребность упорядочить процесс работы с обращениями пользователей в рамках сопровождения этих баз.

И тогда у нас возникла идея быстренько накидать функционал, который позволил бы пользователям регистрировать свои обращения, отслеживать их статус, а нам в порядке очередности обрабатывать эти обращения.

В пустой конфигурации на платформе 1С мы быстренько накидали требуемый функционал, который состоял из одного документа «Обращение» и назвали систему «Service Desk».

Система быстро стала популярной в компании, и с тех пор её функционал нами расширялся и совершенствовался.

На данный момент в этой системе реализован механизм управления релизов.

Если не вдаваться глубоко в детали, механизм создания релиза следующий:

  • Сначала в систему «Service Desk» поступает обращение от пользователя по вопросам работы в той или иной системе.
  • Если вопрос на 1-ой линии не решился и выявлена необходимость внесения изменений в алгоритмы работы системы, то вопрос передаётся на вторую линию для формирования постановки задачи на разработку и, собственно, самой разработки. На этом этапе создаётся документ «Доработка».
  • В конечном итоге доработки объединяются в релиз, который устанавливается на рабочую базу.

 

Формирование релиза

 

 

Расскажу о процессе формирования релиза более подробно.

Документ «Обращение» – очень простой, в нем нет ничего сложного:

  • его основной реквизит – это «Статус»;
  • и главное поле «Описание обращения» – здесь простым человеческим языком написано то, что хочет пользователь.

 

 

Прежде чем перейти к следующему документу «Доработка» я немного расскажу о структуре баз и хранилищ конфигураций в нашей компании.

У каждой информационной системы есть два хранилища. Мы их называем «Тестовое» и «Релизное».

  • К тестовому хранилищу подключены тестовые базы консультантов и разработчиков. Разработчики вносят изменения в конфигурации в свои базы, а консультанты тестируют работу программистов.
  • Затем в процессе подготовки обновления разработчики помещают изменения из своих тестовых баз в свои так называемые релизные базы. Каждый разработчик имеют свою базу для каждой системы, и все эти базы подключены к релизному хранилищу.
  • В итоге в релизном хранилище оказываются доработки всех разработчиков для установки релиза.
  • Сама рабочая база также подключена к релизному хранилищу и обновляется непосредственно из релизного хранилища, в котором происходит окончательный сбор релиза.

Также хочу заметить, что наша система Service Desk содержит информацию о конфигурациях систем. Она берет эту информацию непосредственно из тестовых хранилищ, так как в тестовых хранилищах есть абсолютно все изменения, которые разработчики вносят в систему – даже те, которые еще не планируются к установке на рабочую базу.

 

 

Перейдем к документу «Доработка». Этот документ намного более функционален, чем документ «Обращение», и создается на его основании.

  • Изначально документ «Доработка» создается в статусе «Зарегистрировано», и с ним начинают работать консультанты по внедрению информационной системы. В результате на вкладке «Описание» формируется описание задачи непосредственно на техническом языке для разработчика.
  • После того как консультант поставил задачу разработчику, он отправляет документ «Доработка» в статус «В разработке», и тогда уже исполнителем по доработке становится непосредственно программист. Разработчик вносит изменения в свою тестовую базу и помещает их в тестовое хранилище. Как я говорила ранее, структура тестового хранилища выгружается в систему Service Desk.
  • В процессе своей работы программист на вкладке «Измененные объекты» галочками отмечает те объекты конфигурации, которые он изменил в процессе доработки. Это некий организационный момент – разработчик должен вручную поставить эти галочки. Кроме галочек он может указать комментарий – например, в какую процедуру или функцию вносились изменения, а также любую другую информацию.
  • А также есть правило – когда разработчик вносит в конфигурацию изменения кода, он обязательно комментирует, и комментарий содержит номер доработки, в рамках которого происходит изменение, и также автора, который внес эти изменения.
  • И при помещении в тестовое хранилище измененных объектов также в комментарии обязательно указывается номер доработки. Вся эта информация значительно облегчает сбор релизов в дальнейшем. Сейчас я скажу, как.
  • После того, как разработчик внес изменения в конфигурацию, он передает доработку в тестирование консультанту.
  • Вообще с документом «Доработка» по очереди работают консультант и программист, гоняя его по разным статусам – «В уточнении», «В тестировании», снова «В разработке». Чаще всего документ принимает статус «В разработке» несколько раз, и каждый раз при изменении объектов разработчик дозаполняет вкладку «Измененные объекты» новыми объектами, которые он меняет. Таким образом, доработка хранит в себе всю информацию об измененных объектах конфигурации в ходе ее выполнения.

 

 

Перекидывание доработки между статусами происходит до тех пор, пока консультант не примет изменения и у него не останется замечаний к разработчику. После того, как это происходит, консультант должен заполнить вкладку «Информация о релизе».

Вкладка «Информация о релизе» содержит три раздела:

  • «Описание релиза» – здесь содержится информация для пользователей на простом человеческом пользовательском языке о том, что изменилось в системе
  • «Список адресов» – это адреса пользователей, которые получат информацию об обновлении.
  • «Изменяемые инструкции» – здесь консультант вносит изменения в файлы инструкций, которые необходимо обновить после того, как изменения будут установлены на рабочую базу.

После того, как консультант заполнит всю необходимую информацию о доработке, он переводит доработку в статус «К помещению в рабочую базу».

Как только доработка попала в этот статус, исполнителем по ней снова становится разработчик. Но он не работает дальше с документом «Доработка» до тех пор, пока эта доработка не попадет в документ «Релиз».

 

 

Таким образом, мы с вами подошли к главному документу моего сегодняшнего доклада – документу «Релиз».

В зависимости от типа релиза он появляется разными способами:

  • плановый релиз создается автоматически регламентным заданием по расписанию;
  • другие виды релизов формируются консультантами.

Что нужно заполнить в релизе? Минимальные данные – это плановая дата установки релиза и набор тех доработок, которые должны войти в этот релиз (из числа доработок в статусе «К помещению в рабочую базу»). Все остальные вкладки, которые есть в этом документе, заполняются автоматически на основании тех данных, которые имеются во включенных в этот релиз «Доработок». Например, вкладка «Информация о релизе» формируется из описаний релиза в «Доработках» – это информация, которая будет в рассылке при установке релиза.

 

 

После того как документ «Релиз» переходит в статус «Согласован», разработчики начинают работать каждый со своей доработкой – переносить изменения по ним в релизное хранилище.

Используя вкладку «Измененные объекты», разработчики должны перенести в релизные базы те изменения, которые должны войти в релиз. Каждый разработчик переносит изменения только по выполненным им доработкам. Так как все релизные базы подключены к одному релизному хранилищу, изменения в общие объекты программистам приходится вносить по очереди.

На вкладке «Измененные объекты» есть вся информация об измененных объектах всех доработок, которые вошли в документ «Релиз». Эта вкладка имеет два представления.

Первое представление, которое вы видите на экране (со снятой галочкой «По доработкам») – это представление, которое показывает изменения в разрезе структуры конфигурации:

  • Здесь есть столбец «К установке», где содержатся номера доработок, которые вошли в этот релиз.
  • Также здесь есть столбец «Не устанавливать». Здесь фигурируют те доработки, которые не должны попасть в релиз, но по которым на данный момент в системе есть изменения конфигурации именно в части этого объекта. Они подсвечены розовым цветом, и разработчик, когда помещает изменения в свою релизную базу, должен обратить внимание, что эти объекты конфигурации нельзя полностью заменить, их нужно проанализировать, вычленить из них те изменения, которые сделаны в рамках этой доработки, и внести только их. Те объекты, которые не подсвечены розовым, разработчик может полностью заменять.

Это представление удобно использовать для тех релизов, в которых принимал участие только один разработчик. Оно удобно в этом случае.

 

 

Второй вид (при установленной галке «По доработкам») удобно использовать, если в релизе принимали участие несколько разработчиков – когда идет обновление баз, где много функциональных блоков.

Это представление помогает разработчику перенести изменения только по своим доработкам, абстрагируясь от изменений, сделанных его коллегами – т.е. каждый разработчик вносит изменения только по своим доработкам.

Т.к. все базы прикреплены к одному релизному хранилищу, то разработчики вносят эти изменения последовательно:

  • После того, как разработчик внес изменения в релизную базу, он переводит доработку в статус «В релизном хранилище».
  • Только после того, как все доработки перешли в этот статус, документ «Релиз» переходит в статус «Готов к установке».
  • Затем строго по расписанию, которое было указано в документе, происходит обновление из релизного хранилища рабочей базы. Оно происходит в одной транзакции – в один момент документ «Релиз» переходит в статус «Установлен», и все доработки, которые в него включены, а также обращения, на основании которых созданы эти доработки, переходят в статус «Выполнено». Происходит автоматическое обновление инструкций для пользователей. И автоматически происходит рассылка с информацией об обновлении.

 

Эффекты от внедрения

 

 

Что мы получили благодаря реализованному механизму?

Возможно, для небольшой компании, где два разработчика и пять информационных баз, это все неактуально – у них никаких проблем с учетом обновлений нет. Но в рамках «Иркутской нефтяной компании» нам этот механизм очень сильно помог.

  • Раньше у нас каждый раз после выпуска планового релиза, особенно на крупных базах, просто валом несколько дней подряд шли срочные релизы, потому что обязательно где-то кто-то что-то зацепил, либо наоборот, не обновил какой-то нужный объект. И в итоге на рабочие базы попадала либо непротестированная функциональность, либо туда не попадало что-то нужное. Был большой негатив со стороны пользователей, и выпуск исправительных релизов – даже в обеденное время – только усиливал этот негатив. А благодаря этому механизму мы практически свели к нулю установку исправительных релизов.
  • Также мы получили удобный инструмент сборки релизов, который подскажет разработчику – какие объекты ему нужно обновлять полностью, а какие с осторожностью, так как они также были изменены его коллегами.
  • Несмотря на то, что разработчикам и консультантам приходится вносить много данных в документ «Доработка», количество трудозатрат на подготовку релизов у нас снизилось. Это произошло за счет того, что значительно снизилось именно количество этих исправительных срочных релизов, что дало огромный выигрыш по трудозатратам сотрудников на подготовку обновлений в целом – сама длительность сборки релиза не сильно изменилась.
  • Руководители отдела разработки и внедрения получили инструмент для контроля дисциплины своих сотрудников.
  • В частности, начальник отдела внедрения может контролировать, как консультанты обновляют инструкции, как они качественно оповещают об изменениях пользователей – всех ли пользователей они оповещают об этом.
  • Руководитель отдела разработки имеет механизм, который дает ему возможность в случае возникновения каких-то ошибок разобраться, почему это произошло, кто допустил ошибку. Он может контролировать исполнительскую дисциплину в плане заполнения данных в документе «Доработка».
  • Теперь у нас нет проблем с актуальностью инструкций. Инструкции актуальны всегда, они обновляются вместе с релизом – поэтому проблем о том, кто и когда обновит инструкцию – чуть раньше или позже – у нас никогда не возникает.
  • Также мы ушли от ручной установки релиза. Раньше у нас разработчики не спали, ночью обновляли вручную базы, утром консультанты первым делом должны были как можно быстрее отправить уведомления пользователям об установке релиза  и обновить все инструкции. Если вдруг кто-то отвлекся, забыл, проспал – недовольство в наш адрес было обеспечено. Сейчас мы готовимся к обновлениям заблаговременно, в рабочее время. Ночью все спокойно спят. Этот процесс упорядочен.

 

Перспективы развития

 

 

В описанной мною функциональности меня устраивает практически все, за исключением одного – разработчикам приходится ручками вручную отмечать измененные объекты, которые он помещает в хранилище конфигурации в документах «Доработка» системы Service Desk. Это своего рода «двойной ввод». Но пока мы не решили, что с этим можно сделать. Мы бы хотели, чтобы:

  • при помещении разработчиком изменений в хранилище – информация об определенных объектах, которые он туда помещает, приходила бы в систему Service Desk;
  • так как разработчик при помещении в хранилище указывает в комментарии номер доработки, хотелось бы, чтобы в этой доработке все эти объекты автоматически отмечались на вкладке «Измененные объекты»;
  • при этом если есть добавленные объекты, сначала обновлялась информация о конфигурации тестового хранилища в Service Desk, а потом также отмечались все измененные или добавленные объекты.

Тогда бы мы ушли от риска того, что набор действительно измененных объектов конфигурацию и тот набор объектов, который отмечен в «Доработке» разработчиком, не совпадают. Такое, к сожалению, бывает. Человеческий фактор пока остается.

Главное – хотелось бы, чтобы эта процедура инициировалась на стороне конфигуратора при помещении объекта в хранилище, а не из системы Service Desk. Повторюсь, что мы пока решения этому не нашли.

Если вдруг у кого-то будут какие-то идеи на этот счет – поделитесь, пожалуйста, я буду очень признательна!

 

 

У меня все. Спасибо за внимание!

 

Вопросы

 

  • При обновлении релиза иногда требуется не только внесение изменений в конфигурацию, но и обновление данных – добавили реквизит, поменяли тип, нужно перенести данных. Это должно произойти в момент выкатки новой конфигурации. Включены ли в вашу процедуру каким-либо образом еще и изменения данных помимо изменений инструкций и кода?
  • В самом механизме этого нет. У нас есть механизм, который позволяет не устанавливать обращение в статус «Выполнено» и информировать консультанта с помощью определенных настроек о том, что конфигурация обновилась, и в нее нужно внести какие-то данные. Т.е. эти настройки консультант сам для себя заранее формирует, чтобы система ему потом об этом напомнила.
  • Получается, что консультант это сделает уже с утра, когда пользователи могут начать работать с неверными данными?
  • Такое бывает нечасто, и консультанты про это сами знают. Если что-то нужно сделать действительно быстро – бывает, что консультант может это делать ночью или рано утром, когда еще пользователей нет.
  • Какое количество у вас разработчиков и как часто вы выпускаете релизы?
  • У нас шесть разработчиков, пять из них – разработчики 1С. По поводу количества релизов – мы стараемся сократить количество релизов, мы их пытаемся упорядочить. И раз в две недели выпускаем плановый релиз. Это получается достаточно крупный, тяжелый релиз. Но у нас бывают проектные релизы, которые мы устанавливаем тоже по регламентам – по понедельникам, например. И, к сожалению, бывают срочные релизы – когда нужно исправить какую-то ошибку в системе, либо пользователю эта функциональность нужна срочно.
  • Экстренные релизы вы тоже заносите в систему и отражаете (если сломалось, и нужно обновить прямо сейчас)?
  • Да, срочные релизы мы также проводим через эту систему. Обычно мы стараемся, конечно, дотянуть время, например, до обеда – пока меньше пользователей будет работать. И также планируем установку релиза – готовим его заранее за пару часов, и он устанавливается в обед автоматически.
  • Каким образом вы тестируете релиз? Как вы проверяете работоспособность при сборке?
  • Тестирование релизов происходит консультантами, они свою базу обновляют из тестового хранилища. И, соответственно, тестируют в ней функциональность вручную. Автоматического тестирования у нас пока нет.
  • А каким образом осуществляется приемка функциональности? Есть задача, ее выполняют разработчики, дальше эта функциональность принимается. В какой момент это происходит?
  • Консультант принимает функциональность от разработчика. Если у него нет никаких замечаний, его полностью устраивает реализация, он переводит доработку в статус «К помещению в рабочую базу». Тем самым он подтверждает готовность функциональности для промышленной базы.
  • Это происходит уже в релизном хранилище?
  • Консультант делает это в системе Service Desk, и только после этого доработка попадает в документ «Релиз», и только потом ее переносят уже сами разработчики – тот, кто ее разрабатывал – в релизное хранилище.
  • Как происходит работа с документацией (с инструкциями)? Как они доставляются до конечных пользователей? И ведется ли версионирование?
  • Да, версионирование инструкций ведется. Сами инструкции также находятся в системе Service Desk – все находится в одном месте. И когда консультант во вкладке «Подготовка к релизу» указывает текущий раздел инструкции и прикрепляет к нему вордовский файл, содержанием которого должна замениться инструкция при обновлении. И таким образом инструкция в момент установки релиза становится свежей.
  • А как она к пользователю попадает?
  • Пользователь заходит в систему, и там есть все инструкции. Мы инструкции не рассылаем пользователям. Пользователям мы просто рассылаем краткое уведомление о том, что изменилось в системе и что работает теперь по-другому. А детальные инструкции находятся в Service Desk – все пользователи знают, где они находятся, и ими пользуются.
  • Вы думали как-то поделиться с сообществом эти практиками? Или это останется вашим внутренним достижением?
  • Мы думали об этом – нужно ли это кому-то, кроме нас, у всех своя специфика. Возможно.
  • Насколько часто вы выпускаете релизы?
  • Конечно, одна неделя на другую не похожа, но в среднем 5-6 релизов в неделю вполне может быть.
  • Тогда рассматривали ли вы вопрос внедрения практик DevOps?
  • Я знаю, что сейчас есть различные механизмы, системы, которыми можно пользоваться, но сейчас мы пользуемся этим механизмом – он разработан под нас, нам с ним удобно, и пока что мы от него отказываться не хотим. Возможно, в дальнейшем – жизнь не стоит на месте, и мы перейдем на что-то более современное.
  • Просто по поводу того, что вы сказали – ручной ввод информации по измененным объектам конфигурации – дело в том, что когда разработчик помещает в хранилище свои изменения – по этим изменениям можно сформировать отчет. А отчет в текстовом формате можно сохранить и распарсить и те же изменения получить в вашу систему.
  • Да, отчет мы тоже формируем. Но у нас именно в чем удобство – в том, что мы можем посмотреть, для чего это изменение было сделано – у нас оно привязано непосредственно к доработке и к обращению пользователя. Мы можем отследить, кто это запросил.
  • Но вы говорите, что когда разработчик помещает свои изменения в хранилище, он помечает их номером задачи. Соответственно, когда вы формируете отчет по измененным объектам конфигурации в хранилище, там же можно их сформировать по номеру задачи. Таким образом автоматизировать ввод изменений в вашу систему.
  • Просто в конфигураторе нет возможности запустить событие при помещении в хранилище.
  • Но вы же можете эти изменения регламентными заданиями выгружать – если вы будете рассматривать для себя практику DevOps, там это можно организовать.
  • Спасибо большое за совет.
  • Если я правильно понял, у вас у каждого разработчика есть своя тестовая база, в которой он ведет разработку, а потом изменения закидывает в тестовое хранилище. А у вас бывают ситуации, когда двое разработчиков работают над одним и тем же объектом и первый разработчик закидывает свои изменения сегодня, а второй – завтра, и когда второй разработчик закидывает изменения, он стирает изменения первого?
  • Если первый вносил изменения, он захватил объект, и его изменять никто не может в тестовом хранилище. После того, как он его доработал, он его помещает в тестовое хранилище, и там уже есть все изменения. И второй разработчик при захвате уже получает объект с изменениями. Конечно, теоретически может быть, что он нечаянно сотрет изменения другого разработчика. Но у нас в хранилище вся информация сохраняется, и потом, в случае возникновения каких-то проблем, мы можем это отследить, найти, скорректировать действия разработчика.
  • У нас проблема, что когда второй разработчик захватывает объект и получает изменения, он закидывает свою версию и модуль объекта меняется.
  • Именно поэтому мы требуем от разработчиков, чтобы их тестовые базы были подключены к этому хранилищу и чтобы они обновляли их оттуда, не отключали от хранилища, не вносили туда изменения и потом хранилище не обновляли своими конфигурациями.
  • Ваши релизы устанавливаются многим клиентам? Или все доработки делаются под одного клиента?
  • Нет, релиз привязан к информационной базе. Есть базы, где очень много функциональных блоков – часть из них между собой связана. И когда мы формируем релиз, туда входят все доработки, которые относятся к этой информационной базе. Там много заказчиков и разработчиков работают над этим релизом. Т.е. релиз не для одного заказчика – релиз для базы.
  • У вас в задаче была закладка «Описание для релиза». Это творческое описание, которое может отличаться от описания задачи, потому что мы туда добавляем какие-то слова для пользователя. Кто занимается этими красивыми описаниями?
  • Описания вносит консультант, который понимает, что именно дорабатывается, он сам ставит задачу разработчику. И задача консультанта – как можно более понятно пользователю сформировать это описание.

 

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019. 

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Обновление для КА 1.1, ЗУП 2.5, БУХ 2.0: НДС, ЕФС-1, Расчет страховых взносов, Мобилизация, Статистика, Электронные трудовые книжки, 2-НДФЛ, Регламентированная отчетность, Кадровый учет, Прослеживаемость импортных товаров

Зарплата Регламентированный учет и отчетность Кадровый учет Обновление 1С Платформа 1С v8.3 Сложные периодические расчеты 1С:Комплексная автоматизация 1.х 1С:Бухгалтерия 2.0 1С:Зарплата и Управление Персоналом 2.5 Бухгалтерский учет Налоговый учет Управленческий учет Акцизы ЕНВД ЕСН Земельный налог ИП, ПБОЮЛ, КФХ Налог на имущество Налог на прибыль НДС НДФЛ ФОМС, ЕФС Транспортный налог УСН ПСН (патентная система налогообложения) Платные (руб)

Обновления для конфигураций: КА 1.1; ЗУП 2.5; БУХ 2.0; КА 1.1 Комплексная автоматизация торговли алкогольной продукцией; КА 1.1 Комплексный учет сельскохозяйственного предприятия

19900 руб.

01.04.2020    140422    676    352    

232

Автоматическое подтверждение легальности обновления базы или как обновить 100 типовых баз 1С за 5 часов

DevOps и автоматизация разработки Обновление 1С Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Расширение для конфигураций 1С для автоматического подтверждения легальности обновления и выполнения обработчиков обновления при пакетном автоматическом обновлении большого числа баз 1С. А также сам модуль обработки по автоматическому обновлению баз.

2400 руб.

08.05.2019    24117    58    26    

26

Скрипт для обновления базы с расширением из хранилища

Обновление 1С Платформа 1С v8.3 Бесплатно (free)

Небольшая оптимизация рабочего времени через скрипт обновления базы 1С с расширением из хранилища конфигураций.

22.01.2024    1053    ke.92@mail.ru    2    

24

Многопоточное обновление 1С: Управление холдингом

Обновление 1С 8.3.14 1С:Управление холдингом Абонемент ($m)

Что делать, если обновление базы в режиме предприятия выполняется значительно больше вашего технологического окна, даже если это окно - с вечера пятницы и до утра понедельника.

1 стартмани

10.01.2024    3117    saver77    18    

24

Не обновляется типовая конфигурация 1С через конфигуратор

Обновление 1С Платформа 1С v8.3 Россия Бесплатно (free)

Столкнулся с проблемой. Нужно было поднять до текущего релиза Розницу 2.3. Обновлял по старинке, через конфигуратор (база клиент-серверная). Указывал логин и пароль, ждал скачивания обновления и обновлял. Но после накатывания 5 релизов следующий устанавливаться не хотел, а точнее конфигуратор гордо говорил, что обновлений больше нет. Решение нашел здесь на форуме и хочу зафиксировать. Чтобы самому не забыть и передать опыт начинающим.

29.11.2023    1264    shestopalovpro    4    

7

Принудительный запуск дополнительных процедур обработки данных после обновления

Обновление 1С Платформа 1С v8.3 Конфигурации 1cv8 Россия Абонемент ($m)

Ручной запуск процедур обработки обработчиков после обновлений. Может быть полезно стажерам, консультантам, разработчикам, администраторам, всем, кто обновляет информационные базы.

1 стартмани

20.11.2023    560    6    IvanTerentev    0    

2

Ошибка SDBL "Нет таблицы или отсутствует RefSelf"

Инструменты администратора БД Обновление 1С Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

Известно несколько способов разной степени шаманства. Предлагаю ещё один, проверенный на практике и базирующийся на точном понимании своих действий.

15.11.2023    1467    Yashazz    1    

9
Оставьте свое сообщение