Зачем нужно программирование на питоне

5/5 ( 2 голоса )

Рассмотрим практику применения системы контроля версий Git при коллективной разработке решений на платформе 1С

Что такое Git?

Git сейчас является одной из самых популярных систем контроля версий. Если вы знаете этот продукт, вы можете перейти непосредственно к следующей части статьи. Но как показывает практика среди разработчиков 1С очень немногие представляют себе. Что такое Git и зачем он нужен. А те, кто знает. Воспринимают этот программный продукт как “что-то связанное с консолью и старым Linux”.

И они правы. Интерфейс Git, мягко говоря, не имеет большого интерфейса. Но не за это разработчики так любят Git. Строго говоря, это один из первых и проверенных временем VCS. Используется, в частности, при разработке ядра Linux.
В настоящее время Git приобрел широкую популярность благодаря развитию проекта GitHub. В современном мире практически каждый разработчик программного обеспечения знает. Что такое GitHub и зачем он нужен. Он так или иначе связан с языками программирования общего назначения (C ++, Java, PHP и т. Д.). И многие люди, не связанные с разработкой программного обеспечения GitHub, также знакомы с ним, потому что оттуда всегда можно скачать последнюю версию этого бесплатного программного обеспечения, в той мере. В какой GitHub используется как сайт для коллективной разработки этого программного обеспечения.

Основной альтернативой этому ресурсу является не менее известный Bitbucket. Но Bitbucket использует стек JIRA для организации локальных хранилищ разработчиков. Какой из них выбрать, зависит от вашего вкуса. Вы можете найти много дискуссий на эту тему в Интернете, но это не главная цель этой статьи.
Я давно знаком с Git. Кроме того, проекты 1С чаще всего имеют конкретную внутреннюю цель. Поэтому размещение их кода в публичном репозитории бессмысленно. Если не сказать “неправильно” по отношению к заказчику.

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

Как работает Git?

Ничего особенного: выберите каталог с исходным кодом программного обеспечения или просто файлы и выполните команду Git. Которая вам нужна для создания репозитория для этого каталога (локального и удаленного – именно поэтому Git является распределенной системой управления версиями).
Затем вы работаете с исходными файлами в каталоге, для которого вы создали репозиторий.

После того, как вы закончили вносить определенные изменения. Которые можно сохранить как версию (скомпилировать. Запустить, проверить. Что каким-то образом это работает, например). Вы выполняете команду git commit и сохраняете изменения в репозитории. Чтобы перенести изменения в удаленный репозиторий, выполните команду git push.
На самом деле, вполне логично. Что в локальном репозитории должна быть специальная функция получения изменений. Внесенных другими разработчиками. Для этого есть такие операции. Как git pull – to get a full repository и git fetch to get the changes.

При получении обновлений может возникнуть так называемый процесс “слияния”. Когда один и тот же файл кода был исправлен несколькими разработчиками. Конфликты слияний возникают и в том случае. Если разные разработчики исправили одну и ту же строку в исходном файле. В связи с этим могут возникнуть различные направления развития. Но это более сложные процессы использования систем контроля версий. В 1С есть определенная специфика, которая делает данный функционал Git ненужным.
Для общего понимания того, как работает Git и большинство этих систем контроля версий. Нет необходимости разбираться во всех тонкостях.

Основная идея состоит в том, чтобы понять, что существуют локальные и удаленные репозитории. В репозитории хранится вся история изменений. Внесенных в отслеживаемые файлы. Изменения фиксируются в репозитории с помощью команды commit. Локальный репозиторий синхронизируется с удаленными командами push и pull/fetch. Таким образом, у вас есть вся история изменения файлов исходного модуля, включая изменения. Внесенные другими разработчиками.

Для чего он нам нужен?

Продвинутые разработчики 1С наверняка думают: зачем разработчику 1С нужен Git. Если в платформу “Магазин конфигураций” встроен собственный VCS?

