В одной из предыдущих статей рассказывалось, как организован процесс разработки платформы «1С:Предприятие». А сегодня мы хотим рассказать, как разрабатывается (с помощью средств платформы «1С:Предприятие») самое, пожалуй, насыщенное по функциональности прикладное решение 1С – «1С:ERP Управление предприятием 2».
«1С:ERP Управление предприятием» — инновационное решение для построения комплексных информационных систем управления деятельностью многопрофильных предприятий, в том числе с технически сложным многопередельным производством, с учетом лучших мировых и отечественных практик автоматизации крупного и среднего бизнеса.
Немного инфографики:
Пользователями 1С:ERP стали более 900 предприятий. При этом несколько десятков проектов, с точки зрения разработчиков, получили статус «пилотного», т.е. данные предприятия и организации в первую очередь принимают активное участие в развитии новой функциональности, оперативно предоставляя обратную связь.
Вот логотипы некоторых пользователей 1С:ERP:
Интересной особенностью решения 1С:ERP является то, что разрабатываем мы одно решение — 1С:ERP – а из его исходников автоматически получаем четыре решения (путем «вырезания» функциональности и переключения функциональных опций):
- Собственно 1С:ERP. Самое функциональное решение, готовое к внедрениям на тысячи рабочих мест в средних и крупных компаниях. Модули 1С:ERP
- 1С:Комплексная Автоматизация. Ее использование будет наиболее эффективным в условиях растущего бизнеса малых и средних предприятий, управленческие процессы которых требуют четкой координации и согласованных действий нескольких исполнителей. ПодробнееКонфигурация «Комплексная автоматизация», редакция 2.0 может быть интересна для пользователей, имеющих опыт работы с комплексными конфигурациями на платформе «1С:Предприятие 7.7», и пользователей, работающих с отдельными информационными базами на основе конфигураций «Бухгалтерия предприятия», «Управление торговлей», «Зарплата и управление персоналом».
- 1С:Управление Торговлей. Позволяет в комплексе автоматизировать задачи оперативного и управленческого учета, анализа и планирования торговых операций, обеспечивая тем самым эффективное управление современным торговым предприятием.
- 1С:Управление Торговлей. Базовая версия. Решение для небольших торговых предприятий, позволяет вести учет от имени одной организации – юридического лица или индивидуального предпринимателя. Не поддерживается изменение конфигурации, можно применять только типовую конфигурацию и устанавливать ее обновления, с одной информационной базой в один момент времени может работать только один пользователь, не поддерживается работа с сервером «1С:Предприятия 8». То есть, фактически, пресловутая «автоматизация ларька».
При расширении бизнеса или увеличении потребностей компании в автоматизации наращивание функциональности системы можно производить поэтапно, переходя от конфигурации «Управление торговлей» к конфигурации «Комплексная автоматизация» и далее к «ERP Управление предприятием 2». За счет высокой степени унификации решений такой переход выполняется быстро, накопленные в информационной базе данные сохраняются, а переучивание пользователей не требуется – они продолжают работать в привычной программной и информационной среде.
Как пишется 1С:ERP
Как мы из одного решения делаем четыре
Разработка ведется только в одной ветке (ERP). Процесс формирования из флагманского решения ERP более «легких», функционально ограниченных Комплексной Автоматизации (далее – КА для краткости) и двух разновидностей Управления Торговлей (далее – УТ и УТ Базовая) автоматизирован.
Изменения из ERP в «производные» конфигурации (КА, УТ, УТ Базовая) переносятся автоматически, с использованием механизма сравнения и объединения конфигураций. Этот механизм изначально предназначен для автоматизации процесса перехода на новые версии прикладных решений тех пользователей, которые изменяют/расширяют функциональность прикладного решения на своей стороне. Механизм сравнения и объединения конфигураций выполняет трехстороннее семантическое слияние на основании анализа трех конфигураций:
- старая конфигурация от поставщика
- новая конфигурация от поставщика
- текущая конфигурация пользователя (старая конфигурация от поставщика плюс изменения, сделанные в ней пользователем)
На выходе мы получаем новую текущую конфигурацию, которая объединяет в себе новую функциональность (привнесенную разработчиком) и сохраняет доработки (кастомизации), сделанные пользователем.
В нашем случае в роли текущей конфигурации выступают поочередно КА, УТ, УТ Базовая, в роли старой и новой конфигураций от поставщика – ERP старой и новой версии соответственно. Т.е. мы считаем, что функционально ограниченные конфигурации — КА, УТ, УТ Базовая – это кастомизированные (в основном путем удаления незадействованных объектов) версии ERP.
Одни из немногих объектов, которые пишутся для каждого из решений вручную – это планы обмена, определяющие правила интеграции данного решения с другими решениями 1С (например, с 1С:Документооборотом) или, например, с внешним оборудованием. Но, благодаря постепенному переходу в обмене данными на единый стандарт EnterpriseData, мы уменьшаем количество уникальных для конкретного решения планов обмена и стараемся использовать единый код обмена данными.
В таком подходе есть одна интересная особенность. Всё решение пишется один раз, в ветке ERP; но бОльшая часть кода, форм, сценариев, отчетов и т.д. используется в четырех решениях, причем весьма разных – ERP внедряется на предприятиях с тысячами пользователей, а УТ Базовая призвана обслуживать индивидуальных предпринимателей. Мы стараемся уделять много внимания юзабилити нашего продукта.
Международный стандарт ISO 9241-11 определяет юзабилити как:
степень, с которой продукт может быть использован определёнными пользователями при определённом контексте использования для достижения определённых целей с должной эффективностью, продуктивностью и удовлетворённостью
Мы стараемся писать приложение так, чтобы с ним было легко и удобно работать даже неискушенному пользователю.
Особенности разработки
При разработке ERP мы должны всегда помнить, что разрабатываемая функциональность может быть задействована в одном или нескольких производных от ERP решениях (КА, УТ, УТ Базовая). Для легкого включения/выключения функциональности мы широко используем механизм функциональных опций, изначально созданный для таких задач. Функциональные опции позволяют выделить в прикладном решении функциональность, которую можно включать/выключать при внедрении, не изменяя само прикладное решение. Функциональные опции – это параметры настройки решения, флажки, при выключении которых вся связанная с ними функциональность становится недоступной. В первую очередь функциональные опции используются для тонкой настройки программы под нужды конкретного внедрения. В ERP мы задействуем этот механизм (помимо основного его назначения) для «вырезания» из ERP производных конфигураций. Например, в решении ERP есть функциональная опция «Управление предприятием», с ней связана вся функциональность, отвечающая за управление производством — формирование графика производства, учет производственных затрат, соответствующие отчеты и многое другое. Эта опция включена только в решении 1С:ERP и выключена в «производных» решениях КА, УТ, УТ Базовая. А всего в 1С:ERP используется около 600 функциональных опций.
Еще один механизм платформы, облегчающий труд разработчика 1С:ERP – подсистемы. Подсистемы – это способ разбить функциональность решения на блоки; каждый объект в решении (справочник, документ, отчет и т.п.) должен входить хотя бы в одну подсистему. В частности, в решении ERP заведены три подсистемы, облегчающие построение производных от ERP решений:
- «Объекты УП, УТ, КА» — объекты, входящие во все прикладные решения: Управление Торговлей, Комплексная Автоматизация, Управление Предприятием (русскоязычное название ERP).
- «Объекты УП, КА» — объекты, относящиеся только к конфигурациям Комплексная Автоматизация и ERP.
- «Объекты УП» — объекты, относящиеся только к решению ERP
Любой прикладной объект в решении ERP должен относиться ТОЛЬКО К ОДНОЙ из этих трех подсистем. Это условие проверяется при статическом анализе кода решения ERP (см. ниже).
Цифры после запятой
Версия продукта ERP состоит из четырех чисел, разделенных точками. Например — 2.1.3.117.
- Первое число (редакция) в версии меняется крайне редко (например КА 1.х.х.х и КА 2.х.х.х разделяет почти 8 лет).
- Второе число (подредакция) меняется примерно раз в год. В версии с новой подредакцией выпускается новая функциональность. Выпуск таких версий часто приурочивается к началу календарного года, чтобы у пользователей было достаточно времени на «переезд» на новую версию.
- В версиях с новым третьим числом (релиз) развивается существующая функциональность; новый релиз выходит примерно раз в два-три месяца.
- Версии с обновленным четвертым числом (исправительные сборки) содержат в себе только исправления ошибок и обновления для соответствия текущему законодательству. Выходят каждые две недели.
Единовременно у нас в разработке могут находиться до 3 версий продукта, например:
- 2.1.3.X – Поддерживаемый релиз предыдущей подредакции. Будет выпускаться до конца 2016 года. В этой версии идет только исправление ошибок и правки для соответствия текущему законодательству.
- 2.2.1.X – Текущий релиз текущей подредакции. В нем новая функциональность подредакции. Для него до выпуска релиза 2.2.2.X, будут выпускаться исправительные сборки.
- 2.2.2.X – Развитие функциональности текущей подредакции. Именно этот релиз активно разрабатывается.
Учитывая, что из каждой ветки ERP получаются, помимо ERP, еще 3 решения – КА, УТ и УТ Базовая – получаем 12 версий продуктов, находящихся в 12-ти разных хранилищах.
В ходе разработки мы имеем до 4 горизонтов планирования, например:
- 2.1.3 (поддерживается), решаем, какие ошибки правятся, какие проекты, связанные с изменением законодательства, будем реализовывать. Будут реализованы только те изменения, которые вступят в силу в 2016 году. Горизонт – до конца 2016 г.
- 2.2.1 (поддерживается) – исправляются «внешние» ошибки + изменения законодательства, вступающие в силу до выхода 2.2.2. Горизонт – до выхода 2.2.2.
- 2.2.2 (активно разрабатывается) — исправляются «внешние» ошибки + найденные нами ошибки + реализуется новая функциональность. Горизонт – до выхода 2.2.3
- 2.2.3 (планируется). Если проект большой, то он может сразу разрабатываться на эту версию (и не войдёт в предыдущую). Горизонт – до выхода 2.2.4 или до конца 2017 года.
Использование продукта «1С:Система проектирования прикладных решений» в разработке ERP
Как уже рассказывалось, мы в 1С стараемся следовать принципу Eat your own dogfood, используя наши собственные продукты в наших внутренних процедурах. В частности, в разработке ERP мы широко используем продукт «1С:Система проектирования прикладных решений» (сокращенно СППР). СППР, как следует из названия, помогает проектировать прикладные решения на платформе «1С:Предприятие», и позволяет обслуживать задачи полного цикл разработки ПО — сбор требований, контроль изменений, документирование, баг-трекинг и т.д.
СППР позволяет создавать элементы двух типов – ошибки (которые должны быть исправлены) и требования (запросы на новую функциональность). С ошибками все более-менее ясно, рассмотрим создание нового требования.
Поводом для создания требования может быть:
- Запрос от партнера или клиента. Такие запросы мы собираем, в частности, на партнерских семинарах; путем голосования среди партнеров мы выделяем наиболее приоритетные из них.
- Запрос может возникнуть в ходе пилотного проекта по внедрению новой версии в том случае, если у клиента возникло важное для него пожелание.
- Запрос от нашей службы техподдержки (точнее, запрос от партнера или клиента, прошедший через нашу техподдержку), запрос с нашего партнерского форума или от нашего аккаунт-менеджера (который сопровождает важного для нас клиента/клиентов).
- Запрос от команды разработки платформы 1С:Предприятие. Платформенная команда просит команду разработки ERP (и других типовых конфигураций) использовать новую платформенную функциональность – например, интерфейс Такси, отказ от модальных окон, отказ синхронных вызовов и т.д.
- Рефакторинг, оптимизация архитектуры, улучшение юзабилити.
Поводом для рефакторинга (п.5) могут быть серьезные архитектурные изменения (например, пересмотр распоряжений на отгрузку, когда вместо накладных стали использоваться заказы).
Продукт СППР поставляется в составе ERP (но его можно купить и отдельно). Решение ERP может быть запущено в режиме интеграции с СППР; в этом случае на каждой форме будет кнопка «Открыть функциональную модель», при ее нажатии откроется описание функциональности формы в СППР.
Вот, что открывается – это модель рабочего места в IDEF0:
Можно и наоборот – изучать функциональную модель и из нее открывать формы рабочих мест. Такой режим можно использовать при изучении работы программы.
Важный момент – открывается не СППР, открывается форма внутри ERP, куда подгружаются данные из СППР. Т.е. интеграция «бесшовная» (пользователь ее не видит). Этот прием применяется при интеграции и с другими продуктами. Например, с 1С:Документооборот (можно работать не выходя из ERP с почтой, задачами, бизнес-процессами, которые работают в другой базе).
Как мы разрабатываем ERP: 6 контрольных точек проекта
Итак, решено реализовать новое требование на изменение функциональности. Однотипные требования объединяются в технические проекты. В рамках нового релиза ERP обычно реализуются от 100 до 150 технических проектов, каждом проекте – от одного до нескольких десятков требований. Технический проект заводится в СППР; проект в ходе реализации проходит через 6 контрольных точек, каждая из них фиксируется в СППР.
Немного о делении на команды внутри подразделения ERP. Руководитель команды (тим-лид) участвует в проектировании и, как правило, участвует в разработке. В состав команды также входят обычно тестировщики. Команды разработки статичны, за ними закреплены по нескольку предметных областей. Если проект затрагивает смежные области, на время реализации проекта привлекаются участники соответствующей команды. В проект может быть вовлечена не вся команда.
Ответственный за проект – ведущий разработчик или тим-лид. На его ответственности – контроль процессов:
- Качественное проектирование, учет всевозможных сценариев, сопряжение со смежными блоками
- Сроки
- Качество архитектуры, пользовательского интерфейса
- Написание справки, оформление проекта, в т.ч. разработку функциональной модели
Точка 1. Открытие проекта
Тим-лид заводит технические проекты в СППР списком на релиз. В каждом проекте расписываются цели, указываются реализуемые требования. Список перед началом работы над релизом обсуждается с руководителем разработки. Собственно при открытии проекта совещаний не проводят – просто проект в СППР посылают на открытие.
Команда проекта приступает к разработке концепции.
Точка 2. Согласование концепции
Для согласования концепции проводится онлайн или офлайн встреча, в которой участвуют ответственный за проект, тим-лид, руководитель разработки, вовлеченные в проект специалисты. Обычно к этому этапу у ответственного за проект готов «крупноблочный» концепт, который дошлифовывается в ходе встречи. Также обсуждаются (и прописываются в СППР) сценарии, описание пользовательского интерфейса. Если требование родилось из запроса партнеров или клиентов, то материалы проекта (концепции, сценарии, UI) могут быть отправлены партнеру/клиенту для оценки решения.
В процессе встречи согласуется трудоемкость создания прототипа (обычно создание прототипа занимает до 5 рабочих дней). Команда приступает к созданию прототипа.
Точка 3. Согласование прототипов
Проводится встреча, в ходе которой рассматриваются готовые прототипы, обсуждаются детали реализации (в частности, какие объекты будут добавляться и изменяться), проверяются гипотезы, утверждаются прототипы форм и т.д. С целью максимально серьезной проверки на юзабилити прототипы запускаются в самом «жестком» режиме – в веб-клиенте, в интерфейсе «Такси», на мониторах с маленьким разрешением.
Функциональная модель проекта в нотации IDEF0 разрабатывается и хранится в СППР.
На этом этапе проектная команда должна как можно точнее оценить трудозатраты на реализацию проекта, поэтому обсуждаются (и документируются в СППР) все аспекты проекта:
- Согласование правильности описания проекта в СППР (в частности, отслеживается, что все задачи на предыдущих контрольных точках проекта выполнены).
- Какие новые объекты метаданных (справочники, документы и т.д.) будут добавляться в решение
- Какие изменения будут делаться в уже существующих объектах метаданных
- Согласование планов обменов данными с другими решениями(будут ли новые/измененные данные участвовать в обмене данными с другими приложениями, и если да – то как именно)
Если трудозатраты всех устраивают – проводится презентация (на основе материалов по проекту из СППР) всего, что сделано по проекту, с целью выявить как можно больше нюансов перед началом разработки.
И начинается разработка!
Точка 4. Согласование разработанного решения
Решение разработано, подготовлена презентация (в формате PowerPoint). Часто проводится очное совещание с «живым» показом разработанного решения.
Если проект публичный (опубликован в доступном партнерам списке планов на сайте 1С), то презентация выкладывается на партнерском форуме в разделе ERP, чтобы все заинтересованные партнеры могли ознакомиться и высказать свои замечания.
Точка 5. Тестирование и аудит проекта
По окончании основной разработки проводится прогон ручных функциональных тестов. Тестеры как полноценные члены команды участвует во всех контрольных точках проекта и имеет понимание функциональности проекта и сценариев работы. Тестеры также оценивают новую функциональность на соответствие нашим стандартам юзабилити. Эти стандарты (включают в себя стандарты кодирования и стандарты разработки интерфейса) публикуются в доступном партнерам ресурсе на сайте 1С.
Код проекта проходит процедуру code review. Code review в ERP проводят участники другой проектной группы; code review – обязанность, которую все разработчики команды ERP несут по очереди. В случае если в коде найдены проблемы, в СППР регистрируются ошибки, которые должны быть исправлены до прохождения точки 5.
Проводится проверка обновления на новую версию с предыдущей (последней выпущенной на данный момент сборкой).
Итак, проект готов, тесты пройдены, время заливать код в основное хранилище (до этого вся разработка ведется в отдельном хранилище технического проекта). На этом этапе также заканчивается написание справочных материалов по новой функциональности (справка хранится в СППР).
По окончании этапа (тесты пройдены и готовы справочные материалы) проект заливается в основное хранилище; после этого проводится выборочное регрессионное тестирование в смежных областях – мы должны убедиться, что не сломали ничего из существующей функциональности.
Точка 6. Окончание проекта
Закрываем проект в ССПР – присваиваем ему статус «Выполнено».
Выпуск версии
Примерно за месяц до выпуска нового релиза накладывается мораторий на заливку новых проектов в основное хранилище (разработка в хранилищах тех. проектов продолжается); те проекты, которые не успели закончиться к этому времени, переносятся на другую версию.
В течение этого месяца проводится регрессионное тестирование; вносить изменения в код разрешено только для исправления привнесенных в этом релизе ошибок. Непривнесенные ошибки (те, которые воспроизводились и на предыдущих релизах), к началу регрессионного тестирования обычно почти все исправлены; те же ошибки, что остались, переносятся на следующий релиз. Основная задача регрессионного тестирования – гарантировать неухудшение качества продукта.
В качестве баг-трекера, как уже говорилось, используется все тот же СППР.
Исправительные сборки
Каждые две недели мы выпускаем исправительные сборки к версиям; на сегодня это 2.1.3.x, после выхода релиза 2.2.1 будут выпускаться 2 исправительные сборки — 2.1.3.x и 2.2.1.х. От регистрации ошибки до появления ее в исправительном релизе у нас проходит менее двух недель; наша статистика показывает, что среднее время от обращения клиента с ошибкой в ERP в поддержку до выхода ее исправления в исправительной сборке на сегодня – 9 дней.
Разветвленная разработка
В групповой работе над ERP мы стараемся использовать средства, предоставляемые нам платформой 1С:Предприятие. Конфигурации хранятся в хранилище конфигураций, при чекине новой функциональности в ветки используется стандартный механизм поставки и поддержки. Все операции автоматизируются по максимуму; в случае, если объекты менялись только на стороне разработчика – объединение кода происходит без участия программиста. Если для объединения исходников нужно вмешательство разработчика, обычно мы используем встроенные возможности платформы. Но есть также возможность вызова сторонних инструментов сравнения/объединения из инструментов платформы (например, KDiff3 или Araxis). Кстати, эта фича – вызова сторонних инструментов сравнения/объединения — была добавлена в платформу по запросу именно команды разработки ERP.
Разное
При разработке новой функциональности мы используем ту версию платформы, которая будет доступна на момент выхода новой версии ERP (на сегодня это платформа 8.3.8).
Это возможно благодаря тому, что в платформе очень активно используется режим поддержки совместимости с предыдущими версиями. Как только появляется новая платформа – мы на нее переходим, а вот отключение режима совместимости происходит далеко не сразу. Это связано с тремя причинами:
- Мы хотим меньше «шокировать» пользователей, поэтому отключение режима совместимости мы стараемся делать в «тихие» периоды, а не тогда, когда все пользователи, например, сдают отчетность.
- Обычно отключение совместимости связано с разного объема переделками конфигурации. Их нужно планировать, для их реализации нужно время.
- ERP – это конфигурация, в состав которой входит на настоящий момент 10 библиотек. Отключать совместимость можно только тогда, когда все библиотеки тоже это сделают.
О библиотеках можно написать отдельно. Библиотека – это специальным образом написанная конфигурация, которая включает в себя функциональность, которая должна одинаковым образом работать в различных конечных наших прикладных решениях. Интеграция библиотек осуществляется с помощью уже упомянутого механизма платформы «Поставка конфигураций». Библиотеки разделяются на публикуемые (те, которые мы публикуем, и которые могут использовать сторонние разработчики в своих прикладных решениях) и внутренние (которые мы отдельно не публикуем – только в составе прикладных решений). Подавляющее количество библиотек являются публикуемыми.
В состав ERP входят 10 библиотек, разрабатываемых другими командами. Их код не меняется разработчиками команды ERP.
- Библиотека стандартных подсистем.
Базовая функциональность – права доступа, печать, почта и т.д. Входит в состав большинства прикладных решений.
- Библиотека регламентированной отчетности.
Формирование отчетности в фискальные органы, подача отчетности в электронном виде
- Библиотека подключаемого оборудования.
Драйверы для работы с различным оборудованием: сканеры штрих-кодов, фискальные регистраторы, весы и т.д.
- Библиотека технологий сервиса.
Взаимодействие конфигураций, работающих в режиме сервиса (т.е. развернутых в «облаке») с инфраструктурой сервиса
- Библиотека интеграции с 1С:Документооборот.
Бесшовная интеграция с 1С:Документооборот: сквозные бизнес-процессы, общий список задач, работа с файлами, почтой и т.д. не выходя из окна ERP.
- Библиотека «Зарплата и кадры» (расширенная)
Расчет зарплаты, ведение кадрового учета, отчетность для ПФР. Функциональность 1С:Зарплата и управление персоналом в ERP
- Библиотека интернет-поддержки пользователей.
Информирование о выходе обновлений, обращение в тех. поддержку, скачивание и установка обновлений
- Библиотека электронного документооборота.
Обмен электронными документами с контрагентами (в т.ч. юридически значимый ЭДО), DirectBank (прямой обмен с банками), обмен с сайтами (CMS). - Библиотека интеграции с ЕГАИС.
Обмен с Единой Государственной Автоматизированной Информационной Системой для учета операций по розничному обороту алкоголя. - Библиотека регламентированного учета.
«Кусочек» 1С:Бухгалтерии в ERP. Вообще регламентированный учет в ERP в методической части (за некоторыми небольшим исключениями) сходен с 1С:Бухгалтерией, но его реализация отличается и делается независимо. Из 1С:Бухгалтерии мы берем бухгалтерские отчеты и отчетность по некоторым налогам.
Как мы тестируем 1С:ERP
После создания из ERP трех решений — КА, УТ, УТ Базовая — для проверки корректности всех четырех решений мы проводим статический и динамический анализ полученных конфигураций.
Частичный статический анализ проводится каждый раз после того, как из хранилища ERP создаются конфигурации КА, УТ, УТ базовая и заливаются в собственные хранилища (этот процесс проходит два раза в день).
Более развернутый статический анализ делается с помощью конфигурации 1С:Автоматическая Проверка Конфигураций (1С:АПК). В частности, 1С:АПК проверяет:
- Состав ролей. Например, проверяется, что права на чтение всех констант включены в роль «Базовые права».
- Соответствие кода принятым стандартам. Для большого количества стандартов прикладной разработки (которых у нас несколько сотен) написаны процедуры анализа кода на предмет их соблюдения. Например, что не используются полные соединения в запросах, или, что правильно локализованы строки, которые отображаются в интерфейсе.
- Специфические проверки, связанные с особенностями разработки ERP
Например, проверка, что каждый прикладной объект входит только в одну из подсистем «Объекты УТ, КА, УП», «Объекты КА, УП» или «Объекты УП»
Динамический анализ кода включает в себя, в частности, регрессионное тестирование, в рамках которого прогоняются следующие операции (а результаты операций сверяются с последним предыдущим успешным тестированием):
- Открытие всех форм
- Обмен данными с другими прикладными решениями (например, с 1С:Бухгалтерия Предприятия)
- Отражение проведенных документов в учете. Проверяется, что после проведения документа в эталонной базе результат отражения его в учете не поменялся.
- И др.
Для регрессионного тестирования мы используем от 10 до 20 баз данных, различного размера (от 15 Гб до 70 Гб) и разной специфики наполнения.
На этих же базах тестируем обновление на новую версию с предыдущей, с целью убедиться, что обновление проходит а) корректно и б) за разумное время.
При обновлении базы 1С есть два существенных этапа:
- Основное время — обновление данных в многопользовательском режиме. Прикладное решение готовит данные к обновлению в фоне, пользователи могут продолжать работать с системой, но быстродействие системы может быть снижено и часть функций могут работать ограниченно. Обычно обновление на новую версию проводят в выходные (когда активность пользователей минимальна).
- Минимальное время — обновление в монопольном режиме. Когда все данные подготовлены в фоновом режиме, наступает время изменения структуры БД. Для этого база данных переводится в монопольный режим, когда работа пользователей с системой невозможна. Скорость обновления крайне важна для наших пользователей.
В ближайших планах – расширение зоны автотестирования с целью покрыть ими максимальное количество сценариев.
Заключение
ERP – один из самых масштабных наших продуктов. Мы стараемся использовать в его разработке современные и передовые методики, а также создавать новые методики и инструменты, чтобы, с одной стороны, быстро его развивать, а с другой стороны — обеспечивать высокое качество разработанного решения.
Комментарии (54)
juffinhalli
29.03.2016 13:44+5Простите накипело. Эта статья уже не актуальна? Для меня 1C до сих пор остаётся венцом отечественной
экономики говнакопроэкономики. Одна активация клиентского ПО чего стоит. А версии под Linux? Ещё много боли. Так можно долго перечислять. Эффективные менеджеры, <много матных слов>!
Спасибо, хоть хабру дали заработать.
PeterG
29.03.2016 14:16+1Спасибо за полный позитива пост, коллега!
Вы у каждого явления видите только одну сторону?
Ну и не устану повторять — ненависть лучше, чем равнодушие)juffinhalli
29.03.2016 14:32+1Пока я вижу только то, что за 25 лет флагманский продукт не довели до ума. К монополисту знаете ли, сложно быть равнодушным.
Yag0andy2006
29.03.2016 14:52+1С удовольствием почитаю Вашу статью о Вашем продукте, доведённом до ума.
juffinhalli
29.03.2016 15:11-1PeterG
29.03.2016 17:19+3Видимо, пока juffinhalli не сочтет, что все проблемы 1С наконец решены, мы не должны публиковать никаких статей на Хабре.
juffinhalli
29.03.2016 19:19-2Публикуйтесь на здоровье! Хабру нужно чем-то оплачивать хостинг. Цель моих сообщений это донести до не знакомых с этой кухней хабровчан, что за красивыми рекламными проспектами кроется корыстное желание посадить Вашу компанию на новую ЕRP иглу и выкатывать за этим ещё большие ценники. Наплевательское отношение компании к своим клиентам прилагается бесплатно. И ничего личного. Видно место проклятое (с)
YourLastDoctor
29.03.2016 19:44+2Нас самом деле, для специалиста, принимающего решения об использовании той или иной ERP, ваши сообщения, загрязненные мемами (видимо, как и ваше сознание), ненавистью, и оскорблениями широкому кругу вовлеченных в экосистему, несут нулевую информационную ценность, и являются мусорными в данном месте в данное время.
Мусорить, конечно, ваше право, но конструктивно было бы доносить информацию, которую вы считаете важной, в публикациях соответствующей тематики.
winstowins
30.03.2016 15:00+1Коллега, критиковать всегда просто. Это самый первый способ.
В условиях рынка — можно перейти на другой программный продукт.
В некоторых случаях — это даже очень полезно.
Например — по поводу ценников. Думаю верно будет тогда озвучивать ценники конкурентов?
Как минимум — это будет некоторый сравнительный анализ и очень полезен для «не знакомых с этой кухней»
Можно и дальше продолжать обсуждать.
В целом — в любом программном продукте, есть «неточности, проблемы». Как показывает практика — чем лучше специалист подготовлен — тем меньше этих проблем возникает. В некоторых западных компаниях (и это очень большой плюс) — просто не допускают сотрудников без соответствующей квалификации в запуску и обслуживанию.
По поводу «25 лет». Опять же — предлагаю посмотреть на каком движке сделаны аналоги, и каким годом датируется этот движок. И если говорить за ERP — конкретно — то ей точно не 25 лет. А гар
Locolind
31.03.2016 10:19+2Вот этот внедренный подход к разработке — это +100500 в карму 1С.
Ребята встали на очень правильные рельсы, думаю это ощутила уже вся команда и это уже ощущает часть клиентов. А дальше будет ещё лучше.
Большинство других команд разработчиков в нашей о такой «технологии организации работ» пока могут мечтать.
Будучи человеком сопричастным к внедрению и развитию ИТ-систем, и находясь больше на стороне Бизнеса, болею за их «боль» (решение их проблем), могу сказать это серьезная заявка на то, что продукт 1С лет через 10 начнет вытеснять западные решения/продукты в силу лучшего понимания отечественной специфики и более высокой скорости реализации изменений.
Благодарю за статью! +1 вам в карму.
Provlax
29.03.2016 15:40+2Это ваше мнение и вы конечно имеете на него право. Однако на рационально мыслящего человека ваши нелепые ярлыки вряд ли могут произвести впечатление. Как минимум пока вы не уточните уровень вашего профессионализма в данной конкретной отрасли. А пока вы выступаете в роли той бабки, которая всем у подъезда рассказывает.
Apatic
01.04.2016 10:32Читал прошлые посты от 1С и прямо радовался — количество неадекватных истерик, столько часто устраиваемых "IT специалистами" по поводу 1С, стремилось в них к нулю. Наконец-то, думаю. Но вот, видать, рано радовался.
YourLastDoctor
29.03.2016 15:05Как вы работаете с Хранилищем конфигурации в столь масштабном проекте? Не доставляют ли неудобств эксклюзивные захваты объектов для изменения? Отсутсвие бранчей(веток)? Даже в небольшой команде с этим определенные трудности (а так же, с быстродействием самого хранилища).
PeterG
29.03.2016 15:06+1Разработку мы ведем в хранилищах разработки, которые стоят на поддержке от основного хранилища. Это и есть наши бранчи. Создание бранчей автоматизировано и происходит с помощью СППР. При этом использует пакетный режим запуска "Конфигуратора", т.е. в принципе мы пользуемся штатными возможностями платформы. В одном бранче редко бывает необходимо нескольким разработчикам захватывать один объект.
В основном хранилище происходят заливки проектов и исправления ошибок, поэтому ситуации когда двум разработчикам нужен один объект опять-таки минимизированы, и тем более очень редко бывает, когда объект нужен надолго. В "горячую пору", когда много проектов нужно залить в основное хранилище — это после снятия моратория, связанного с выпуском версии, когда за период моратория накапливается какое-то количество проектов на заливку — мы решаем организационно, выстраивая очередь заливок. Но это не часто бывает.
С быстродействием примерно та же история — в основном хранилище разработка не ведется, поэтому фатальна скорость работы не основного хранилища, а бранчей. В бранчах же история небольшая, поэтому бранчи достаточно шустро работают.YourLastDoctor
29.03.2016 15:23Спасибо, весьма ценная информация. В свое время для воркфлоу — основная часть команды на сопровождении правит баги, а другая подгруппа делает новую "фичу", приходилось вручную поднимать копию основного хранилища, и по окончанию работ, вручную мержить правки в основное хранилище. Хорошо, что теперь есть канонически способ, не требующий от человека выполнений функций VCS :)
EvilBeaver
29.03.2016 17:47+1А есть ли автоматизация бранчей-хотфиксов?
- выпустили свежую версию, создали N бранчей и ведем разработку, часть слили в ствол.
- обнаружили баг.
Где правим и как объединяем изменения?YourLastDoctor
29.03.2016 20:03Обнаружили баг, через СППР создали бранч для разработки багфикса, влили в ствол, N бранчей разработки обновили через механизм поставки из ствола, вроде должно быть так. Код СППР открыт, по идее, можно сделать любые автоматизации под нужный workflow (и даже на основе СППР написать свой велосипед). Жаль, с 1С давно завязал, было бы интересно развернуть такой процесс.
pumbaEO
29.03.2016 17:01+4Все операции автоматизируются по максимуму
Интересен список этих операций.PeterG
30.03.2016 10:44-2Это описано в ИТС. Информация доступна легальным пользователям ИТС.
alexey-lustin
30.03.2016 11:11Только без обид. Но этой информации там нет. Система стандартов на ИТС устарела насколько мне известно.
vdovin_ds
30.03.2016 09:40+1Привет.
А расскажите немного больше про код ревью.
С помощью какого инструмента вы его делаете?PeterG
30.03.2016 11:12- Формируется отчет о сравнении ветки разработки и основного хранилища. Аудитор просматривает изменения, если нужно посмотреть более внимательно, то открывает в Конфигураторе конфигурацию ветки.
- Также проверки кода делаются автоматически с помощью продукта "Автоматическая проверка конфигураций", куда в поставку заложены формальные проверки целого рядов стандартов разработки.
vdovin_ds
30.03.2016 12:15Т.е. способов, что бы ревьювер мог оставить комментарий к строчке кода нет? именно этого очень хочется
PeterG
30.03.2016 15:46Замечания аудитор записывает в СППР. Сюда загружается отчет о сравнении, который при загрузке парсится, по нему заполняется список измененных тех. проектом объектов. Сам отчет аудитор просматривает тоже из СППР в контексте измененных объектов. "Проглядел список измененных объектов — посмотрел что именно изменилось каждом объекте — записал замечания" — все это не выходя из СППР. Замечания регистрируются в ошибками и попадают в общий контроль сроков исправления ошибок.
- Формируется отчет о сравнении ветки разработки и основного хранилища. Аудитор просматривает изменения, если нужно посмотреть более внимательно, то открывает в Конфигураторе конфигурацию ветки.
fishca
30.03.2016 10:45А всего в 1С:ERP используется около 600 функциональных опций.
Да и общих модулей не шибко меньше. И это не есть хорошо.PeterG
30.03.2016 10:46Да и общих модулей не шибко меньше. И это не есть хорошо.
А почему вы считаете, что это плохо?fishca
31.03.2016 15:17Указательный палец устает скроллить ;) Работать с таким количеством объектов крайне не удобно и тяжело.
ardn
31.03.2016 16:55Чем меньше кусочек конфигурации, тем удобнее его поддерживать (рефакторить, вносить новую функциональность). Это очень удобно.
Ну а насчет скролла — не зря же поисковую строку объектов метаданных добавили.
Lavs
31.03.2016 20:41А вы пробовали поиск (Ctrl + Alt + M)? Сразу сокращает количество объектов до минимума.
huse
30.03.2016 10:54У такого масштабного продукта должна быть мощная методологическая проработка в предметной области. Как она происходит? Есть ли она вообще? А то судя по статье — просто партнеры пишут заявки, кто то их рассматривает и принимает решение делать не делать, а дальше поперла разработка.
Почему спрашиваю — вызывают вопросы некоторые термины, подходы и странности в продукте. Создается впечатление, что если методолог и есть, то он давно сдался и нервно курит, закрывшись в кабинете.PeterG
30.03.2016 10:55Непонятно разделение на "методическую проработку" и "разработку". Это неразделимые понятия при работе над таким сложным и многовариативным проектом, как "ERP". В ходе разработки ведется методическая проработка вопросов тим-лидами, ответственными за проекты, руководителем разработки. Если это необходимо, то привлекаются сторонние специалисты: проводятся консультации с представителями клиентов (логистами, фин. директорами, производственниками и т.д..), партнеров, юристами, аудиторами, специалистами по юзабилити, производительности и т.д… Это делается на протяжении всей работы над проектом: при выработке начальной концепции, при доработке концепции, при обсуждении сценариев работы пользователей, оценке интерфейсов и т.д… Будут привлекаться другие специалисты или нет, насколько будут привлекаться, на каких этапах — решается индивидуально при работе над каждым проектом.
DonAlPAtino
30.03.2016 16:46Прошу прощения если вопрос не совсем по теме — в Комплексной Автоматизации 2 проводки делаются сразу или в отложенном режиме (Как в ERP?). У меня проект бухгалтера исключительно за это зарубили год назад...
PeterG
31.03.2016 12:33Вопрос действительно не по теме, попробуйте обратиться на линию консультации.
DonAlPAtino
31.03.2016 12:45Вот когда сотрудник 1С говорит "попробуйте обратиться на линию консультации" это о многом говорит. Когда они ответят (а ответят они что-нибудь в стиле "вы указали не тот регистрационный номер") я забуду в чем вопрос был. :-(. Может лучше кто-нибудь из 1С напишет про Комплексную автоматизацию сюда?
Figurnov
31.03.2016 16:18когда сотрудник 1С говорит «попробуйте обратиться на линию консультации» это о многом говорит.
Например, о том, что 1С большая организация, в которой разрабатываются десятки очень разных продуктов, и ни один сотрудник не может знать всего обо всех продуктах.
Когда они ответят (а ответят они что-нибудь в стиле «вы указали не тот регистрационный номер») я забуду в чем вопрос был.
Наверное, потому, что этот вопрос для вас маловажен.DonAlPAtino
31.03.2016 16:54+1Вообще-то в первом абзаце данной статьи рассказывалось про разработку КА путем вырезания ее из ERP. Так что то что вы не знаете — не верю. Это не "десятки очень разных продуктов".
Послали вы меня дружно. Очень характерно для представителей 1С. Тут тоже не поспоришь.
Но "большое спасибо" за уделенное время.Figurnov
31.03.2016 17:54в первом абзаце данной статьи рассказывалось про разработку КА путем вырезания ее из ERP. Так что то что вы не знаете — не верю. Это не «десятки очень разных продуктов».
Конечно, не все продукты 1С делаются независимо друг от друга. Из 1С:ERP 2 делаются Комплексная автоматизация, Управление торговлей и Управление торговлей (базовая версия). 1С: Бухгалтерия предприятия выпускается в виде базовой, ПРОФ, КОРП версий, приложения "Предприниматель 2015", и все они адаптируются для разных рынков сбыта. И так далее.
Но даже с учетом этого продуктов у 1С много десятков, посмотрите сами.
https://releases.1c.ru/total?hideUnavailablePrograms=falseVasiliyKudryavtsev
31.03.2016 18:29Туда доступ только для зарегистрированных пользователей
DonAlPAtino
01.04.2016 10:01+1Судя по ссылкам сюда на партнерский форум, итс и прочее сотрудники 1С об этом не догадываются. "У каждого ДОЛЖНА БЫТЬ подписка на 1С!"
Figurnov
31.03.2016 19:07Насколько я помню, это настраивается. Для каждой организации можно сделать свою настройку.
AlexScamp
31.03.2016 16:08+1Петр, спасибо за статью, всегда читаю с удовольствием, некоторые моменты интересны (и просто «подсмотреть», и опыт перенять)… Но всегда когда доходит до комментариев (в которых часто бывают не менее интересные вещи и мысли, чем в статье, поэтому читаю обязательно) почти всегда вижу одно и то же. Кажется, тут балом правят мнения, что стакан наполовину пуст (а то и вообще пуст), а особенно забавляет (и удручает одновременно) слышать мнения от людей, которые давно не в теме, где-то что-то слышали или может и сталкивались, но давно и не долго и как оно сейчас — понятия не имеют (не всегда конечно так, но очень часто). И удручает то собственно потому, что наверняка есть люди, которым такое мнение будет просто навязано («много плюсиков у комментария» -> «автор прав»), и дальше все по кругу… Это весьма печально для уважаемого все-таки технического ресурса. И в связи с этим всем вопрос к вам — а зачем вам этот блог?)
PeterG
31.03.2016 16:55+3Спасибо за интерес! Попробую ответить — зачем мне этот блог.
Почти всю свою программерскую жизнь я занимался написанием платформ для ERP — iScala, Epicor, потом Microsoft Dymanix (тут правда писал больше прикладной код). В самом начале 2000-х, мы с коллегами в шведской компании Scala придумали новый фреймворк/платформу ERP, основанную на метаданных и облегчающую жизнь прикладного разработчика. Чуть позже вышли ранние версии Microsoft Business Framework и наш собственный проект заморозили, считая, что Microsoft Business Framework решит все наши задачи. Но MBF так и "не взлетел", а время для реализации своего фреймворка мы упустили.
Когда я в очередной раз оказался на профессиональном распутье (поработав разработчиком, тим-лидом, директором R&D и т.д.), фирма 1С сделала мне очень интересное предложение — заняться продвижением их платформы. Про 1С я всегда был высокого мнения (т.к. были знакомые, писавшие платформу 1С), но, познакомившись поближе с нынешней платформой, я понял, что примерно вот это мы с коллегами и хотели написать лет 15 назад. Но в силу ряда причин (в том числе и отсутствия ряда экспертиз в прикладных областях) не смогли.
А в сравнении с конкурентами (которых я немало повидал, а часть из них даже написал) платформа 1С обладает огромным числом преимуществ; главные из них (на мой взгляд) — продуманная объектная модель (не нагромождение классов и таблиц, а реальные объекты из мира учетных систем с минимумом программного кода), продуманная система обновления, кросс-платформенность (в особенности наличие веб-клиента "бесплатно", без единой строчки доп. кода, и мобильный фреймворк). Понятно, что у каждой системы есть баги, недостатки. Но концепт, зерно, заложенное в основу платформы 1С — самое, на мой взгляд, правильное, по сравнению с другими продуктами, представленными на рынке.
"А мужики-то не знают!". Вот я и пытаюсь донести это до ИТ-сообщества. Парадокс ситуации в том, что чтобы понять всю прелесть платформы 1С — надо написать на C++/Java/Delphi парочку учетных систем с нуля. Понаступать на грабли, поизобретать велосипеды. А потом написать учетную систему на платформе 1С. И оценить трудозатраты.
А у нас многие разработчики 1С кроме 1С ничего не щупали. Отсюда их избалованность и пресыщенность. А ведь полезно иногда посмотреть, как выглядят проблемы пользователей/разработчиков конкурирующих систем.
Хабр же считаю самым лучшим на сегодня IT-ресурсом. Не без недостатков, конечно.
Уф, много написал, но, надеюсь, мысль — зачем мне нужен этот блог — донес.YourLastDoctor
31.03.2016 17:02На аватарке вы? Если да, когда и на каком аэродроме снято? :)
PeterG
01.04.2016 11:05Я, аэродром Коробчеево АКА Аэроград, 28 августа 2015 г.
Фотосессия "1С в облаках" в поддержку продукта 1cFresh.
svcoder
08.04.2016 14:51-1Функциональная модель проекта в нотации IDEF0 разрабатывается и хранится в СППР.
1. Кем она разрабатывается? Неужели вы ее разрабатываете в редакторе графических схем внутри СППР? Это ведь абсалютно неудобное средство, например по сравнению с BPWin. Как вы переносите элементы с уровня на уровень?
2. Вы написали, что в СППР вносятся изменения на этапе 3, при этом на этапе 5 проект может быть не готов в включению в очередной релиз. То есть изменения вносятся в какую-то ветку СППР, а затем каким то образом переносятся в основную ветку?
3. Кто пишет справку, сами разработчики или отдельные технические писатели. Как синхронизирована встроенная справка и документация?
4. Как разработчики ERP смирились с тем, что запись конфигурации после небольшого изменения занимает от 40 секунд (при работе на сервере приложений) до 3 минут при файловой базе?
5. Почему в состав конфигурации входит регламентированная отчетность, которая занимает огромную часть из указанного вами объема строк кода и которая может поставляться отдельной поставкой и также отдельно обновляться?
6. В СППР есть поле оценка. Кто ее выполняет и контролирует. Есть ли анализ, почему оценка была превышена, есть ли какие-то штрафы для разработчика, регулярно превышающего оценку?
7. По вашей оценке, если необходимо добавить в конфигурацию в какой либо справочник новый реквизит и вывести его на форму сколько человеко-часов это потребует (хотя бы приблизительно общее количество времени на обсуждение, прототип, разработка, тестирование, справка, внесение в СППР и т.п.)
svcoder
08.04.2016 16:15Пример разработки ERP:
ШаблонСообщения = НСтр(«ru = 'Номенклатура %НоменклатураХарактеристика% %Назначение%
|Превышен оперативный складской остаток на складе „“%Склад%»" на %Количество% %Единица%'");
Если строку внутри НСтр передать переводчику для перевода на английский язык, что он напишет? И так во всей конфигурации!YourLastDoctor
08.04.2016 17:19А в чем проблема перевести строковый шаблон? Ну да, это не gettext и .po-файлами, выглядит слегка непривычно.
alexey-lustin
https://partners.v8.1c.ru/forum/t/1468491/m/1468491
https://partners.v8.1c.ru/forum/t/1466117/m/1466285
PeterG — по ссылкам есть интересные моменты. Публично озвучивать не могу.
PeterG
Алексей, я в теме, люди работают.
Для непубличных коммуникаций у тебя есть моя почта)