Добрый день, коллеги!
В данный момент наша команда работает в хранилище + git (gitsync), так же выгрузка epf \ cfe туда же в git (vanessa-runner), платформа 8.3.11
Хочется убрать прокладку в виде хранилища вообще и перейти на git-flow в итоге, при этом не потерять юзабилити как при работе с хранилищем и по максимуму автоматизировать всю движуху с GIT. Конечно я почитал статьи посвященные работе git + 1C, но практически все предпологают работу с хранилищем -> GIT, ответа для себя я так и не нанешл в итоге.
Основная мотивация отказа: желание организовать более жеский контроль за кодом, в том плане, что есть некоторые разработчики, для которых хочется убрать возможность делать коммиты напрямую в девелоп ветку, только через пулл реквесты.
В целом картина мира прояснилась немного при просмотре доков по CLI 1С, но есть сомнения по поводу автоматизации доставки кода в девелоперскую ИБ из GIT'а, т.к. конфа у нас на поддержке, то тупо загрузку из файлов не выполнить, сразу выходит ошибка, что есть объекты, редактирование которых запрещено, но в целом можно выполнять загрузку только измененных файлов, предварительно получив список через команды того же GIT'а, но в тоже время как быть если например я удалил модуль? Как я понял средств для удаления объектов через CLI у 1С нет.
С другой стороны можно доставлять код через CF, но тут есть другая проблема, все это делается очень долго, компиляция в CF, потом заливка CF в конфу и тд, на SSD уходит минут 5, хотелось бы побыстрее, да и расточительство это ждать пока скопилится полный CF когда изменилось всего 2 строчки кода, так же переход с ветки на ветку будет занимать те же 5 минут.
В общем, хотелось бы почитать Ваш опыт \ советы как сделать этот процесс более продуктивным.
В данный момент наша команда работает в хранилище + git (gitsync), так же выгрузка epf \ cfe туда же в git (vanessa-runner), платформа 8.3.11
Хочется убрать прокладку в виде хранилища вообще и перейти на git-flow в итоге, при этом не потерять юзабилити как при работе с хранилищем и по максимуму автоматизировать всю движуху с GIT. Конечно я почитал статьи посвященные работе git + 1C, но практически все предпологают работу с хранилищем -> GIT, ответа для себя я так и не нанешл в итоге.
Основная мотивация отказа: желание организовать более жеский контроль за кодом, в том плане, что есть некоторые разработчики, для которых хочется убрать возможность делать коммиты напрямую в девелоп ветку, только через пулл реквесты.
В целом картина мира прояснилась немного при просмотре доков по CLI 1С, но есть сомнения по поводу автоматизации доставки кода в девелоперскую ИБ из GIT'а, т.к. конфа у нас на поддержке, то тупо загрузку из файлов не выполнить, сразу выходит ошибка, что есть объекты, редактирование которых запрещено, но в целом можно выполнять загрузку только измененных файлов, предварительно получив список через команды того же GIT'а, но в тоже время как быть если например я удалил модуль? Как я понял средств для удаления объектов через CLI у 1С нет.
С другой стороны можно доставлять код через CF, но тут есть другая проблема, все это делается очень долго, компиляция в CF, потом заливка CF в конфу и тд, на SSD уходит минут 5, хотелось бы побыстрее, да и расточительство это ждать пока скопилится полный CF когда изменилось всего 2 строчки кода, так же переход с ветки на ветку будет занимать те же 5 минут.
В общем, хотелось бы почитать Ваш опыт \ советы как сделать этот процесс более продуктивным.
По теме из базы знаний
- Практика применения DevOps. Автоматизация процессов разработки, инструментарий и работа с Git
- Добавляем в Конвертацию данных 2.1 средства для работы с GIT
- Распаковка файлов обработок/отчетов при работе с GIT precommit
- Работа с GitLab API
- Как упростить подготовку конфигурации для работы с Git и SonarQube
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Как насчет такого варината: В момент начала работы над фичей делается git checkout -b feature-xxx, далее создается НОВАЯ пустая ИБ, в нее заливается конфигурация из локального репозитория и в ней ведется разработка. На ней же проводятся тесты и прочее. После завершения работы Конфигурация разрабатываемой ИБ выгружается в локальный репозиторий, далее в зависимости от прав разработчика делается либо push в origin/develop либо pull request, и в случае успешного принятия удалается и ветка и ИБ с ней связанная.
А релизы выпускаются с установленной периодичностью из мастер ветки обычной компиляцией CF\CFU
А релизы выпускаются с установленной периодичностью из мастер ветки обычной компиляцией CF\CFU
(2) С релизами и так понятно, как раз CF и хотел делать, а вот с постоянным созданием новой ИБ тут мне не нравиться то, что нужно тратить много времени на все это дело т.к. выходит вот как:
5 минут зыгрузки метаданных
~10 мин первоночального заполнения ИБ
0 - 10 минут загрузки нужных бизнес данных в ИБ для разработки фичи
Итого 15 - 25 минут на инициализацию ИБ, с учетом того, что разрабочик может делать по моим наблюдением до 3х фич в день (не особо больших), то он теряет > 1 часа времени только на ожидании, в общем как сказал выше многовато выходит.
Думаю посмотреть как сделано в EDT, благо их плагины с легкостью поддаются декомпиляции и ничего там не обфусцировано и тд, они же как то решили эти проблемы обмена ИБ <=> XML \ BSL файлам.
5 минут зыгрузки метаданных
~10 мин первоночального заполнения ИБ
0 - 10 минут загрузки нужных бизнес данных в ИБ для разработки фичи
Итого 15 - 25 минут на инициализацию ИБ, с учетом того, что разрабочик может делать по моим наблюдением до 3х фич в день (не особо больших), то он теряет > 1 часа времени только на ожидании, в общем как сказал выше многовато выходит.
Думаю посмотреть как сделано в EDT, благо их плагины с легкостью поддаются декомпиляции и ничего там не обфусцировано и тд, они же как то решили эти проблемы обмена ИБ <=> XML \ BSL файлам.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот