Как организовать разработку 1с
Привет, Хабр!
В этой статье мы расскажем, как построен процесс разработки платформы «1С:Предприятие», как мы работаем над обеспечением качества, и поделимся уроками, которые получили, создавая один из самых больших российских программных комплексов.
Люди и процессы
- Средства разработки (Конфигуратор)
- Веб-клиент
- Серверная инфраструктура и отказоустойчивый кластер
- и т.д.
С другой стороны, в практиках, которые направлены «вовнутрь», команды достаточно автономны. Например, инспекции кода сейчас применяются во всех командах (и существуют общие правила, определяющие обязательность прохождения ревью), но были внедрены в разное время и процесс построен по разным правилам.
То же самое касается организации процесса — кто-то практикует варианты Agile, кто-то использует другие стили ведения проекта. Канонического SCRUM, кажется, нет нигде — специфика коробочного продукта накладывает свои ограничения. Например, замечательная практика демонстрации оказывается неприменимой в неизменном виде. Другие практики, например, роль Product Owner, имеют у нас свои аналоги. В качестве Product Owner по своему направлению обычно выступает руководитель группы. Помимо технического лидерства в команде, одной из самых главных его задач является определение дальнейших направлений развития. Процессы выработки стратегии и тактики развития платформы – это сложная и интересная тема, которой мы посвятим отдельную статью.
Работа над задачами
Когда принято решение о реализации того или иного функционала, его облик определяется в серии обсуждений, в которых участвуют, как минимум, разработчик, ответственный за задачу и руководитель группы. Часто привлекаются другие члены команды или сотрудники из других групп, обладающие нужной экспертизой. Окончательный вариант утверждается руководством разработки платформы 1С: Предприятия.
- что входит, а что не входит в scope задачи
- какие мы представляем себе сценарии использования. Еще важнее понять, какие возможные сценарии мы не будем поддерживать
- как будут выглядеть пользовательские интерфейсы
- как будут выглядеть API для прикладного разработчика
- как новый механизм будет сочетаться с уже существующими
- что будет с безопасностью
- и т.д.
- Анализ проблемы и вариантов решения
- Описание выбранного решения
- Описания технических деталей реализации
- Единство используемых терминов. Если в одном месте Платформы в похожей ситуации был использован термин «записать», то использование «сохранить» должно быть очень серьёзно оправданным
- Единство подходов. Иногда ради упрощения изучения и единого опыта использования приходится повторять в новых задачах старые подходы, даже если очевидны их минусы
- Совместимость. В тех случаях, когда старое поведение сохранять нельзя, нужно все равно подумать о совместимости. Часто бывает, что прикладные решения могут быть завязаны на ошибку и резкое изменение повлечёт неработоспособность на стороне конечных пользователей. Поэтому, мы часто оставляем старое поведение «в режиме совместимости». Существующие конфигурации, запущенные на новом релизе платформы будут использовать «режим совместимости» до тех пор, пока их разработчиком не будет принято сознательное решение о его отключении.
Уроки и рецепты
- Ценность проектного документа, как любой документации, не всегда бывает очевидна. Для нас она в следующем:
- Во время проектирования помогает всем участникам быстро восстановить контекст обсуждения и быть уверенными, что принятые решения не будут забыты или искажены
- Позже, в сомнительных ситуациях, когда мы не уверены в правильности поведения, проектный документ помогает вспомнить само решение и мотивацию, которая стояла за его принятием.
- Проектный документ служит отправной точкой для пользовательской документации. Разработчику не нужно что-то писать с нуля или устно объяснять техническим писателям — уже есть готовая основа.
Обеспечение качества
Вообще, «качество» и «обеспечение качества» — очень широкие термины. Как минимум, можно выделить два процесса — верификацию и валидацию. Под верификацией обычно понимают соответствие поведения ПО спецификации и отсутствие других явных ошибок, а под валидацией — проверку на соответствие потребностям пользователя. В этом разделе речь пойдёт об обеспечении качества в смысле верификации.
Тестировщики получают доступ к задаче уже после ее вливания, но процесс обеспечения качества начинается намного раньше. В последнее время нам пришлось приложить значительные усилия по его совершенствованию, т.к. стало очевидно, что существовавшие механизмы стали недостаточно адекватны увеличившемуся объёму функционала и заметно возросшей сложности. Эти усилия, по отзывам партнёров о новой версии 8.3.6, как нам кажется, уже дали эффект, но много работы, конечно, ещё впереди.
Существующие механизмы обеспечения качества можно условно разделить на организационные и технологические. Начнём с последних.Тесты
Когда речь заходит о механизмах обеспечения качества, сразу на ум приходят тесты. Мы, конечно, их тоже используем, причём в нескольких вариантах:
Unit-тесты
На C++ мы пишем unit-тесты. Как уже упоминалось в предыдущей статье, мы используем модифицированные варианты Google Test и Google Mock. Например, типичный тест, проверяющий экранирование символа амперсанда ("&") при записи JSON, может выглядеть так:
Интеграционные тесты
Следующий уровень тестирования — интеграционные тесты, написанные на языке «1С:Предприятие». Именно они образуют основную часть наших тестов. Типичный набор тестов представляет собой отдельную информационную базу, хранящуюся в *.dt файле. Инфраструктура тестов загружает эту базу и вызывает в ней заранее известный метод, который вызывает уже отдельные тесты, написанные разработчиками, и форматирует их результаты так, чтобы их могла интерпретировать инфраструктура CI (Continuous Integration).
В данном случае, если результат записи разойдётся с эталоном, вылетит исключение, которое инфраструктура перехватит и интерпретирует как провал теста.
Наша система CI сама выполняет эти тесты под различные версии ОС и СУБД, включая 32- и 64-разрядные Windows и Linux, а из СУБД — MS SQL Server, Oracle, PostgreSQL, IBM DB2, а также нашу собственную файловую базу.
Пользовательские тестовые системы
Третий и самый громоздкий вид тестов — это т.н. «Пользовательские тестовые системы». Они применяются тогда, когда проверяемый сценарий выходит за пределы одной базы на 1С, например, при тестировании взаимодействия с внешними системами через веб-сервисы. Для каждой группы тестов выделяется одна или несколько виртуальных машин, на каждую из которых устанавливается специальная программа-агент. В остальном разработчик теста имеет полную свободу, ограниченную только требованием выдавать результат в виде файла в формате Google Test, который может быть прочитан CI.
Упомянутые выше тесты пишут сами разработчики платформы, на С++ или создавая небольшие конфигурации (прикладные решения), заточенные под тестирование конкретного функционала. Это является необходимым условием отсутствия ошибок, но не достаточным, особенно в такой системе как платформа 1С: Предприятие, где большая часть возможностей не являются прикладными (используемыми пользователем напрямую), а служат основой для построения прикладных программ. Поэтому существует ещё один эшелон тестирования: автоматизированные и ручные сценарные тесты на реальных прикладных решениях. К этой же группе можно отнести и нагрузочные тесты. Это интересная и большая тема, про которую мы планируем отдельную статью.
При этом все виды тестов выполняются на CI. В качестве сервера непрерывной интеграции используется Jenkins. Вот как он выглядит на момент написания статьи:
Для каждой конфигурации сборки(Windows x86 и x64, Linux x86 и x64) заведены свои задачи по сборке, которые запускаются параллельно на разных машинах. Сборка одной конфигурации занимает длительное время — даже на мощном оборудовании компиляция и линковка больших объёмов C++ представляет непростую задачу. Кроме того, создание пакетов под Linux (deb и rpm), как оказалось, занимает сопоставимое с компиляцией время.
Поэтому в течение дня работает «укороченная сборка», которая проверяет компилируемость под Windows x86 и Linux x64 и выполняет минимальный набор тестов, а каждую ночь работает регулярная сборка, собирающая все конфигурации и прогоняющая все тесты. Каждая собранная и проверенная ночная сборка помечается тэгом — так, чтобы разработчик, создавая ветку для задачи или вливая изменения из основной ветки, был уверен, что работает с компилирующейся и работоспособной копией. Сейчас мы работаем над тем, чтобы регулярная сборка запускалась чаще и включала больше тестов. Конечная цель этой работы — обнаружение ошибки тестами (если её можно обнаружить тестами) в течение не более двух часов после коммита, чтобы найденная ошибка была исправлена до конца рабочего дня. Такое время реакции резко повышает эффективность: во-первых, самому разработчику не нужно восстанавливать контекст, с которым он работал во время привнесения ошибки, во-вторых, меньше вероятность, что ошибка заблокирует чью-нибудь ещё работу.Статический и динамический анализ
- CppCheck
- PVS-Studio
- Встроенный в Microsoft Visual Studio
- обращений к неинициализированной памяти
- обращений к освобождённой памяти
- выходов за границы массива и т.д.
Организационные меры обеспечения качества
Помимо автоматических проверок, выполняемых машинами, мы стараемся встраивать обеспечение качества в ежедневный процесс разработки.
Наиболее широко применяемая практика для этого — peer code review. Как показывает наш опыт, постоянные инспекции кода не столько отлавливают конкретные ошибки (хотя и это периодически происходит), сколько предотвращают их появление за счёт обеспечения более читаемого и хорошо организованного кода, т.е. обеспечивают качество «в долгую».
Другие цели преследует ручная проверка работы друг друга программистами внутри группы — оказывается, даже поверхностное тестирование не погруженным в задачу человеком помогает выявить ошибки на раннем этапе, ещё до того, как задача влита в ствол.Eat your own dogfood
Но самым эффективным из всех организационных мер оказывается подход, который в Microsoft называется «eat your own dogfood», при котором разработчики продукта оказываются первыми его пользователями. В нашем случае «продуктом» оказывается наш таск-трекер (упомянутая выше «База задач»), с которой разработчик работает в течение дня. Каждый день эта конфигурация переводится на последнюю собранную на CI версию платформы, и все недочеты и недостатки сразу сказываются на их авторах.
Хочется подчеркнуть, что «База задач» — серьёзная информационная система, хранящая информацию о десятках тысяч задач и ошибок, а число пользователей превышает сотню. Это не сравнимо с самыми крупными внедрениями 1С: Предприятия, но вполне сопоставимо с фирмой среднего размера. Конечно, не все механизмы можно проверить таким способом (например, никак не задействована бухгалтерская подсистема), но для того, чтобы увеличить покрытие проверяемого функционала, есть договоренность, что разные группы разработчиков используют разные способы подключения, например, кто-то использует Web-клиент, кто-то тонкий клиент на Windows, а кто-то на Linux. Кроме того, используется несколько экземпляров сервера базы задач, работающие в разных конфигурациях (разные версии, разные ОС и т.д.), которые синхронизируются между собой, используя входящие в платформу механизмы.
Помимо Базы задач есть и другие «подопытные» базы, но менее функциональные и менее нагруженные.Выученные уроки
- В таком большом и массово используемом продукте дешевле написать тест, чем не написать. Если в функциональности есть ошибка и она будет пропущена — затраты конечных пользователей, партнеров, службы поддержки и даже одного отдела разработки, связанные с воспроизведением, исправлением и последующей проверкой ошибки будут куда больше.
- Даже если написание автоматических тестов затруднительно, можно попросить разработчика подготовить формализованное описание ручных тестов. Прочитав его, можно будет найти лакуны в том, как разработчик проверял своё детище, а значит, и потенциальные ошибки.
- Создание инфраструктуры для CI и тестов — дело затратное и по финансам, и по времени. Особенно, если приходится это делать для уже зрелого проекта. Поэтому начинайте как можно раньше!
И ещё один вывод, который не следует прямо из статей, но послужит анонсом следующих: самое лучшее тестирование фреймворка — это тестирование построенных на нем прикладных приложений. Но о том, как мы тестируем Платформу с применением прикладных решений, таких как «1С:Бухгалтерия», мы расскажем в одной из следующих статей.
Конфигурация «Комплексная автоматизация», редакция 2.0 может быть интересна для пользователей, имеющих опыт работы с комплексными конфигурациями на платформе «1С:Предприятие 7.7», и пользователей, работающих с отдельными информационными базами на основе конфигураций «Бухгалтерия предприятия», «Управление торговлей», «Зарплата и управление персоналом».
Как пишется 1С:ERP
Как мы из одного решения делаем четыре
- старая конфигурация от поставщика
- новая конфигурация от поставщика
- текущая конфигурация пользователя (старая конфигурация от поставщика плюс изменения, сделанные в ней пользователем)
степень, с которой продукт может быть использован определёнными пользователями при определённом контексте использования для достижения определённых целей с должной эффективностью, продуктивностью и удовлетворённостью
Мы стараемся писать приложение так, чтобы с ним было легко и удобно работать даже неискушенному пользователю.
Особенности разработки
- «Объекты УП, УТ, КА» — объекты, входящие во все прикладные решения: Управление Торговлей, Комплексная Автоматизация, Управление Предприятием (русскоязычное название ERP).
- «Объекты УП, КА» — объекты, относящиеся только к конфигурациям Комплексная Автоматизация и ERP.
- «Объекты УП» — объекты, относящиеся только к решению ERP
Цифры после запятой
Версия продукта ERP состоит из четырех чисел, разделенных точками. Например — 2.1.3.117.
- Первое число (редакция) в версии меняется крайне редко (например КА 1.х.х.х и КА 2.х.х.х разделяет почти 8 лет).
- Второе число (подредакция) меняется примерно раз в год. В версии с новой подредакцией выпускается новая функциональность. Выпуск таких версий часто приурочивается к началу календарного года, чтобы у пользователей было достаточно времени на «переезд» на новую версию.
- В версиях с новым третьим числом (релиз) развивается существующая функциональность; новый релиз выходит примерно раз в два-три месяца.
- Версии с обновленным четвертым числом (исправительные сборки) содержат в себе только исправления ошибок и обновления для соответствия текущему законодательству. Выходят каждые две недели.
- 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С:Предприятие. Платформенная команда просит команду разработки ERP (и других типовых конфигураций) использовать новую платформенную функциональность – например, интерфейс Такси, отказ от модальных окон, отказ синхронных вызовов и т.д.
- Рефакторинг, оптимизация архитектуры, улучшение юзабилити.
Поводом для рефакторинга (п.5) могут быть серьезные архитектурные изменения (например, пересмотр распоряжений на отгрузку, когда вместо накладных стали использоваться заказы).
Продукт СППР поставляется в составе ERP (но его можно купить и отдельно). Решение ERP может быть запущено в режиме интеграции с СППР; в этом случае на каждой форме будет кнопка «Открыть функциональную модель», при ее нажатии откроется описание функциональности формы в СППР.
Вот, что открывается – это модель рабочего места в IDEF0:
Можно и наоборот – изучать функциональную модель и из нее открывать формы рабочих мест. Такой режим можно использовать при изучении работы программы.
Важный момент – открывается не СППР, открывается форма внутри ERP, куда подгружаются данные из СППР. Т.е. интеграция «бесшовная» (пользователь ее не видит). Этот прием применяется при интеграции и с другими продуктами. Например, с 1С:Документооборот (можно работать не выходя из ERP с почтой, задачами, бизнес-процессами, которые работают в другой базе).Как мы разрабатываем ERP: 6 контрольных точек проекта
- Качественное проектирование, учет всевозможных сценариев, сопряжение со смежными блоками
- Сроки
- Качество архитектуры, пользовательского интерфейса
- Написание справки, оформление проекта, в т.ч. разработку функциональной модели
Точка 1. Открытие проекта
Тим-лид заводит технические проекты в СППР списком на релиз. В каждом проекте расписываются цели, указываются реализуемые требования. Список перед началом работы над релизом обсуждается с руководителем разработки. Собственно при открытии проекта совещаний не проводят – просто проект в СППР посылают на открытие.
Команда проекта приступает к разработке концепции.Точка 2. Согласование концепции
Для согласования концепции проводится онлайн или офлайн встреча, в которой участвуют ответственный за проект, тим-лид, руководитель разработки, вовлеченные в проект специалисты. Обычно к этому этапу у ответственного за проект готов «крупноблочный» концепт, который дошлифовывается в ходе встречи. Также обсуждаются (и прописываются в СППР) сценарии, описание пользовательского интерфейса. Если требование родилось из запроса партнеров или клиентов, то материалы проекта (концепции, сценарии, UI) могут быть отправлены партнеру/клиенту для оценки решения.
В процессе встречи согласуется трудоемкость создания прототипа (обычно создание прототипа занимает до 5 рабочих дней). Команда приступает к созданию прототипа.Точка 3. Согласование прототипов
- Согласование правильности описания проекта в СППР (в частности, отслеживается, что все задачи на предыдущих контрольных точках проекта выполнены).
- Какие новые объекты метаданных (справочники, документы и т.д.) будут добавляться в решение
- Какие изменения будут делаться в уже существующих объектах метаданных
- Согласование планов обменов данными с другими решениями(будут ли новые/измененные данные участвовать в обмене данными с другими приложениями, и если да – то как именно)
Точка 4. Согласование разработанного решения
Решение разработано, подготовлена презентация (в формате PowerPoint). Часто проводится очное совещание с «живым» показом разработанного решения.
Если проект публичный (опубликован в доступном партнерам списке планов на сайте 1С), то презентация выкладывается на партнерском форуме в разделе 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 – это конфигурация, в состав которой входит на настоящий момент 10 библиотек. Отключать совместимость можно только тогда, когда все библиотеки тоже это сделают.
Как мы тестируем 1С:ERP
- Состав ролей. Например, проверяется, что права на чтение всех констант включены в роль «Базовые права».
- Соответствие кода принятым стандартам. Для большого количества стандартов прикладной разработки (которых у нас несколько сотен) написаны процедуры анализа кода на предмет их соблюдения. Например, что не используются полные соединения в запросах, или, что правильно локализованы строки, которые отображаются в интерфейсе.
- Специфические проверки, связанные с особенностями разработки ERP
Например, проверка, что каждый прикладной объект входит только в одну из подсистем «Объекты УТ, КА, УП», «Объекты КА, УП» или «Объекты УП»
- Открытие всех форм
- Обмен данными с другими прикладными решениями (например, с 1С:Бухгалтерия Предприятия)
- Отражение проведенных документов в учете. Проверяется, что после проведения документа в эталонной базе результат отражения его в учете не поменялся.
- И др.
- Основное время — обновление данных в многопользовательском режиме. Прикладное решение готовит данные к обновлению в фоне, пользователи могут продолжать работать с системой, но быстродействие системы может быть снижено и часть функций могут работать ограниченно. Обычно обновление на новую версию проводят в выходные (когда активность пользователей минимальна).
- Минимальное время — обновление в монопольном режиме. Когда все данные подготовлены в фоновом режиме, наступает время изменения структуры БД. Для этого база данных переводится в монопольный режим, когда работа пользователей с системой невозможна. Скорость обновления крайне важна для наших пользователей.
Заключение
ERP – один из самых масштабных наших продуктов. Мы стараемся использовать в его разработке современные и передовые методики, а также создавать новые методики и инструменты, чтобы, с одной стороны, быстро его развивать, а с другой стороны — обеспечивать высокое качество разработанного решения.Рассмотрим типовые примеры, которые используются в организациях:
В самом простом случае один разработчик захватывает объект конфигурации, а остальные вынуждены ждать, пока этот объект освободится, иначе они не смогут внести изменений в этот объект. Делается это с той целью, чтобы не возникло конфликтов, когда два разработчика одновременно изменяют один и тот же объект конфигурации.
Естественно, это (захват объекта) может продолжаться достаточно долго, пока не завершится разработка, человек и того хуже, может уйти в отпуск, заболеть и забыть отпустить объект конфигурации, а время идет и задачу нужно решать. Если человек длительно отсутствует на рабочем месте, а объект все же нужен прямо сейчас, то выход один - отменять захват объекта администратором хранилища принудительно. В этом случае разработчик, захвативший объект, потеряет изменения, которые он вносил в объект. Мягко говоря, подход «так себе».
- Все говорят – все слушают (параллельный подход):
В более опытной команде разработчиков строится несколько иной подход, когда полностью чистая база данных подключается к хранилищу конфигурации и используется только для получения/помещения изменений, такая база используется только в режиме конфигуратора. Есть своим преимущества, более быстрая реструктуризация конфигурации БД в следствие отсутствия данных в таблицах БД, маленький объем самой базы. После получения изменений из хранилища все изменения сохраняется в файл конфигурации и уже сравнением/объединением (или полной загрузкой) конфигурации переносятся в свою тестовую копию базы с реальными данными, в которой как раз и ведется разработка. После завершения разработки конфигурация из тестовой БД снова сохраняется в файл и сравнением/объединением, с захватом объектов все переносится и помещается в основное хранилище конфигурации.
Преимущества такого подхода – никому не нужно ждать, пока захваченный объект в хранилище освободится, каждый разрабатывает свой функционал отдельно.
Недостатки – чем больше срок между получением файла хранилища конфигурации и переносом своих изменений обратно, тем больше различий в самом хранилище, которые туда уже поместили другие за время разработки, и тем сложнее переносить свои изменения в основное хранилище, особенно в тех местах где разработка пересекалась с другими коллегами в одних и тех же модулях, и объектах. Много галочек, много различий в объектах, изменилась сортировки и порою можно просидеть не один час реального времени, перенося все это, каждый объект нужно просмотреть и учесть всё, чтобы случайно не затереть помещенный ранее код коллег. Здесь принцип «кто успел, тот и съел», то есть кто поместил раньше тебя свои изменения в модуль, тому и проще, ведь это не ему придется сравнивать код двух модулей, объединять его в один и т.д. Если вспомнить, что бывают проекты по 2-3 месяца, то подобный подход при завершении проекта и переносе в основное хранилище покажется сущим адом.
Рассмотрим наиболее выгодный подход для разработчика при работе в крупной команде:
- Все говорят, но я никого не слушаю и делаю по-своему (параллельный подход с минимальным контролем).
Для более простого понимания принципа этой технологи, сначала я буду использовать надуманный пример, на основе не использующейся в реальной жизни конфигурации, код в конфигурации не будет нести какой-либо смысловой нагрузки – это будет просто «какой-то» текст, нам важно понять саму технологию, а не углубляться в понимание того, как правильно писать код или как решить ту или иную задачу с использованием тех или иных сущностей.
Имеем какую-то конфигурацию (собственную, отраслевую или от фирмы 1С не имеет значения).
В частном случае создана конфигурация из трех документов и одного общего модуля
Содержание общего модуля достаточно банальное
Для этой конфигурации создано хранилище.
Разработчик 1 будет в роли негодяя - напрямую подключился из своей тестовой базы к хранилищу и ведет разработку прямо там, мешая другим коллегам параллельно разрабатывать, захватывает объекты пока не закончит свою разработку.
Разработчик 2 устал постоянно ждать на захваченных объектах, начальник ругает, нужно делать работу, а не сидеть сложа руки. Он сохранил конфигурацию в файл и загрузил в свою тестовую базу. Ведет разработку там и не ждет Разработчика 1 или еще кого-либо. Позже перенесет свои наработки в хранилище пусть и с определёнными рисками.
Разработчик 3 пойдет по пути №2, но при этом не будет заботиться и переживать о контроле, он отдаст это механизмам 1С. Создаёт файл поставки от основного хранилища конфигурации. После чего этот файл поставки загружает в свою тестовую базу, поставив её на поддержку.
Загрузив файл поставки в свою тестовую базу, видит, что все объекты находятся на поддержке или, как говорят, «на замке»:
На этом этапе технология разветвленной разработки (п. 4. Разработка технических проектов) гласит - Правило «Объект поставщика редактируется с сохранением поддержки» нужно устанавливать только для тех объектов, которые изменяются при выполнении технического проекта. Правило нужно менять как можно более точечно – например, если изменения в проекте будут затрагивать только форму, то нужно изменить правило только для этой формы, а для объекта, которому эта форма принадлежит, нужно оставить правило «Объект поставщика, не редактируется».
На самом деле это только Ваше дело, устанавливать правило «Объект поставщика редактируется с сохранением поддержки» точечно или сразу для всей конфигурации целиком. Методологически правильно делать как гласят стандарты, но это долго и, по моему мнению, избыточно, т.к. при разработке проекта часто меняется много объектов сразу. В тот момент, когда потребовалось в процессе разработки поменять, к примеру, общий модуль или модуль объекта, которые ещё на поддержке, нужно открывать окно поддержки конфигурации, пользоваться неудобным поиском, визуально находить нужный объект метаданных, менять свойство снимая с поддержки и т.д. в то время как в голове содержится информация по разработке, и она может вылететь из головы из-за того, что ты отвлекся на лишние действия. Я по своему опыту сразу устанавливаю для всей конфигурации целиком правило «Объект поставщика редактируется с сохранением поддержки», это позволяет мне не снимать точечно в том числе с поддержки те метаданные, которые я изменю в процессе разработки, но в хранилище конфигурации они «на замке» от основного поставщика конфигурации, там я как раз их сниму в процессе переноса и помещения в хранилище точечно, если уже потребуется!
Открываем настройку поддержки конфигурации
И включаем возможность изменения
Устанавливаем правила поддержки
И особо ни о чем не задумываясь начинаем разработку своего проекта или решение своих задач в тестовой базе.
Для примера мы поменяем общий модуль «ОбщийМодульДляВсегоВызовСервера» и «ДокументРазработчика3», добавим свой общий модуль и справочник.
Процедуру, которая имела вид
Мы преобразовали к такому:
В результате чего конфигурация принимает примерно такой вид:
Аналогично поступят Разработчик 1 и Разработчик 2, мы опустим этот момент, скажем лишь то, что Разработчик 1 без особых переживаний сделает это прямиком в хранилище конфигурации с захватом объектов, Разработчик 2 сохранит свой файл конфигурации и перенесет все сравнением/объединением, потратив какое-то количество времени на все это. И наступает наша очередь (мы самые последние) переносить свой проект в хранилище.
За время нашей разработки, открыв хранилище конфигурации, получив все объекты, мы видим, что конфигурация изрядно изменилась:
Но это нас не останавливает и даже не пугает, ведь мы на поддержке. Перед переносом всех изменений в основное хранилище Разработчик 3 повторяет процедуру создания файла поставки конфигурации от основного хранилища и обновляет свою тестовую базу.
Обновление базы из хранилища:
Видим следующую картину обновления
Невооруженным взглядом видно, что изменений достаточно много. Но мы все отдадим на откуп механизмам обновления 1С.
Снимаем отметку в корне конфигурации, тем самым сняв отметки со всех объектов метаданных
И устанавливаем фильтр в режим «Показывать отличия новой конфигурации поставщика от старой конфигурации поставщика».
В данном режиме возвращаем отметку в корне конфигурации, отметив все объекты в этом режиме
И переключаем фильтр в режим «Показывать только дважды измененные свойства»
В данном режиме мы видим, что совместно с другими разработчиками мы изменяли только один общий модуль, объединение которого мы настроим вручную
В данном случае я вношу результирующие изменения, просто добавив их в конкретную процедуру
И на этом все! Если режим «Показывать только дважды измененные свойства» вообще не показал ничего, значит, мест, где пересекалась разработка с другими разработчиками, нет вообще и переживать тем более не о чем!
Устанавливаем правила поддержки для новых объектов, как и ранее, на свое усмотрение:
Получив результирующую конфигурацию, мы имеем в своей базе ни что иное, как "Основная конфигурация хранилища с последними изменениями всех разработчиков + все наши доработки", сохраняем её в файл и без особого труда переносим всё простым сравнением/объединением в основное хранилище конфигурации.
Там (в основном хранилище конфигурации при сравнении/объединении) мы увидим вот такую приятную картину – мы видим только те изменения, которые вносили мы:
Объединяем с хранилищем и понимаем, что мы сократили огромное количество времени и сил.
Таким способом (см. «Обновление базы из хранилища») можно обновлять конфигурацию своей тестовой базы в любой момент времени, перенося к себе изменения, сделанные своими коллегами и уже помещенными в хранилище. Это полезно при длительной разработке какого-то проекта в своей базе, вы переносите чужие изменения и сразу адаптируете свой код под новые условия.
Углубившись в проблему, мы поняли, что в большей степени каждый сам для себя выбирает пути в коллективной разработке. Но кто-то не ищет лёгких путей, а ходит «по натоптанной». Надеюсь материал был Вам полезен, и вы примете на вооружение эту полезную и нужную технологию. Удачной и, главное, легкой вам коллективной разработки. Спасибо за прочтение статьи.
UPD 08.06.2021
Рекомендация - для больших конфигураций все же лучше снимать объекты своей базы с поддержки "точечно", так трехстороннее сравнение при обновлении конфигурации из хранилища происходит в несколько раз быстрее и экономится приличное количество времени, очень хорошо описал эту проблему коллега в комментарии к данной статье "чем больше размеров конфигурация, тем более заметно вы будете это ощущать по времени её обновление".
Еще одна из хороших рекомендаций которая прозвучала в комментариях к статье - если в вашей организации практикуют захват объектов в хранилище на все время изменения, вместо технологии разветвленной разработки, то перед тем как создавать из основного хранилища файл поставки для последующего обновления им локальной базы разработки - в основном хранилище следует захватить доработанные вами объекты заранее, если это конечно возможно. Это нужно, чтобы к моменту переноса доработок на основное хранилище ваши доработанные объекты были доступны для изменения и их не смогли захватить другие разработчики под свои нужды пока вы ведете работу в своей базе.
Многие рутинные операции при работе над проектом 1С можно автоматизировать – довериться готовым инструментам и уменьшить количество нажимаемых кнопок. О том, как с помощью готового шаблона проекта настроить окружение для разработки на митапе «DevOps в 1С» рассказал технический директор Инфостарта Артур Аюханов.
Определение DevOps
Я выбрал из Википедии несколько цитат с определением того, что такое DevOps.
Первое и самое важное – это взаимозависимость процессов создания продукта и эксплуатации ПО. Очень важно, чтобы при разработке продукта учитывалось, как в дальнейшем этот продукт будет эксплуатироваться, как он будет раскатываться, как будут накатываться фиксы, как будут собираться тикеты, обратная связь и т.д. Это нужно сразу продумывать, а не работать в отдельных изолированных командах – отдельно команда продукта, отдельно команда эксплуатации.
Мне очень нравится цитата «Культура создания ПО в команде». В DevOps очень важно пропагандировать, создавать культуру – ведь, с одной стороны, мы все айтишники, инженеры, но с другой стороны, мы художники. Мы творим, создаем новое. Мы не просто ремесленники. Слово «Культура» очень важно. Мы увеличиваем свои знания, обмениваемся знаниями, проводим какие-то культурные мероприятия, такие как митапы и конференции Инфостарта.
Также очень важно, чтобы у нас во всех процессах работы с продуктом использовались единые стандарты, инструменты, единое окружение. Например, чтобы команда эксплуатации использовала те же инструменты, которыми пользуются разработчики – чтобы в обеих командах при развертывании баз 1С использовался rac, ras, еще какие-то инструменты. Чтобы соблюдались единые инструменты разработки – конфигуратор или EDT, и т.д.
И немаловажный момент для DevOps – системы автоматизации сборки и выпуска (CI/CD/Jenkins/GitLab/Azure и т.д.) должны быть доступны соответствующим лицам с правильными ролями. И могли использоваться на разных этапах DevOps.
На картинке знаменитый знак бесконечности DevOps – планирование, кодирование, сборка, тестирование, потом выпуск релиза, операционная деятельность и мониторинг.
Весь мой доклад будут пронизывать некие идеи или мантры.
На слайде DevOps присутствует первая мантра «Все есть код» – она означает, что все действия, которые мы выполняем при разработке, при эксплуатации продуктов, нужно фиксировать. Это не должны быть действия, которые мы каждый раз интерактивно “закнопываем”. Все рутинные операции, которые выполняет разработчик или эксплуататор, должны выполняться в автоматическом режиме.
Например, разработчик нажимает кнопку или запускает одну простую команду, и у него выполняется сборка его проекта или собирается/обновляется информационная база. Или эксплуататор нажимает кнопку и происходит автоматическое развертывание релиза на продуктовую базу – выгоняются пользователи и т.д.
В своем выступлении я затрону шесть из восьми этапов DevOps. На «знаке бесконечности» они расположены слева и в середине – это:
Система 1С:Предприятие 8.3 – специализированная среда, которая служит для разработки экономического и бухгалтерского программного обеспечения, которое в свою очередь предназначено для автоматизации деятельности различный организаций. Большой процент функционала уже заложен в самой этой системе – технологической платформе. Поэтому в первой части статьи мы поговорим о среде разработки, а во второй – о том, как происходит разработка конфигурации 1С на этой платформе.
Среда разработки и базовые механизмы
Всю систему 1С можно поделить на две большие части: платформу и конфигурацию. Платформа представляет собой «framework», средство для разработки (своих решений или настройки типовых решений, продаваемых 1С), а также является средой исполнения программ 1С:Предприятие. Конфигурации – прикладные решения, разработанные на технологической платформе 1С:Предприятие, которые служат для автоматизации определенной области деятельности. Такие решения выпускает фирма 1С и ее партнеры. Прикладные решения в большинстве своем «открытые», что дает возможность любому специалисту, имеющему соответствующие знания, настраивать программу «под себя», то есть адаптировать под нужды конкретного предприятия и конкретной формы деятельности. При этом дополнительное ПО не нужно, все средства разработки есть в программном комплексе. Такая особенность системы называется «Конфигурируемостью».
Принципы работы системы 1С:Предприятие 8.3
Перечислим основные и показательные:
Два режима работы с информационной базой: файловый и клиент-серверный
В файловом режиме работы вся информационная база (конфигурация, данные, движения по регистрам, настройки пользователей) хранится в одном файле. Данный файл (1Cv8.1CD) обычно находится на общем сетевом ресурсе, доступном всем пользователям 1С. Настраивать этот вариант очень легко, и он подойдет для небольшой компании, где не более 5 пользователей, с небольшим документооборотом. При исполнении конфигурации в файловом режиме система «имитирует» наличие сервера на компьютере пользователя. То есть, программируя в файловой базе, все равно следует придерживаться клиент-серверного механизма разработки.
Для больших же компаний целесообразно использовать серверный вариант хранения в реляционных базах данных, но такой режим работы потребует усилий по установке и администрированию. Этот вариант реализован на механизме трехуровневой архитектуры, он использует СУБД и кластер серверов 1С, которые успешно решают проблему надежности, быстродействия и производительности.
Рис.1 Трехуровневая схема
Клиентское приложение отправляет запрос к кластеру серверов, его принимает менеджер кластера (центральный сервер). В случае необходимости, распределяя нагрузку между серверами, центральный кластер переадресует запрос дополнительным серверам. Затем рабочий сервер-кластер обращается к СУБД для получения необходимых данных. СУБД обрабатывает запрос и возвращает массив данных рабочему серверу, который передает их клиентскому приложению.
Система позволяет осуществлять переход из одного режима работы на другой.
Рис.2 Система позволяет осуществлять переход из одного режима работы на другой
Конфигурация, написанная для файловой базы данных, будет работать и на серверной базе, но в некоторых случаях может потребоваться адаптация некоторых алгоритмов.
Клиентские приложения
У платформы 1С:Предприятие 8.3 есть несколько клиентских приложений. Их основное предназначение — организация интерфейса, взаимодействие с пользователем, они отображают данные и дают пользователю возможность вносить изменения.
Толстый клиент. Этот клиент может выполнять практически всю функциональность, но потребует широкополосных каналов связи. Такой вариант работы позволяет разрабатывать и отлаживать прикладные решения. Клиент по собственному протоколу передачи данных напрямую обращается к базе данных (файловый вариант базы) или к кластеру серверов (клиент-серверный вариант), который в свою очередь обращается к СУБД или сразу дает ответ.
Ниже представлена архитектура приложений для файлового и клиент-серверного вариантов работы.
Рис.3 Архитектура приложений для файлового варианта работы
Рис.4 Архитектура приложений для клиент-серверного варианта работы
Объектно-реляционная модель базы данных
Само прикладное решение в системе 1С:Предприятие 8.3 – это совокупность шаблонов, каждый из которых прототипирован. Отдельный такой прототип решает свою собственную задачу. Справочники, документы, различные регистры — все это прототипы системы. То есть не абстрактные, а вполне конкретные сущности, присутствующие в реальной жизни автоматизируемой организации. В 1С:Предприятие эти прототипы называются «объектами конфигурации». Все они представлены в так называемом «дереве конфигурации».
Рис.5 Объектно-реляционная модель базы данных
Разработчику нужно выбрать лишь подходящий прототип, создать объект в рамках этого прототипа и обеспечить его общение с другими объектами. Напрямую работать с базой данных нельзя. Взаимодействие осуществляется посредством объектов.
Внутренний язык программирования
Он схож с таким языком, как Visual Basic. Особенности языка:
- Мягкая типизация. Тип переменной не указывается, переменная может поменять тип в процессе работы;
- Переменные можно не объявлять заранее (неявный способ объявления переменных);
- В одном модуле могут находиться процедуры или функции, некоторые из которых выполняются на клиенте, а некоторые – только на сервере. Потом препроцессор 1С «разрежет» модули на части, вырежет ненужное, соединит и отдаст компилятору;
- Регистр для кода не имеет значения;
- Язык доступен в нескольких вариантах, но в основном все конфигурации написаны на русском. При желании можно комбинировать русский и английский язык, но читаемость кода ухудшится.
Система предоставляет различные механизмы для разработки конфигурации
Основные и наиболее интересные из них:
Собственный язык запросов
Запросы представляют собой мощный инструмент для получения данных из базы данных в удобном виде. На выбранные данные посредством языка запросов можно наложить фильтры, сгруппировать, отсортировать, но изменять данные при их помощи нельзя. Запросы являются основой для построения отчетов. Синтаксис языка запросов 1С похож на SQL, так как основан на нем. Существует визуальный помощник для составления текста запроса – «Конструктор запроса». Текст запроса можно написать вручную, но нередко он может состоять из нескольких сотен строк, поэтому визуальное представление текста запроса намного облегчает эту задачу. Конструктор запроса выглядит следующим образом:
Рис.7 Собственный язык запросов
Также для отладки запросов предусмотрен специальный инструмент — «консоль запросов». Сама отладка происходит следующим образом: разработчик в конфигураторе пишет текст запроса, далее пишет программный код, который будет обрабатывать результат этого запроса, затем переключается в режим предприятия, запускает полученную обработку, анализирует результат запроса. Если обнаруживается ошибка, разработчик переключается в режим конфигуратора и вносит исправления в текст запроса и заново переключается в режим предприятие для повторной проверки запроса. Такое переключение не очень удобно. А консоль запросов позволяет проверять текст запроса сразу в режиме предприятия на реальных данных. Из консоли запросов можно открыть конструктор запросов.
Система компоновки данных (СКД)
Это инструмент, предназначенный для создания отчетов. Разработчик при помощи данного средства декларативно описывает поведение отчета, при этом программного описания зачастую не требуется. Рутинную работу запроса к базе данных, вывод данных в макет и т.д. сделает СКД. Еще одна важная возможность СКД — различные варианты отчетов. На основании одного и того же источника данных можно получить несколько вариантов, как именно эти данные будут представлены пользователю.
СКД используется не только для построения отчетов, а также для построения динамических списков.
Мобильная платформа
Данная технология позволяет создавать приложения для мобильных устройств под управлением операционных систем Android, iOS, Windows Phone. Мобильное приложение, установленное на устройстве, представляет собой комбинацию мобильной платформы и мобильной конфигурации. Информационная база на мобильном устройстве содержит аналог файловой базы данных (для хранения данных, с которыми работает пользователь) и мобильное приложение (программный код, исполняющийся на мобильном устройстве).
Рис.8 Мобильная платформа
Для передачи приложения на мобильное устройство нужно опубликовать на веб-сервере xml-файл, который представляет собой готовое приложение. Мобильная платформа с мобильного устройства подключается к этому веб-серверу, забирает этот xml-файл и устанавливает его у себя.
Рис.9 Настройки
Система взаимодействий
Процесс разработки
Что же представляет собой профессиональная разработка на 1С:Предприятие 8.3? Для начала определимся, что разработка – это не синоним программирования. Проектирование и конструирование системы – интересный, творческий процесс, который включает в себя множество аспектов. Само написание программного кода – один из инструментов разработки и не является ключевым.
Везде, где есть 1С:Предприятие, есть технологическая платформа. Из-за этого все программы 1С имеют одинаковую логику и методику проектирования. Система скрывает от разработчика многие скучные, однообразные действия, то есть всю «низкоуровневую» работу берет на себя. Любая программа собирается из готовых шаблонов. Разработчик описывает структуру базы данных из этих шаблонов, выбирая нужный, уже существующий в системе. Можно провести аналогию между прототипами в 1С и классами в ООП, но свой собственный прототип (класс) создать нельзя.
Платформа имеет ограниченный набор шаблонов, имеющих свое предназначение и модель взаимодействия между собой. Разработчику достаточно добавить в информационную базу нужные объекты конфигурации, и система сама обеспечит правильную работу добавленных объектов. Конечно, функционирование объектов будет сильно ограничено. Но встроенный язык и язык запросов помогут задать специфичное поведение объектов. С их помощью можно описывать собственные алгоритмы общения объектов между собой или собственные алгоритмы обработки данных.
Важным этапом проектирования является разработка интерфейса. Новейший интерфейс в системе 1С:Предприятие 8.3 носит название «Такси». Особенность его в том, что разработчик декларативно описывает его поведение, и на основе этого описания платформа формирует пользовательский интерфейс. При разработке прикладного решения важную роль играет функциональность, но для достижения коммерческого успеха не менее важен дружелюбный интерфейс или эргономичность. Все эти задачи (функциональность, эргономичность) успешно выполняет управляемый интерфейс.
Четкое разграничение системы на технологическую платформу и прикладные решения имеет ряд преимуществ: низкая стоимость и высокая скорость создания и внедрения программ 1С. Платформа позволяет специалистам не углубляться в большинство технологических деталей, а сконцентрироваться на прикладной задаче, что увеличивает скорость разработки и уменьшает стоимость готового решения. Также в подавляющем большинстве случаев пользователи работают в типовых конфигурациях (1С:Бухгалтерия, 1С:Управление торговлей, 1С:Зарплата и управление персоналом, 1С:Управление небольшой фирмой), поэтому разработчику редко приходится писать что-то свое «с нуля». В основном процесс разработки – это доработка готового прикладного решения разработчиком, не участвовавшем в его создании, что также является преимуществом разработки в данной системе.
Разработка в системе 1С:Предприятие 8.3 – процесс многогранный, в большей мере требующий навыков аналитики и понимания бизнес-процессов предприятия. А среда разработки – очень мощный и гибкий инструмент, который предоставляет разработчику множество возможностей для успешной и быстрой автоматизации деятельности предприятия. Аналогов данной системы в настоящий момент в России нет. И программная линейка 1С является стандартом для работы различных организаций разных направлений бизнеса. Наша компания предоставляет услуги сопровождения, внедрения и доработки 1С в Москве. Если у вас остались вопросы, свяжитесь с ним, мы с радостью вам поможем.
Читайте также: