Особенности непрерывной групповой разработки на эксплуатируемой базе

Если проектная команда внедряет крупные блоки и значительно дорабатывает конфигурацию, наиболее безопасным был бы следующий способ: тщательно протестировать вносимые изменения на обособленной базе данных, согласовать их с заказчиком и перенести в финальном виде на рабочую базу. Таким образом, конечные пользователи получат готовый к работе программный продукт. Риск возникновения ошибок при этом будет минимальным.

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

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

• организация работ,
• разработка,
• тестирование,
• исправление ошибок.

Чтобы обеспечить непрерывную работу, можем разделить структуру баз на несколько звеньев в соответствии с этапами внедрения доработок:

1. Частные базы разработчиков, обязательно подключенные к общему хранилищу разработки. В условиях быстрой разработки и множественных перемещений неподключенная база станет неактуальной уже к концу дня. В ней нет данных о захвате объекта разработчиком, а потому могут возникать конфликты доработок;
2. Единая база для тестирования, куда регулярно с выбранной периодичностью выгружаем конфигурацию разработки, а также загружаем данные из рабочей базы, чтобы иметь актуальные данные для тестирования срочных исправлений и доработок. Эта база подключена к своему хранилищу, и все изменения в ней фиксируются в системе хранения версий;
3. Конечная база – продуктив, в которую с выбранной периодичностью попадают проверенные и одобренные доработки. Ее необязательно подключать к хранилищу, так как внесение доработок на этом этапе — вынужденная мера, которая вызовет полную остановку рабочего процесса. Динамическое обновление рабочей базы недопустимо ни при каких условиях.

Базы 2 и 3 являются обязательными для регулярного снятия копий на момент до загрузки доработок.

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

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

Если внедрение осуществляется группой разработчиков, необходимо использовать систему контроля версий. Выбор конкретной системы зависит от размера группы разработки, предпочтений команды или даже нескольких команд, требований заказчика и условий работы. Наиболее распространенный вариант — использование хранилища конфигурации. Данный инструмент упоминали в предыдущем разделе. Преимущество: простота использования. Недостаток: блокирует объекты, открытые другими разработчиками. Это может тормозить работу в условиях интенсивного потока задач.

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

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

Частной проблемой может стать доработка внешних отчетов и обработок. Если они не входят в состав конфигурации, то и находятся вне зоны видимости хранилища. В случае, если несколько программистов вынуждены одновременно работать над одним объектом, потребуется дополнительно сверить версии на наличие внесенных за время работы изменений и свести их воедино. Этого можно избежать, если закрепить объекты за конкретными разработчиками.

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

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

Этап тестирования можно условно разделить на два процесса.

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

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

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

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

Однако мы не можем полностью исключить попадание непредвиденных ошибок в рабочую базу.

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

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

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