Transcription
Всем привет. Ээ. Сегодня я расскажу вам про то, как подружить 1С системой версии хранения, системой хранения версий Git и ээ системой проверки Sonar. Как мы видим на картинке, они вполне себе могут дружить, водить хороводы. А краткий ликбез. Что за зверь такой Git? Как я сказал ранее, это система хранения версий. Она у нас имеет двухступенчатую, ну, состоит из двух ступеней: удалённый репозиторий, локальный, локальный индекс. То есть, непосредственно, в чём особенность. Мы устанавливаем. В нашем примере мы сегодня будем разбирать. У нас есть разные версии GitLab, GitHub. Мы будем работать с GitLab. Он у нас уже развёрнут благодаря IT-отделу. Вот. При работе с Git нам необходимо локально развернуть сам Git. Установить на сервере, как я сказал, он уже у нас установлен. Так, небольшой спойлер. Собственно, по адресу `fcr.com.ru` у нас уже есть какие-то проекты. Это у нас удалённый репозиторий, где хранятся все наши проекты. И локальный репозиторий я покажу чуть позже.
Так, теория. Какие особенности Git? Git можно представить, ну, собственно, я так понимаю, изначально разработчики его представляли как какое-то там витиеватое дерево либо сакуру. То есть, дело в том, что у нас как есть корневой, ну, вот наша стандартная система разработки. У нас есть рабочая база, есть какая-то тестовая база, и у каждого разработчика своя разработка. Согласовываются там с аналитиками, заказчиками, потом переносится в прод. Здесь мы можем рассмотреть это всё как, а, как такие ветки. То есть, у нас есть глобальный прод, от которого может быть там несколько тестовых версий, и у каждой тестовой на свою задачу может быть отдельно отдельная фича, так называемая. То есть, это, ну, в нашем языке обычно это просто номер какой-то задачи. Соответственно, в какой-то момент мы можем объединить несколько задач и поместить их в нашу версию тестовой базы. Как мы это делаем обычно? Ручками. Здесь мы делаем коммит, помещаем все изменения для того, чтобы, допустим, их ведущий разработчик отрецензировал, и потом уже с согласия ведущего разработчика, аналитика, мы переносим их в корневую ветку мастер. То есть, то, что у нас будет считаться рабочим билдом.
Как, собственно, изнутри состоит Git? Рабочий каталог, который у нас установлен локально, он не относится к репозиторию. Репозиторий — это у нас `.git` папка. Индекс — это промежуточное хранилище, то есть, как бы такой кэш. Нам это для чего нужно? Для того, что локально мы разрабатываем задачу. В рамках одной задачи мы, скажем так, сделали. Ну, на примере хранилища, очень часто бывает, что нам нужен какой-то один и тот же объект двум разработчикам. Вот Виталий меня поймёт. Мы работаем над одним объектом, и ему в одной задаче нужен этот объект, и мне в другой. Он у меня уже захвачен. Виталий говорит: "Помести там на минутку, я внесу свои правки". Вот здесь у нас такое же помещение есть в индекс. Но, соответственно, мы можем выбрать, что непроверенный функционал мы не будем помещать в репозиторий, то есть мы его не будем индексировать. Он у нас останется локально. А поместим только то, в чём мы уверены. Соответственно, к Виталию уже не попадёт какой-то код, который потом может уйти на прод. Если мы будем проверять код за мной, он его просто получил из хранилища. Если он его не закоммитил, да, то есть риск потом, что если Виталий раньше закончит задачу, на проде окажется у нас не недопроверенная моя часть кода. Вот. И, собственно, двухэтапное версионирование, назовём это так. Для этого у нас и есть, что можно выбирать, какие конкретные изменения у нас будут уходить дальше.
А как я сказал ранее, что такое коммит? Коммит — это запись снимков изменённых файлов в репозитории. У нас всё хранится, по сути, в файлах, и таким образом у нас гарантируется сравнение. То есть, сравниваются файлы между собой: предыдущая версия и текущая версия. В ветках разработки у коммита есть свойства: идентификатор, дата, имя коммитера и его электронная почта. Ну, по сути, это также выглядит как в хранилище, когда мы пишем номер задачи. Да, там у нас есть автоматически, и там пользователь у нас в принципе тоже есть. Здесь все эти данные тоже у нас будут автоматически при первичной настройке репозитория локального. Ссылка на коммит родителя. Это она, скажем так, невидимая. Она просто нам этот идентификатор нужен для того, чтобы Git понимал, какой ветке, к корню непосредственно, да, то есть к проду относится у нас внесение этих изменений, либо это тест, либо это какая-то фича, которая вообще, возможно, никогда не уйдёт на прод. Мы просто решили попробовать. Ещё, ещё одно удобство Git заключается в том, что мы можем бесконечно плодить фичи и в итоге не сливать их с корневой, скажем так, с корневой тестовой базы. То есть, на примере, у нас есть гипотеза, что нам, ну, мы не уверены, от аналитика поступает нам задача, как лучше это будет работать. Вот мы попробовали одно. Нам нет смысла удалять или даже комментировать этот код. Мы можем сделать отдельную подветку и посмотреть. Если нам что-то не понравилось, мы не удаляем весь этот код, а просто возвращаемся к предыдущему коммиту, на его основании делаем новую ветку и новую фичу. Таким образом, как бы у нас, скажем так, облегчается поиск каких-то нетривиальных решений. Нам не нужно плодить зелёнку в модуле, потому что у нас как бы мы можем бесконечное количество модулей хранить со своими изменениями.
А так, теперь, собственно, хотелось бы перейти непосредственно к примерку. Аэ. Всё у нас в целом и GitLab, и SonarQube настроены на серверах `fcr.com.ru`. Сейчас мы разберём какой-нибудь супер простой пример, супер простые вещи. Создадим новый проект. Ну, ладно, наверное, не очень. Мы, конечно, одни сники. Создаём пустой проект. Он у нас появляется в списке проектов. На самом деле, сейчас это у нас один единственный файл, в котором указано, что он был создан. И у нас по умолчанию всегда создаётся ветка `main`. То есть, это ветка, от которой мы уже будем создавать все остальные вариации. То есть, по сути, я бы советовал делать `main` скажем так, продом. То есть, в нашей парадигме `main` будет равно прод.
[музыка]
Предположим, что у нас есть, у нас есть какая-то конфигурация. Для упрощения она будет пустая. Вот э конфигурация изначально поставщика. Мы выгружаем. Прежде чем выгрузить файлы локально, я выделил себе папочку `git`, в которой, в которой мы будем хранить все свои проекты. Сейчас нам нужно получить с нашего сервера. Как я говорил, что у нас репозиторий удалённый. На данный момент только в удалённом репозитории есть наш проект. Сейчас мы должны получить его локально. Только я белый экран вижу или у всех белый экран? Так, секунду. Тебя, видимо, одно окно захвачено было, и ты что-то делаешь в других окнах. Так, сейчас всё. О, да, да. Прошу прощения. Собственно, есть выделенная папка. Неважно, как она называется, неважно, где она находится, просто для удобства. У меня установлена программа.
[музыка]
В том, что у нас является непосредственно консольным приложением, и в целом все команды в нём выполняются либо через, либо через командную строку, что не совсем удобно постоянно писать. В принципе, эта проблема решается сторонними приложениями, например, GitKraken. Изначально мы создаём себе локальный репозиторий с помощью команды `git clone`. Выбираем. Так, сейчас секунду. Для того, чтобы сделать, для того, чтобы сделать клон, у нас тут есть, есть в репозитории получить адрес. Мы его копируем, вставляем, и, собственно, выбираем директорию, в которую будет создана наша база. Тут же проверяем. Вот у нас появилась папочка `git`, в которой на данный момент есть только файл. Что вполне соответствует, что вполне соответствует тому, что у нас лежит в удалённом репозитории. Нашу типовую 1С и выгрузить конфигурацию в файл. Выбираем нашу папку, которую мы решили использовать как репозиторий. Проверяем, что у нас выгрузка произошла. Встаём на папочку, правой кнопкой мыши и помещаем наши изменения. Выбираем файлы, которые мы будем отправлять на удалённый репозиторий. В нашем случае, ну, не в нашем случае, в большинстве случаев 1С — это у нас все файлы. Так как можно, конечно, выбрать конкретные, но по сути, мы всегда выгружаем конфигурацию в файл, и не совсем удобно искать, в каких модулях мы что делали, поэтому проще всего выбирать все файлы. Можем поставить галочку "Кто автор коммита", чтобы дата текущая, и пишем какой-то комментарий: "Первичная выгрузка нашей базы". Идём на удалённый репозиторий. Так, идём на удалённый репозиторий, чтобы убедиться, что выгрузка прошла. Но она как-то не очень удачно прошла. Сейчас ещё раз. А, та-та-та. Там.
Да, всё, я заблудился. Команду `pull` выполнить. Просто можно выбрать, в следующий раз покажу, что в контекстном меню сразу "сделать commit and pull". Я выбрал только `commit`. Видим, что у нас появились файлы конфигурации. И теперь сделаем сразу ещё несколько веток. Ну, в данном случае мы сделаем одну ветку, назовём её `test`. Предположим, что это у нас будет та ветка, в которой будут работать аналитики. Ну, с которой будут работать аналитики. Она у нас будет шествовать помещению в прод.
[музыка]
И сразу создадим ещё одну ветку. Мы видим сейчас, что мы находимся в тестовой ветке, не в рабочей. На рабочую можно переключиться. И таким образом, если мы сейчас будем создавать ещё какую-то ветку, в дальнейшем мы создаём её для той версии, скажем так, конфигурации, в которой мы сейчас находимся. Сейчас мы находимся в `test`, и в `test` мы создадим какую-то ветку для разработки задач. Ну, предположим, у нас будет две каких-то задачи параллельно вестись разработка. А поэтому мы сразу же создадим ещё одну. И в рамках первой задачи, предположим, что нам надо было создать какой-то документ и в его модуле добавить какой-то блок перед записью с отказом. Опять сохраняем конфигурацию файла. Проверяем, в какой мы ветке находимся. Сейчас мы находимся в `task2`, потому что я её создал последнюю. Ну, вот переключился на первую. Переключился на первую. В рамках первой задачи. Так, проверяем, что у нас появился документ наш созданный. И коммитим. Добавляем комментарий. Выбираем все файлы. Дату ставим. Автор. Выбираем то, что я не сделал в прошлый раз. Хотим отправить данные на удалённый репозиторий. Проверяем, что у нас стало на удалённом репозитории. Проверяем удалённый репозиторий. У нас мы видим, что есть ветка `main`, которая всё ещё содержит первичную выгрузку конфигурации. Есть `test`, которая на текущий момент ей соответствует, потому что разработку мы ведём в `task1`, где у нас появился документ. А сейчас предположим, что параллельно второй программист у нас получает. Так, получим. Получим изменения. Но сначала выберем `task2`. Вот. Проверяем, что у удалённого второго программиста у нас нету никакого документа. Он получил у нас только что. Вот его рабочий день начался. Он получил свой вариант конфигурации, которая называется `task2`. Загружает его из файлов и видит, что никакого документа нет. Перед ним стоит задача создать справочник и какой-то вот код в модуле. Он сейчас у нас тоже напишет. Пусть для разнообразия у него будет отказ после этого. Он также закончил работу над своей задачей и сохраняет конфигурацию файла. Проверяем, что у нас появилась папочка `catalogs`, которые лежат в справочнике. Проверяем, на какой ветке мы сейчас находимся. Видим, что `task2`. И помещаем нашу вторую таску. Выбираем, что все файлы. Так. Мы попытались сымитировать работу двух разработчиков. Идём в удалённый репозиторий и смотрим, что у нас в итоге получилось в конце рабочего дня. На вариант нашей рабочей базы — конфигурация, в которой нет ничего лишнего. А тестовая база соответствует ей, потому что у нас условный VR и аналитики пока ещё ничего не проверяли. В `task1` у нас есть только документ. В `task2` у нас есть только справочник. Что же нам теперь с этим всем делать? Вот в Git Extensions, ещё одной программе визуализации Git, у нас как раз хорошо видно, как работают наши [музыка] деревья. Так, я тут совершил небольшую ошибку. Дело в том, что мы видим, что вместо того, чтобы сделать `task2` параллельно `task1`, я внёс изменение непосредственно на основании `main`. Это не совсем правильно. То есть, он хранит в себе ссылку на `main`. Он должен быть параллельно. Вот как-то так. Итак, вот у нас есть две задачи, которые мы хотим объединить. Ну, то есть, мы всё проверили, что всё хорошо, и можно переносить в тестовую, чтобы в дальнейшем перенести в главную. Переключаем. Ведущий разработчик у нас переходит в тестовую ветку, выбирает задачу, где у нас был создан документ. Идёт коммит. Можно в дальнейшем для истории оставить только объединённый вариант, либо оставить также слияние. То есть, для того, чтобы можно было отслеживать. Выбираем "оставить". Визуально это будет у нас выглядеть так. То есть, если мы оставляем одну ветку, то они станут упорядочены, никакого слияния не будет. Если создавать конец слияния, Studio выскакивает нам помочь. Теперь мы видим, что у нас `test`. Мы видим, что у нас `test` базируется на `main`, но при этом `task1` — вот эта голубая ветка — сливается с ней. То есть, мы взяли изменение `task1` и перенесли в нашу тестовую базу. Запушили изменения в удалённый репозиторий и пойдём проверим их. Видим, что в `test` у нас появился, появились данные по задаче, что создан документ. Но при этом в `main` у нас всё ещё типовая конфигурация. Таски 2 также остались данные по справочнику. В таске 1 — данные по документу. И теперь мы проверили, что таска 2 нас тоже полностью удовлетворяет. Разработчик справился со своей задачей. Мы также её хотим объединить нашей текущей веткой `test`. Нажимаем "объединить с текущей веткой". Выбираем "всегда создавать коммит слияния". Нажимаем "объединить". И тут у нас что-то пошло не так. Появились неразрешённые конфликты. В Git могут возникать конфликты, если непосредственно параллельная работа ведётся. Так как у нас идёт сравнение файлов, файлы будут отличаться. И в задаче ведущего разработчика будет входить разрешение этих конфликтов. Мы открываем файл и видим строкой там и там. Девять. Но в одном случае у нас указаны существующие метаданные, что мы добавили справочник, а в другом — документ. Нам, по-хорошему, надо перенести это всё. Можно выбрать: перенести только блок из локального репозитория, только блок из удалённого репозитория, либо, допустим, выбрать, что их надо перенести оба, один там после другого. Мы сейчас возьмём только локальный репозиторий и ручками добавим данные по документу. Собственно, примерно в большинстве случаев всё будет так и разруливаться. Закрываем. У нас есть ещё один конфликт. Точно так же у нас указано, что состав конфигурации входит в справочники. В другом случае в состав конфигурации они не входят. Здесь нам удобно сразу использовать, нажать кнопочку "использовать обе строчки с кода".
[музыка]
Так, всё, мы разрешили все конфликты. Фиксируем изменения и отправляем их в удалённый репозиторий. Видим, что у нас также наш маршрут теперь прошёл через `task2`, и мы получили данные в `test`. О, проверяем, что у нас теперь хранится в удалённом репозитории. В `test` видим, что у нас есть и справочник, и документ. И предположим, на следующее. Сейчас мы видим, что у нас есть только справочник у разработчика 2. Вот. Предположим, на следующий день он приходит и обновляет у себя. Обновляет у себя свою версию файлов конфигурации из тестового, скажем, типичное у нас обновление из с помощью скэ. Да, поднимает себя, скажем так, свежий бэкап для того, чтобы получить. Ну, даже не SQL, это скорее как получить данные из хранилища. Он получает последнюю версию тестовую. После этого заходит в конфигуратор и загружает конфигурацию из файлов. И вот, если вчера ещё вечером у него были данные только по справочнику, то теперь он получил данные и по задаче второго разработчика с документом. В принципе, эта функция аналогична получению данных из хранилища. Самые, самые базовые вещи, что касается Git, на этом мы закончим. Теперь, что касается SonarQube. Андрей, когда разработчики меняют один и тот же объект, а можешь такую ситуацию увести? Да. Ну, давай. А давай сейчас. Суть будет примерно такая же, как я показал только что на примере. Ну, давай прямо воспроизведём. Вот, допустим, у нас есть, у нас есть `test`, и мы сейчас двум разработчикам опять ещё сделаем по новым таскам. Так, создадим новую ветку. Здесь, надеюсь, то не долго. Ну, минут пять идёт. Четыре страшно. Не будешь. Так, вот у нас сейчас `test`, и у `test` мы создадим ещё две ветки. Ну, назовём там `task3`, `task4`. Так, вот наш один разработчик что-то решил ещё внести в модуль документа. Мы только что получили, допустим, ему не понравилось, что отказ был истина, и он решил вернуть, что отказ. Сохраняем опять файлы. Так, ладно, в `task4` он ставит ложь. Мы помещаем это всё. А в то же время другой разработчик у нас здесь написал просто какой-нибудь комментарий прямо в этой же строке. Ну, для того, чтобы у нас возникла какая-то коллизия. Это он сделал в рамках задачи номер три. Выгружаем файлы, коммитим. Проверим на удалённом репозитории. Вот у нас появились `task3` бла-бла-бла комментарий, и `task4`. Мы видим, что отказ переприсвоили. Теперь ведущий разработчик у нас вечером всё проверил и решил всё это внести в основную базу, нашу `test`. Он переключается на ветку и, допустим, сначала хочет поместить тот код, где убран отказ от записи, потому что это было корректно. Текущей веткой всё прошло корректно, всё здорово. Идём, отправляем эти данные в удалённый репозиторий и проверяем. Так, почему-то они у нас здесь не попали. `task4` убрали отказ от записи. Вот видим, что появился отказ ложь. А теперь после этого мы решили, что и комментарий нам тоже нужен. И выбираем также объединить с изменениями из таски номер три. Нажимаем "объединить", и у нас выходит конфликт. Ну, и мы начинаем разбираться, в чём его суть. Отличается версии конфигурации. Ну, это не критично. Здесь мы можем поставить, что конфликт решён. Будем использовать вот этот блок и второй. А второй, собственно, мы видим у нас сравнение конфигурации, примерно, да? То есть, мы видим, в чём у нас отличие. И точно так же решаем, что нам с этим делать. То есть, ну, хотим переносим оба изменения. Давай оба оставим. Да, можно руками, а можно выбрать, что использовать текст из какого-то одного блока. Ну, что-то какая-то ахинея, конечно, получилась, но руками, короче, надёжнее. Сделаем из этого вывод. Вот, наверное, приемлемо. То есть, у нас первый разработчик сначала сделал отказ истина, после этого написал комментарий, а потом второй разработчик сделал как слож. Мы помечаем эту коллизию, сохраняем изменения, и Git нам говорит, что все конфликты разрешены. Будем помещать. Мы говорим: "Будем, конечно". Фиксируем изменения и отправляем их. После этого идём, как обычно, удалённый репозиторий посмотреть, что у нас там получилось. И видим, что у нас как бы никакой код не потерялся. Ну, соответственно, гипотетически мы можем что-то и не переносить. То есть, если у нас возникла такая коллизия, ну, это прям максимально похоже на сравнение двух конфигураций, либо сравнение двух файлов. У нас отмечается, какие, какие изменения необходимо, необходимо либо перенести, либо нажать. И смотрим, как теперь это всё нам перенести, условно, в релиз. Мы встаём на наш главную ветку, в которой сейчас у нас не хранится ничего, то есть типовая конфигурация, и мы объединяем с нашим `test`, в котором всё, всё уже проверено, всё здорово, и объединяем его с текущей веткой. В итоге всё у нас слилось в `main`. И предположим, что мы заходим в конфигуратор, вот нашей рабочей базы, и просто загружаем конфигурацию из файлов, выбирая. Выбрал не тот пункт. Полностью заменяю конфигурацию и смотрим, что в модуле у нас все изменения по всем четырём задачам. То есть, у нас есть справочник, у нас есть документ, и код всех четырёх задач. Примерно живёт. В принципе, это можно автоматизировать точно так же, как с хранилищем, через OneScript, но в рамках нашей сегодняшней встречи этот вопрос мы рассматривать не будем. А рассмотрим вопрос, который касается SonarQube. SonarQube у нас также поднят на сервере по адресу `sonar.fcr.com.ru`. Создаём новый проект. Здесь можно выбрать "импорт". Вот наша задачка. Выбираем, в каком случае мы хотим сделать автоматическую проверку кода при изменении базовой ветки. Можно настройки сделать по таймеру, наме. Приём, э-э, то есть при внесении в любую ветку изменений. Но мы будем считать, что, допустим, наш, когда рабочую, мы что-то хотим внести в рабочую, тогда у нас будет автоматическая проверка на синтаксис. Здесь у нас есть инструкция первичной настройки. Нам нужно пойти в наш репозиторий, настройки CI/CD. Ну, в принципе, там всё подробно. Я сейчас покажу быстренько, как с нуля это всё было настроено, но здесь всё описано. То есть, создаём новую переменную, генерируем токен, снимаем галочку. Здесь устанавливаем. Дальше создаём ещё одну переменную. А тут адрес нам надо якобы указать такой, но мы его сейчас исправим, потому что с ним почему-то ничего не работает. Э-э, так, на примере другого проекта я сейчас посмотрю. А, так, так, если Пётр сейчас с нами, а можешь подсказать, какой IP-адрес нам надо подставить? Минуту подожди, скажи. 10. Я что-то помню. То есть, дело в том, что почему-то, если в явном виде указать адрес, то сервис не отрабатывает, но отрабатывает по IP-адресу 10.1.108.1, порт 9000. HTTPS убери. А, ТП. Да, 10.1.108.1. Порт 9000. Благодарю. Проверить, что. Да, разрешить ранеры запускать для нашего проекта. И последняя настройка, которая нам ещё нужна, это надо два файла сгенерировать. Создать два файла в нашем удалённом репозитории. Это можно сделать непо. Сделать всего один раз, а имена файлов у нас написаны в настройках, их содержимое тоже. Так, на этом, собственно, настройка для SonarQube завершена. И нам сейчас надо внести какие-нибудь изменения. Так, вот мы видим, что очередь pipeline у нас запустилась по проверки. Сейчас подождём, и, возможно, уже всё это работает. Так, запустим заново, чтобы точно быть уверенными, что все настройки применили. Так, что-то у нас не то с Docker. Ещё раз настройки.
[музыка]
Я так понимаю, что на самом деле вся проблема в Docker на стороне сервиса SonarQube, развёрнутого у нас. А, ну, что можно сделать? Можно посмотреть примеры, примеры других конфигураций, как это будет выглядеть. То есть, после того, как мы помещаем, ну, в нашем случае мы выбрали при создании корень, нас автоматически Sonar проверяет и выдаёт список замечаний. Ну, на примере нашей процедуры, которая у нас была при записи, да, у нас бы была ссылка, во-первых, на какое правило мы нарушили, скажем так, что у нас код вне области в модуле документа, а лишние пустые строки и так далее. То есть, со всем этим можно работать, и после этого, а при повторном помещении уже исправлены эти ошибки будут уходить. А, немного конкретно с Sonar, конечно, скомкано, но и здесь как таковой информации не то чтобы много, только первичная настройка. Дальше всё автоматически. Единственное правило, здесь мы можем редактировать правила. То есть, вот у нас 167 правил, 1 библиотека, и мы можем добавлять свои правила.
[музыка]
Какой ещё у нас есть вариант? Немного извращённый. Как нам можно работать? Можно работать с помощью программки Visual Studio Code, которая непосредственно может работать с Git. Мы указываем папочку, где у нас хранится наша конфигурация, каталог. И вот мы видим, у меня сейчас стоит расширение `language-1c` для того, чтобы можно было непосредственно использовать синтаксис 1С, синтаксис помощника. И такая же, по сути, у нас такое же выделение кода, как в конфигураторе. Можно код писать здесь и сразу сохранять файлы. Если что-то, допустим, ну, мы знаем на примере, что чтобы не заходить в конфигуратор заново, не раскладывать, тем более это может занимать значительное время, если это у нас не пустая конфигурация, как в примере, до 15 минут может быть сохранение файла в зависимости от количества объектов. Мы знаем, что нам надо поменять, мы можем это сделать в Visual Studio Code. У нас также работает подсказка, 1С-овская, не всегда корректно, но она работает. И как обнаружил вчера Пётр, у нас есть расширение `SonarLint`, которая нам позволяет в Visual Studio непосредственно, без участия нашего сервиса, поднятого, проверять на синтаксис по тем же самым Sonar-правилам. Единственное, что на данный момент я ещё с этим не разбирался, и как это делать, я не могу рассказать. Но есть такая возможность. Если кому-то не нравится конфигуратор, не нравится Eclipse, то можно все наши таски, скажем так. То есть, у нас Visual Studio Code непосредственно привязан. И точно так же здесь можно через него помещать, а не через Git Extension. Вот, наверное, сейчас самое время включить микрофон и позадавать вопросы. Андрей, доступ к SonarQube, его раздают наши администраторы? К ним обращаться. Да, да, доступ раздают администраторы. Угу. Это писать на `it@fcr.com.ru`. Угу. Так, а ещё вопрос. А Пётр подготовил какие-то материалы? Это я так понимаю, подробный мануал по установке, разворачиванию, примером каким-то работы там есть. Э-э, мануал, ну, он немножко сыроват, но им вполне можно пользоваться. Плюс там есть ссылки на сторонние ресурсы, с помощью которых можно позакрывать пробелы, теоретически, скажем так. И я думаю, мы просто разместим это где-то на клауде и дадим ссылочку. Надо дать на них про.
[музыка]
Чере, у тебя такое есть в планах сделать его х? Да, есть. Ну, это регламент будет для, по сути, скажем так, вот ведущего разработчика, потому что это будет ложиться на его плечи. Всё это администрирование, следить, чтобы делали коммиты в соответствующей ветке. Ну, как мы видели, гипотетически, да, можно взять в какой-то момент, всё это, конечно, откатывается, потому что также, как почти все из нас работали с Microsoft Server, да, у нас есть снимки. Также и здесь у нас снимки. Мы в любой момент можем откатиться, но это займёт какое-то время. И гипотетически, который мы подразумеваем, что это для не трогать на Новый год, для рабочей базы будут свои задачки. Туда подпивас можно потом отделить и перенаправить там в тест или там в фичу, в таск и так далее. Но ведущему разработчику как бы за этим надо будет прослеживать. Ну, это в рамках дальнейшей работы уже будем обсуждать. А можно пос тогда, конечно. Смотри, а ты там озвучил такой пример, что мы можем сделать несколько версий какого-либо кода, да, чтобы просто их, допустим, посравнивать между собой. Ну, чтоб, типа, это проще, чем заменить, да? Ну, смотри, у тебя пустая конфигурация. А я, ну, а мы внедряем ERP. Действительно ли легче и проще будет сделать так, как ты сказал, чем, допустим, закомментить зелёнку? Просто код или в расширение написать? Смотри, я когда говорю про зелёнку, я что имел в виду, да? То есть, у нас здесь не будет никакой коллизии. То есть, вот у тебя есть, ну, допустим, какой-то изначально запрос, ты пишешь, предположим, да, большущий запрос. В какой-то момент ты понимаешь, что он тебя не устраивает, хочешь вообще сделать по-другому. Вот зелёнку рядышком написал свежий. Но тот ты тоже не хочешь избавляться, потому что там у тебя есть какие-то здравые мысли. У тебя появляется третья итерация, ты опять залил зелёнкой, как бы третья. А в Git у тебя будет три параллельных ветки. Я это понимаю. Времени у тебя ничего особо, никакой сложности. Тут смотри, вопрос в чём? Первый момент, ну, насколько у тебя часто одного запроса появляются, как будто нечасто. Второй момент, с реальной конфигурацией это будет быстро работать, собственно. То есть, сколько у меня эта выгрузка будет ERP занимать в XML? Ну, то есть, а, ну, если не, не, если с точки зрения выгрузки всей конфигурации, конечно. Но если мы говорим про один какой-то модуль, ты же можешь не выгружать всё. Ты можешь в том же Visual Studio, вот как я сейчас, открыть конкретный модуль, исправить, и после этого закоммитить. В рамках одного модуля вообще достаточно очень удобно. Почему использовать у е? Он примерно так работает уже по модулям. Он же Git, по сути, работает. Не запрещает использовать, просто м преимущество скорости. Кодить и гадить постоянно в конфигуратор, кодить себе расширение или там нет? Я просто привёл пример, да, да. С расширением ещё быстрее, конечно. Тут, тут вообще бесспорно. Я просто привёл один из вариантов, как можно использовать параллельные фичи. Ну, как это используется, по крайней мере, да, не в мире 1С, когда идёт разработка. Вот вопрос расширения теперь. А, допустим, можно ли это всё с расширениями делать? Расширение же тоже можно также выгружать файлы. Просто условно, допустим, изначально у тебя будет ветка `main`, да, и, ну, не знаю, её можно, она в принципе, `main` просто создаётся по умолчанию, когда ты поднимешь, ну, создаёшь новый проект. Ты можешь создать ветку, условно, назвать её там "корень конфигурации". Расширение, ветка параллельно. У тебя есть ветка, не подчинённое этому корню, да, а параллельно "расширение один", "расширение два", и с каждым у тебя будет своё версия, свои там фичи и так далее и тому подобное. То есть, ну, и как раз с расширениями всё гораздо будет быстрее работать, потому что расширение не ERP, там всё приемлемо по скорости. А вопрос ещё. Смотри, ты говоришь, можно выгружать отдельные модули. Ну, то есть, короче, суть в чём, а загружать всю конфу, выгружать и ещё потом это помещать в хранилище 1С. Ну, это долго, да? Ну, конфа ERP там большая, да, гигабайты типа условно. Вот ты говоришь, можно модуль выгружать. А если автоматизированная история, что ты будешь перезагружать только конкретные модули туда-сюда, а не всю конфигурацию полностью? Имеешь в виду перезагружать, когда мы что-то. Ну, ты приходишь, условно, с утра, получаешь последнюю версию, и вот ты её хочешь загрузить только дифференцированную разницу между версиями, да? Гипотетически такое можно сделать. Вопрос. А у 1С как бы всё украдено до нас. Есть такой файл `configDump.xml`. У каждой, у каждого объекта конфигурации есть своя условная версия, идентификатор. Когда мы её редактируем, он меняется. И когда мы выгружаем какую-то конфигурацию, да, он выгружает на самом деле не всё. Он смотрит, что уже выгружена в этом `configDump`-е в XML-ке, сравнивает версии. Если она совпадает, он просто не выгружает этот файл, объект. И то есть, он выгружает изначально только то, что мы поменяли. Ну, если файла нету, то он выгружает всю конфу. И вот как раз история схожая, которая там, по-моему, гига, что ли, ветка загружается 18 минут вся. Но если ты поменял один модуль, ты его выгрузил, у тебя выгрузился только один, и загружается, насколько помню, точно так же. История параметров есть. Самый главный. А в чём, допустим, преимущество SonarQube перед тем же самым, честно говоря, перед APK? Никакого преимущества, на мой взгляд, нету. Там точно такие же правила используются. Ну, собственно, тогда получается, единственная история, по которой это может применяться, большой проект, где действительно большая конкуренция за какие-либо объекты, при этом, допустим, с Git удобно по каким-то причинам типа работать, чтобы потом. Единственный, смотри, единственный, как бы, в чём плюс Sonar, да? Ну, в том, что он у нас интегрирован с Git, да? Если мы говорим про разработку конкретно Git. А так, сама проверка непосредственно, да, что, ну, базовые правила у нас одинаковые. Вот. Поэтому, но при этом, если по DPK у нас условно уже под стандарты FCR написаны, то по Sonar их придётся полностью писать. Если даже мы зальём типа типовую конфу, да, 800 миллион ошибок. Да, ну, ну, стандартная история. И никто как бы не говорит, что, то есть, цель сегодняшнего, как бы, сегодняшней встречи не то, что давайте все перепрыгиваем на Git и на Sonar и бросаем всё, что у нас было раньше. Ну, это цель, как бы, в целом рассмотреть такую возможность, и в чём её как бы плюсы и минусы. Ну, да, я, собственно, про плюсы и минусы. Всё, спасибо.