User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive
 

Доброго времени суток. Сегодня хочу Вам рассказать зачем и в каких случаях необходимо создавать хранилище конфигурации.

Основная причина появления такой чудесной вещи в восьмой платформе, это трудности связанные с совместной разработкой конфигураций, которые мы видели в 7.7. Представьте себе, что разработкой занимаются более одного человека. Как мы налаживали процесс разработки в старой версии 1С 7.7?

Создавалась база, в которой хранилась самая актуальная структура метаданных, назовем её главной. Когда один из разработчиков брался за очередной кусок разработки, он брал актуальный файл конфигурации (в 7.7 это был md файл), накатывал его через сравнить объединить на свою копию базы, вел там разработку, отлаживался. Потом заходил в главную базу и через сравнить объединить накатывал туда свои доработки. При этом ему необходимо было держать в голове список объектов, которые он изменял, ведь пока он разрабатывал, его коллега делал свою часть разработки и возможно уже выложил свои изменения, и если на это не обратить внимания, то Вы затрете работу своего коллеги. Далее необходимо всех оповестить: "ребята я выложил свои доработки и изменил такие-то объекты", если этого не сделать, то "ребята" тоже залезут в эти места и будучи уверенными, что у них актуальная версия объекта затрут Вашу работу. Возникает коллизия разработчиков, они начинают мешать друг другу, тратить много времени на "разбор полетов", ругаться... и проект начинает тормозиться. Конечно, любую проблему можно решить, мы ведь цивилизованные люди))

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

Однако, когда разработчиков все же было несколько, такой режим работы пораждал ведения всяких журналов (на бумаге, в EXCELе, на большой доске в кабинете...), в котором было бы видно, кто сейчас с каким объектом работает, когда вносил измененя. Так же, зачастую, код начинал пестрить кучей комментариев, в которых указывалось кто и когда внес эти строки. Представляете, открываете модуль, лезете в нужную процедуру и начинаете в ней разбираться, а там комментариев больше чем кода в разы, и комменты не столь смысловые, сколько сплошные даты время и фамилии, они вложены друг в друга и ничерта в этом не понять.

Так вот, чтобы решить эту проблему в восьмой платформе и придумали такую вещь, как хранилище конфигураций. По сути своей, это отдельная БД, в которой ведется история версий объектов метаданных. У этой БД есть свой список пользователей - список пользователей хранилища конфигураций. Она хранит информацию, о том, кто с каким объектом сейчас рабоатет. И Самое главное, предотвращает коллизии изменения одного и того же объекта разными разработчиками, путем блокировки объектов.

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

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

Третий бонус, который иногда не столь очевиден, это хранение истории разработки. Очень часто, когда разработка ведется вяло, от случая к случаю, в режиме тех.поддержки, но многими разработчиками, наступает момент, когда программист получив задачу от одного из пользователей что-то разрабатывает. Допустим, он разрабатывает не в рабочей базе, а в локаьной копии, все отладил, протестировал, все хорошо. Выложил доработку в рабочую базу и пользователь стал счастлив. Но предприятие крупное, база большая и сложная (например УПП), пользователей много, программистов в тех.поддержки тоже несколько. И тут сосвсем другой пользователь, из совсем другого отдела начинат кричать, что программа не работает. Оказывается доработка помешала корректной работе совсем другого блока. Заявка о неверной работе пришла к другому программисту, не автору этой доработки. Ему нужно срочно выяснить в подробностях, как было до и как стало после. На словах ему сказали, что был изменен такой-то документ или справочник, но для анализа часто бывает необходимо получить базу по сотоянию до и после одновременно и отладится в них. Тут программист ищет копию, выгруженную накануне разработок и разворчивает её локально, отлаживается в ней, выясняет причину поломки другого блока, вносит коррективы, наступает счастье всех и вся.

Это идеально, на практике, кто что доработал ранее выяснить не всегда получается, и программист ломает мозг, отлаживаясь в рабочей базе. Найдя затык он с большой вероятностью убьёт предыдущие доработки и все пошло по новой, круг замкнулся. Если даже автор доработок сознался, он не всегда точно может назвать дату выкладывания доработок и приходится поднимать несколько копий, прежед чем найдется та самая "на кануне". А каждая база разворачивается по два часа, вот и улетел рабочий день в пустую.

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

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

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

Авторизуйтесь пожалуйста