Большое спасибо 1С за этот функционал. Также стоит отметить. Что VCS владеет далеко не всеми еще более продвинутыми современными ERP-системами и платформами для разработки бизнес-систем.
К сожалению, магазин конфигураций 1С имеет определенные недостатки:

  • Чрезвычайно низкая скорость сравнения (сравнение двух версий в хранилище может занять от 1 до 15 минут). Что делает эту функциональность практически бесполезной.
  • Ветвления нет. Весь процесс разработки в 1С строго линейный.
  • Отсутствие подробной исторической информации об объектах. На самом деле, чтобы получить такую информацию, нужно сравнить версии столько раз. Сколько объект менялся. Но тогда вы не сможете получить обобщенную информацию.

  • Отсутствие многих “плюсов” современных VCS, таких как статистика активности. Встроенный багтрекер и т.д.
  • Ужасный интерфейс.

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

Обзор кода

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

  • Программист, зная, что другие будут смотреть на его код, больше заботится о качестве кода. Пишет его более правильно и точно.

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

Что нам нужно для проверки кода? Возникает желание ответить на этот вопрос: в одно мгновение “только сам код и ничего больше.” Но. К сожалению. Это не так. Обзор кода был бы хорош только для недавно написанного кода. Кроме того, специфика разработки в 1С заключается в том. Что в большинстве случаев решение разрабатывается не “с нуля”. Существует достаточно большой объем исходного кода, который, как правило. В несколько раз превышает объем разработки. Выполняемой проектной командой.

Поэтому нет смысла рассматривать все модули в чистом виде.
Таким образом, нам нужна история изменений по всем модулям, с быстрым доступом и анализом ее. Именно здесь возникает использование Git. Осталось только определить средства представления сводной информации. Чтобы с ней было удобно работать.

GitLab

GitLab-это открытый проект для развертывания среды, аналогичной GitHub. Для собственной команды разработчиков. Конечно, аналогов много, но GitLab, пожалуй, самый популярный проект такого рода.

Для коммерческого использования он платный, но сумма вполне приемлемая, даже для скромного бюджета.
В общем, все очень похоже на интерфейс GitHub, так что разобраться в нем нетрудно. Вы можете скачать и установить GitLab с официального сайта [4]. Кстати, дистрибутивов Windows нет (что неудивительно). Но существуют так называемые Омнибусные пакеты. Которые делают процесс установки GitLab под Linux делом двух команд в консоли.
Существует еще более простой вариант установки – загрузить готовую виртуальную машину с предустановленным GitLab [5]. Есть такой на TurnKeyLinux. Это еще раз подтверждает популярность программного продукта.

Что же делать?

Итак, мы решили, что будем использовать, как и почему. Теперь осталось только одно ‒ сложить все воедино:

  1. Скачать и установить Git для Windows. После установки не забудьте присвоить путь git.exe в переменной PATH. Если это не происходит во время установки по какой-либо причине.
  2. Прочитайте содержание статьи на Infostart. Затем загрузите OneScript с ресурса tge и установите движок и скрипты.
  3. Разверните виртуальную машину с помощью GitLab [5]. Создайте пользователей и проект. Когда вы создадите проект. GitLab напишет вам путь к репозиторию.

    SSL не нужен внутренне. Скорее всего. Вы выберете HTTP-доступ.

  4. Теперь мы настроим репозиторий. Хотелось бы удалить все, что не содержит кода. А именно добавить следующие строки в файл .git/info/exclude:
  5. Затем введите что-то вроде (на этом шаге инициализируется начальный репозиторий GIT):
    Затем команда:
    запускает очень длительный процесс синхронизации хранилища с Git. В ходе этого процесса каждая версия конфигурации из репозитория будет извлечена и проанализирована. Процесс очень медленный. В моем случае он занял несколько недель.
  6. Завершив этот сложный и долгий процесс. Вы можете перейти в GitLab и насладиться вновь открывшимся функционалом.

    Для проверки кода функциональность показана на рис. 1. Рис. На рис. 2 показан так называемый вид обвинений. Особенностью системы является определение авторства той или иной строки кода. Строго говоря. Это делает излюбленный разработчиками авторский комментарий просто бессмысленным.

В конце концов, освоив этот инструмент, можно вывести разработку на новый уровень. Используя те же возможности. Которые уже давно имеются в распоряжении коллег. Разрабатывающих языки программирования общего назначения в данной области.
Вам нужно установить и настроить git или перенести svn в git?

Контакты.