Gitlab как собрать статистика по выходу релизов

Релиз GitLab 8.13

Мы путешествуем по миру и очень рады встречам с нашими пользователями.

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

Теперь можно создавать несколько досок задач (issue boards), а находясь на странице доски — быстро заводить новые задачи. Жизнь мерж-конфликтов стала ещё тяжелее и скоротечнее, потому что теперь их можно разрешать непосредственно в GitLab. Улучшенная система Cycle Analytics позволяет ещё проще следить за тем, какая версия кода выполняется в каждом из окружений (environments), а также предоставляет вам моментальную обратную связь.

Званием MVP этого месяца награждается Марк Зигфридт (Marc Siegfriedt) за его вклад в создание точки входа (endpoint) API для коммита нескольких файлов сразу. Марк проявил терпение и упорство в работе над этим сложным мерж-реквестом. Спасибо, Марк!

Несколько досок задач вместо одной (EE)

Теперь в каждом проекте GitLab Enterprise Edition может быть несколько досок задач.

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

Мы с нетерпением ждём ваших рассказов о том, какое применение вы найдёте доскам задач.

Создание новых задач непосредственно на доске задач

При просмотре доски задач вы можете быстро добавить ещё одну в любой список:

Разумеется, она сразу же получит соответствующие метки.

Редактор мерж-конфликтов.

В GitLab 8.11 появилось разрешение мерж-конфликтов, позволяющее при разрешении конфликта выбирать между вариантом из текущей ветки и из той, которая мержится в текущую.

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

Мы надеемся, это поможет вам за быть всю боль мерж-конфликтов как страшный сон.

Групповые метки

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

Чтобы её упростить, мы реализовали групповые метки (group labels). Они работают точно так же, как и обычные, но создаются и настраиваются один раз для группы проектов, после чего доступны в каждом проекте.

Group level labels in GitLab 8.13

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

Возможность остановки Review Apps

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

Stop dynamic environments (review apps) in GitLab 8.13

Ссылки на развёрнутые версии кода

GitLab создаёт специальные ссылки (ref) на версии кода, которые в данный момент развёрнуты на каждом из ваших окружений (environments). Вам достаточно один раз настроить ваш локальный репозиторий, чтобы обновлять эти ссылки с помощью простого git fetch .

Конвейеры в просмотре коммитов

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

Pipelines for commits in GitLab 8.13

Улучшения Cycle Analytics

Изменено поведение Cycle Analytics — теперь проводятся замеры всей активности за определенный промежуток времени, а не только отправки в продакшен. Само собой, стадии staging и production показывают только то, что было отправлено в продакшен.

Назначение тикетов автору мерж-реквеста

Вы указали ссылки на определенные тикеты в своем коммите или мерж-реквесте, но не назначили их на себя или на автора мерж-реквеста? Теперь есть простой способ сделать это:

Quickly assign

Ограничение видимости репозитория проекта

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

Project repository visibility

Слеш-команда /wip

Теперь можно использовать наши замечательные слэш-команды для быстрого изменения статуса мерж-реквеста с/на Work-In-Progress (WIP).

Просто введите /wip и подтвердите отправку вашего комментария или описания мерж-реквеста.

Отслеживание отладки CI

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

С другой стороны, из-за этого бывает сложно установить причину неправильного выполнения какой-либо задачи. В такой ситуации вы можете включить отслеживание отладки в .gitlab-ci.yml , эта опция доступна в GitLab Runner начиная с версии 1.7. Она включает трассировку shell, в результате чего в логи сборки добавляется информация о выполнении всех команд, присваивании значений всем переменным и т.д.

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

Для включения отслеживания отладки присвойте переменной `CI_DEBUG_TRACE значение true:

job1: variables: CI_DEBUG_TRACE: "true"

Отключение операций Git в CI

Появилась возможность отключения операций Git для ускорения сборок, не требующих взаимодействия с репозиторием. Для этого нужно указать стратегию Git в файле .gitlab-ci.yml :

variables: GIT_STRATEGY: none

Дата развертывания в мерж-реквестах

Небольшое, но приятное нововведение — теперь дата развертывания указывается прямо в мерж-реквесте.

See when a deploy happened in GitLab 8.13

GitLab Runner

Также, вместе с GitLab 8.13 был выпущен GitLab Runner 1.7. Список самых интересных изменений:

Добавлено использование Go 1.7 — добавляет поддержку Runner на Mac OS X Sierra !323
Добавлена GIT_STRATEGY=none !332
Добавлена поддержка OffPeak для автоскейлинга !345
Введена переменная для включения режима трассировки shell в bash, cmd.exe и powershell.exe !339
В первую очередь загружается конфиг InCluster, если загрузка неудачна — конфиг kubectl !327
Godep: github.com/Sirupsen/logrus обновлен до версии 0.10.0 !344
Добавлено использование git clone –no-checkout и git checkout –force !341
Значение поля runner теперь переводится в нижний регистр для совместимости с ограничениями GCE !297
Добавлена обработка before_script при выполнении команды exec !355
Сборки больше не помечаются как неудавшиеся из-за ошибки кеширования !359
Внесены улучшения в процедуру регистрации !356

Полный список изменений можно посмотреть в чейнджлоге Runner’а.

GitLab Mattermost

В GitLab 8.13 включен Mattermost — альтернатива Slack с открытым исходным кодом, доступная на вебе, десктопе и мобильных усторйствах и интеграцией более чем с 700 приложениями при помощи Zapier. В этом месяце добавлена интеграция с Slack, Gitter, XMPP и IRC. Mattermost теперь обновляется 6 раз в год; новые обновления добавляются в GitLab через месяц после их выхода.

Нововведения в API

В данный релиз включено несколько нововведений в API:

Одновременный коммит нескольких файлов

Благодаря MVP месяца Марку появилась возможность совершать через API коммит нескольких файлов одновременно.

Интерфейс доски задач

Андре Гуэдэс (Andre Guedes) реализовал полноценный API для доски задач. Спасибо, Андре!

Информация о действиях пользователей

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

Список видимых проектов

Благодаря Бену Бекелю (Ben Boeckel) появилась возможность просмотреть список всех видимых вам проектов через API.

Изменения в производительности

Улучшена производительность отображения страницы group milestones: !6457
Уменьшено количество выполняемых запросов при обработке ссылок Markdown: !6457 и !6545
Sidekiq теперь использует пул связей при работе с кешем Rails: !6468 и !6657
Уменьшено количество обновлений таблицы ci_runners , благодаря чему уменьшено количество обращений к базе данных: !6537
Немного уменьшено количество выполняемых запросов при пуше коммитов: !6680
Добавлен ежедневный предварительный подсчет рейтинга проектов для страницы trending projects, что повышает ее производительность: !6749
Добавлена асинхронная загрузка diff’ов при создании нового мерж-реквеста: !5844
При изменении timestamp’а последних изменений проекта более не используются временные ссылки (leases) Redis: !6678
Секретный токен для gitlab-shell и API теперь хранится в памяти, а не читается с диска при каждом запросе API: !6599
Уменьшено количество запросов, используемых при проверке политик проекта: !6442
Worker, используемый для истекающих артефактов сборки, теперь эффективнее распределяет задачи и использует более эффективные запросы SQL: !6732
Обновления мерж-реквестов с помощью пушей теперь используют специальный Sidekiq worker: !6767
Хуки конвейера CI теперь обновляются асинхронно: !6824
Метрики конвейера CI теперь обновляются с помощью Sidekiq worker: !6896
Улучшена производительность и использование памяти загрузчика GitHub: !6552
Оптимизировано получение URL для отрисовки эмодзи в обсуждениях.: !6848
При создании проекта мы автоматически создаем соответствующую строку project_features вместо проверки этого (и создания строки при необходимости), когда бы мы ни запрашивали проект из базы данных. Это уменьшает количество запросов к базе данных, когда нам нужно вернуть проект из версии 2 в 1: !6908
Коммиты конвейера CI обновляются только после создания конвейера вместо обновления каждого по-отдельности: !6986
Длительности конвейера CI обновляются только в конце конвейера вместо обновления после каждого изменения состояния: !6987
Обновление кэша проекта теперь происходит каждые 15 минут. Статистика может стать несвежей (например, подсчет коммитов), но существенно уменьшится нагрузка на диск: !7017
Sidekiq теперь использует разные очереди для большого количества разных работников: !7006
Задачи в конвейере CI распределяются умнее, предотвращая назначение нескольких задач с одними и теми же параметрами в одно и то же время: !7005
Кэширование полей markdown в базе данных !6095

Данные об использовании GitLab теперь кэшируются: !779

Изменения в gitlab-shell:

Отслеживание производительности Git теперь может быть включено с помощью переменной окружения: !91
Улучшено перемещение репозиториев между шардами: !97 и !96

Изменения пакета Omnibus GitLab

Jemalloc теперь используется как аллокатор памяти по умолчанию, что должно снизить объем используемой памяти.
У пакетного NGINX теперь есть метод Status, включенный по умолчанию. Спасибо Luis Sagastume!
Новые опции конфигураций добавлены в файл gitlab.rb

Другие изменения

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

Барометр обновлений

Этот релиз содержит значительное количество миграций, которые требуют даунтайма. Администраторы должны приготовиться минимум к 30 минутам простоя. Небольшие установки (например, с несколькими сотнями проектов) должны завершать процесс миграций за 5-10 минут.

Помните, что эти оценки времени примерные и могут отличаться в зависимости от вашей ситуации.

Некоторые из миграций:

добавляют внешние ключи в существующие таблицы
перемещают задачи Sidekiq из одной очереди в другую
удаляют повторяющиеся ярлыки (labels)
устанавливают приоритеты ярлыков
производят другие чистки данных

Очереди Sidekiq

Этот релиз внес несколько изменений в Sidekiq. Раньше GitLab использовал ограниченное количество очередей, которое было жестко определено в bin/background_jobs и в Omnibus GitLab. Начиная с версии 8.13 все названия используемых очередей находятся в config/sidekiq_queues.yml . Пользователям, использующим bin/background_jobs для запуска Sidekiq или Omnibus GitLab, больше не нужно ничего делать вручную. Пользователям, запускающим установку из исходников, может потребоваться внести изменения в настройки, чтобы удостовериться, что Sidekiq использует этот конфигурационный файл. Для этого им нужно убедиться, что Sidekiq запускается следующим образом:

sidekiq -C path/to/gitlab/config/sidekiq_queues.yml

Если вы используете кастомный файл конфигурации Sidekiq, вам нужно добавить содержание sidekiq_queues.yml в этот файл (и поддерживать его актуальным) или использовать sidekiq_queues.yml и определить кастомные настройки с помощью CLI (command line interface) для sidekiq .

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

Еще кое-что

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

Пожалуйста, помните, что исходные пакеты Omnibus остановятся, запустят миграции и запустятся снова вне зависимости от того, насколько «большое» или «маленькое» получится обновление. Чтобы изменить это поведение, добавьте файл /etc/gitlab/skip-auto-migrations .

Установка

Если вы устанавливаете GitLab с «нуля», прочитайте соответствующий раздел.

Обновление

Enterprise Edition

GitLab Enterprise Edition включает в себя дополнительные функции типа поддержки LDAP-групп. Подробную информацию можно посмотреть в описании GitLab EE.

GitLab EE доступен только по подписке. Не хватает времени на установку и настройку нового инструмента? В стоимость подписки входят услуги по установке и обновлению GitLab на ваших серверах.

Перевод с английского выполнен переводческой артелью «Надмозг и партнеры», http://nadmosq.ru, над переводом работали nick_volynkin, rishavant и sgnl_05.

Блог компании Softmart
Git
Системы управления версиями
Системы сборки

Руководство по CI/CD в GitLab для (почти) абсолютного новичка

Наверное, у каждого разработчика, имеющего хотя бы один пет-проект, в определённый момент возникает зуд на тему красивых бейджиков со статусами, покрытием кода, версиями пакетов в nuget… И меня этот зуд привёл к написанию этой статьи. В процессе подготовки к её написанию я обзавёлся вот такой красотой в одном из своих проектов:

результаты

В статье будет рассмотрена базовая настройка непрерывной интеграции и поставки для проекта библиотеки классов на .Net Core в GitLab, с публикацией документации в GitLab Pages и отправкой собранных пакетов в приватный фид в Azure DevOps.

В качестве среды разработки использовалась VS Code c расширением GitLab Workflow (для валидации файла настроек прямо из среды разработки).

Краткое введение

CD — это когда ты только пушнул, а у клиента уже всё упало?

Что такое CI/CD и зачем нужно — можно легко нагуглить. Полноценную документацию по настройке пайплайнов в GitLab найти также несложно. Здесь я кратко и по возможности без огрехов опишу процесс работы системы с высоты птичьего полёта:

разработчик отпраляет коммит в репозиторий, создаёт merge request через сайт, или ещё каким-либо образом явно или неявно запускает пайплайн,
из конфигурации выбираются все задачи, условия которых позволяют их запустить в данном контексте,
задачи организуются в соответствии со своими этапами,
этапы по очереди выполняются — т.е. параллельно выполняются все задачи этого этапа,
если этап завершается неудачей (т.е. завершается неудачей хотя бы одна из задач этапа) — пайплайн останавливается (почти всегда),
если все этапы завершены успешно, пайплайн считается успешно прошедшим.

Таким образом, имеем:

пайплайн — набор задач, организованных в этапы, в котором можно собрать, протестировать, упаковать код, развернуть готовую сборку в облачный сервис, и пр.,
этап (stage) — единица организации пайплайна, содержит 1+ задачу,
задача (job) — единица работы в пайплайне. Состоит из скрипта (обязательно), условий запуска, настроек публикации/кеширования артефактов и много другого.

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

Перед началом: почему?

Потому, что когда появилась необходимость создать приватные репозитории под пет-проекты, на GitHub’e они были платными, а я — жадным. Репозитории стали бесплатными, но пока это не является для меня поводом достаточным переезжать на GitHub.

Почему не Azure DevOps Pipelines?

Потому что там настройка элементарная — даже не требуются знания командной строки. Интеграция с внешними провайдерами git — в пару кликов, импорт SSH-ключей для отправки коммитов в репозиторий — тоже, пайплайн легко настраивается даже не из шаблона.

Исходная позиция: что имеется и чего хочется

автоматическую сборку и тестирование для каждого merge request,
сборку пакетов для каждого merge request и пуша в мастер при условии наличия в сообщении коммита определённой строки,
отправку собранных пакетов в приватный фид в Azure DevOps,
сборку документации и публикацию в GitLab Pages,
бейджики!11

Описанные требования органично ложатся на следующую модель пайплайна:

Этап 1 — сборка
- Собираем код, выходные файлы публикуем как артефакты
- Получаем артефакты с этапа сборки, гоняем тесты, собраем данные покрытия кода
- Задача 1 — собираем nuget-пакет и отправляем в Azure DevOps
- Задача 2 — собираем сайт из xmldoc в исходном коде и публикуем в GitLab Pages
Собираем конфигурацию

Готовим аккаунты
1. Создаём аккаунт в Microsoft Azure
2. Переходим в Azure DevOps
3. Создаём новый проект
  1. Имя — любое
  2. Видимость — любая
4. При нажатии на кнопку Create проект будет создан, и будет совершён переход на его страницу. На этой странице можно отключить ненужные возможности, перейдя в настройки проекты (нижняя ссылка в списке слева -> Overview -> блок Azure DevOps Services)
5. Переходим в Atrifacts, жмём Create feed
  1. Вводим имя источника
  2. Выбираем видимость
  3. Снимаем галочку Include packages from common public sources, чтобы источник не превратился в ~~помойку~~ клон nuget
6. Жмём Connect to feed, выбираем Visual Studio, из блока Machine Setup копируем Source
7. Идём в настройки аккаунта, выбираем Personal Access Token
8. Создаём новый токен доступа
  1. Имя — произвольное
  2. Организация — текущая
  3. Срок действия — максимум 1 год
  4. Область действия (scope) — Packaging/Read & Write
9. Копируем созданный токен — после закрытия модального окна значение будет недоступно
10. Заходим в настройки репозитория в GitLab, выбираем настройки CI/CD
11. Раскрываем блок Variables, добавляем новую
  1. Имя — любое без пробелов (будет доступно в командной оболочке)
  2. Значение — токен доступа из п. 9
  3. Выбираем Mask variable
На этом предварительная настройка завершена.

Готовим каркас конфигурации

По умолчанию, для настройки CI/CD в GitLab используется файл .gitlab-ci.yml из корня репозитория. Можно настроить произвольный путь до этого файла в настройках репозитория, но в данном случае это не нужно.

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

Сначала добавим в файл конфигурации ссылку на docker-образ, в котором будет происходить выполнение задач. Для этого находим страницу образов .Net Core в Docker Hub. В GitHub есть подробное руководство, какой выбрать образ для разных задач. Нам для сборки подойдёт образ с .Net Core 3.1, поэтому смело добавляем первой строкой в конфигурацию
```
image: mcr.microsoft.com/dotnet/core/sdk:3.1
```
Теперь при запуске пайплайна с хранилища образов Microsoft будет скачан указанный образ, в котором и будут исполняться все задачи из конфигурации.

Следующий этап — добавить stage‘ы. По умолчанию GitLab определяет 5 этапов:
- .pre — выполняется до всех этапов,
- .post — выполняется после всех этапов,
- build — первый после .pre этап,
- test — второй этап,
- deploy — третий этап.
Ничего не мешает объявить их явно, впрочем. Порядок, в котором указаны этапы, влияет на порядок, в котором они выполняются. Для полноты изложения, добавим в конфигурацию:
```
stages: - build - test - deploy
```
Для отладки имеет смысл получить информацию об окружении, в котором исполняются задачи. Добавим глобальный набор команд, который будет выполняться перед каждой задачей, с помощью before_script :
```
before_script: - $PSVersionTable.PSVersion - dotnet --version - nuget help | select-string Version
```
Осталось добавить хотя бы одну задачу, чтобы при отправке коммитов пайплайн запустился. Пока что добавим пустую задачу для демонстрации:
```
dummy job: script: - echo ok
```
Запускаем валидацию, получаем сообщение, что всё хорошо, коммитим, пушим, смотрим на сайте на результаты… И получаем ошибку скрипта — bash: .PSVersion: command not found . WTF?

Всё логично — по умолчанию runner’ы (отвечающие за исполнение скриптов задач, и предоставляемые GitLab’ом) используют bash для исполнения команд. Можно исправить это дело, явно указав в описании задачи, какие теги должны быть у исполняющего пайплайн раннера:
```
dummy job on windows: script: - echo ok tags: - windows
```
Отлично! Теперь пайплайн выполняется.

Внимательный читатель, повторив указанные шаги, заметит, что задача выполнилась в этапе test , хотя мы не указывали этап. Как можно догадаться, test является этапом по умолчанию.

Продолжим создание скелета конфигурации, добавив все задачи, описанные выше:
```
build job: script: - echo "building. " tags: - windows stage: build test and cover job: script: - echo "running tests and coverage analysis. " tags: - windows stage: test pack and deploy job: script: - echo "packing and pushing to nuget. " tags: - windows stage: deploy pages: script: - echo "creating docs. " tags: - windows stage: deploy
```
Получили не особенно функциональный, но тем не менее корректный пайплайн.

Настройка триггеров

Из-за того, что ни для одной из задач не указаны фильтры срабатывания, пайплайн будет полностью исполняться при каждой отправке коммитов в репозиторий. Так как это не является желаемым поведением в общем случае, мы настроим фильтры срабатывания для задач.

Фильтры могут настраиваться в двух форматах: only/except и rules. Вкратце, only/except позволяет настраивать фильтры по триггерам ( merge_request , например — настраивает задачу на выполнение при каждом создании запроса на слияние и при каждой отправке коммитов в ветку, являющуюся исходной в запросе на слияние) и именам веток (в т.ч. с использованием регулярных выражений); rules позволяет настраивать набор условий и, опционально, изменять условие выполнения задачи в зависимости от успеха предшествующих задач ( when в GitLab CI/CD).

Вспомним набор требований — сборка и тестирование только для merge request, упаковка и отправка в Azure DevOps — для merge request и пушей в мастер, генерация документации — для пушей в мастер.

Для начала настроим задачу сборки кода, добавив правило срабатывания только при merge request:
```
build job: # snip only: - merge_request
```
Теперь настроим задачу упаковки на срабатывания на merge request и добавление коммитов в мастер:
```
pack and deploy job: # snip only: - merge_request - master
```
Как видно, всё просто и прямолинейно.

Также можно настроить задачу на срабатывание только если создан merge request с определённой целевой или исходной веткой:
```
 rules: - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"
```
В условиях можно использовать перечисленные здесь переменные; правила rules не совместимы с правилами only/except .

Настройка сохранения артефактов

Во время выполнения задачи build job у нас будут созданы артефакты сборки, которые можно переиспользовать в последующих задачах. Для этого нужно в конфигурацию задачи добавить пути, файлы по которым нужно будет сохранить и переиспользовать в следующих задачах, в ключ artifacts :
```
build job: # snip artifacts: paths: - path/to/build/artifacts - another/path - MyCoolLib.*/bin/Release/*
```
Пути поддерживают wildcards, что определённо упрощает их задание.

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

Теперь, когда у нас готов (и проверен) каркас конфигурации, можно переходить собственно к написанию скриптов для задач.

Пишем скрипты

Возможно, когда-то давно, в далёкой-далёкой галактике, собирать проекты (в том числе и на .net) из командной строки было болью. Сейчас же собрать, протестировать и опубликовать проект можно в 3 команды:
```
dotnet build dotnet test dotnet pack
```
Естественно, есть некоторые нюансы, из-за которых мы несколько усложним команды.
1. Мы хотим релизную, а не отладочную сборку, поэтому к каждой команде добавляем -c Release
2. При тестировании мы хотим собирать данные о покрытии кода, поэтому потребуется подключить анализатор покрытия в тестовые библиотеки:
  1. Во все тестовые библиотеки следует добавить пакет coverlet.msbuild : dotnet add package coverlet.msbuild из папки проекта
  2. В команду запуска тестов добавим /p:CollectCoverage=true
  3. В конфигурацию задачи тестирования добавим ключ для получения результатов покрытия (см. ниже)
  Собираем данные покрытия кода
  
  Coverlet после запуска тестов выводит в консоль статистику по запуску:
```
Calculating coverage result. Generating report 'C:\Users\xxx\source\repos\my-project\myProject.tests\coverage.json' +-------------+--------+--------+--------+ | Module | Line | Branch | Method | +-------------+--------+--------+--------+ | project 1 | 83,24% | 66,66% | 92,1% | +-------------+--------+--------+--------+ | project 2 | 87,5% | 50% | 100% | +-------------+--------+--------+--------+ | project 3 | 100% | 83,33% | 100% | +-------------+--------+--------+--------+ +---------+--------+--------+--------+ | | Line | Branch | Method | +---------+--------+--------+--------+ | Total | 84,27% | 65,76% | 92,94% | +---------+--------+--------+--------+ | Average | 90,24% | 66,66% | 97,36% | +---------+--------+--------+--------+
```
  GitLab позволяет указать регулярное выражение для получения статистики, которую потом можно получить в виде бейджа. Регулярное выражение указывается в настройках задачи с ключом coverage ; в выражении должна присутствовать capture-группа, значение которой и будет передано в бейдж:
```
test and cover job: # snip coverage: /\|\s*Total\s*\|\s*(\d+[,.]\d+%)/
```
  Здесь мы получаем статистику из строки с общим покрытием по линиям.
  
  Публикуем пакеты и документацию
  
  Оба действия у нас назначены на последний этап пайплайна — раз уж сборка и тесты прошли, можно и поделиться с миром наработками.
  
  Для начала рассмотрим публикацию в источник пакетов:
  1. Если в проекте не присутствует файл конфигурации nuget ( nuget.config ), создадим новый: dotnet new nugetconfig
    Зачем: в образе может быть запрещён доступ на запись к глобальным (пользовательской и машинной) конфигурациям. Чтобы не ловить ошибки, просто создадим новую локальную конфигурацию и будем работать с ней.
  2. Добавим в локальную конфигурацию новый источник пакетов: nuget sources add -name -source -username -password -configfile nuget.config -StorePasswordInClearText
    1. name — локальное имя источника, не приниципиально
    2. url — URL источника из этапа «Готовим аккаунты», п. 6
    3. organization — название организации в Azure DevOps
    4. gitlab variable — имя переменной с токеном доступа, добавленной в GitLab («Готовим аккаунты», п. 11). Естественно, в формате $variableName
    5. -StorePasswordInClearText — хак для обхода ошибки отказа в доступе (не я первый на эти грабли наступил)
    6. На случай ошибок может быть полезным добавить -verbosity detailed
    1. Отправляем все пакеты из текущей директории, поэтому *.nupkg .
    2. name — из шага выше.
    3. key — любая строка. В Azure DevOps в окне Connect to feed всегда в качестве примера приводят строку az .
    4. -skipduplicate — при попытке отправить уже существующий пакет без этого ключа источник вернёт ошибку 409 Conflict ; с ключом отправка будет пропущена.
    Теперь настроим создание документации:
    1. Для начала, в репозитории, в ветке master, инициализируем проект docfx. Для этого из корня надо выполнить команду docfx init и в интерактивном режиме зададим ключевые параметры для сборки документации. Подробное описание минимальной настройки проекта здесь.
      1. При настройке важно указать выходную директорию ..\public — GitLab по умолчанию берёт содержимое папки public в корне репозитория как источник для Pages. Т.к. проект будет располагаться во вложенной в репозиторий папке — добавляем в путь выход на уровень вверх.
      1. Скрипт:
        
        nuget install docfx.console -version 2.51.0 — установит docfx; версия указана для гарантии правильности путей установки пакета.
        
        .\docfx.console.2.51.0\tools\docfx.exe .\docfx_project\docfx.json — собираем документацию
        
        pages: # snip artifacts: paths: - public
        
        Лирическое отступление про docfx
        
        Раньше при настройке проекта я указывал источник кода для документации как файл решения. Основной минус — документация создаётся и для тестовых проектов. В случае, если это не нужно, можно задать такое значение узлу metadata.src :
        
        < "metadata": [ < "src": [ < "src": "../", "files": [ "**/*.csproj" ], "exclude":[ "*.tests*/**" ] >], // --- snip --- >, // --- snip --- ], // --- snip --- >
        
        metadata.src.src: «../» — выходим на уровень вверх относительно расположения docfx.json , т.к. в паттернах не работает поиск вверх по дереву директорий.
        
        metadata.src.files: [«**/*.csproj»] — глобальный паттерн, собираем все проекты C# из всех директорий.
        
        metadata.src.exclude: [«*.tests*/**»] — глобальный паттерн, исключаем всё из папок с .tests в названии
        
        Промежуточный итог
        
        Вот такую простую конфигурацию можно составить буквально за полчаса и пару чашек кофе, которая позволит при каждом запросе слияния и отправке в мастер проверять, что код собирается и тесты проходят, собирать новый пакет, обновлять документацию и радовать глаз красивыми бейджиками в README проекта.
        
        Итоговый .gitlab-ci.yml
        
        image: mcr.microsoft.com/dotnet/core/sdk:3.1 before_script: - $PSVersionTable.PSVersion - dotnet --version - nuget help | select-string Version stages: - build - test - deploy build job: stage: build script: - dotnet build -c Release tags: - windows only: - merge_requests - master artifacts: paths: - your/path/to/binaries test and cover job: stage: test tags: - windows script: - dotnet test -c Release /p:CollectCoverage=true coverage: /\|\s*Total\s*\|\s*(\d+[,.]\d+%)/ only: - merge_requests - master pack and deploy job: stage: deploy tags: - windows script: - dotnet pack -c Release -o . - dotnet new nugetconfig - nuget sources add -name feedName -source https://pkgs.dev.azure.com/your-organization/_packaging/your-feed/nuget/v3/index.json -username your-organization -password $nugetFeedToken -configfile nuget.config -StorePasswordInClearText - nuget push -source feedName -skipduplicate -apikey az *.nupkg only: - master pages: tags: - windows stage: deploy script: - nuget install docfx.console -version 2.51.0 - $env:path = "$env:path;$($(get-location).Path)" - .\docfx.console.2.51.0\tools\docfx.exe .\docfx\docfx.json artifacts: paths: - public only: - master
        
        Кстати о бейджиках
        
        Ради них ведь всё и затевалось!
        
        Бейджи со статусами пайплайна и покрытием кода доступны в GitLab в настройках CI/CD в блоке Gtntral pipelines:
        
        Бейдж со ссылкой на документацию я создавал на платформе Shields.io — там всё достаточно прямолинейно, можно создать свой бейдж и получать его с помощью запроса.
        
        ![Пример с Shields.io](https://img.shields.io/badge/custom-badge-blue)
        
        Azure DevOps Artifacts также позволяет создавать бейджи для пакетов с указанием актуальной версии. Для этого в источнике на сайте Azure DevOps нужно нажать на Create badge у выбранного пакета и скопировать markdown-разметку:
        
        Добавляем красоты
        
        Выделяем общие фрагменты конфигурации
        
        Во время написания конфигурации и поисков по документации, я наткнулся на интересную возможность YAML — переиспользование фрагментов.
        
        Как видно из настроек задач, все они требуют наличия тега windows у раннера, и срабатывают при отправке в мастер/создании запроса на слияние (кроме документации). Добавим это во фрагмент, который будем переиспользовать:
        
        .common_tags: &common_tags tags: - windows .common_only: &common_only only: - merge_requests - master
        
        И теперь в описании задачи можем вставить объявленный ранее фрагмент:
        
        build job:
        Названия фрагментов должны начинаться с точки, чтобы не быть интерпретированными как задача. Версионирование пакетов При создании пакета компилятор проверяет ключи командной строки, и в их отсутствие — файлы проектов; найдя узел Version, он берёт его значение как версию собираемого пакета. Выходит, чтобы собрать пакет с новой версией, нужно либо обновить её в файле проекта, либо передать как аргумент командной строки. Добавим ещё одну хотелку — пусть младшие два номера в версии будут годом и датой сборки пакета, и добавим пререлизные версии. Добавлять эти данные в файл проекта и проверять перед каждой отправкой можно, конечно — но можно ведь это делать и в пайплайне, собирая версию пакета из контекста и передавая через аргумент командной строки. Условимся, что если в сообщении коммита есть строка вида release (v./ver./version) (rev./revision )? , то мы будем из этой строки брать версию пакета, дополнять её текущей датой и передавать как аргумент команде dotnet pack . В отсутствие строки — просто не будем собирать пакет. Данную задачу решает следующий скрипт: # регулярное выражение для поиска строки с версией $rx # ищем строку в сообщении коммита, передаваемом в одной из предопределяемых GitLab'ом переменных $found = $env:CI_COMMIT_MESSAGE -match $rx # совпадений нет - выходим if (!$found) < Write-Output "no release info found, aborting"; exit ># извлекаем мажорную и минорную версии $maj = $matches['maj'] $min = $matches['min'] # если строка содержит номер релиза - используем его, иначе - текущий год if ($matches.ContainsKey('rel')) < $rel = $matches['rel'] >else < $rel = ".$(get-date -format "yyyy")" ># в качестве номера сборки - текущие месяц и день $bld = $(get-date -format "MMdd") # если есть данные по пререлизной версии - включаем их в версию if ($matches.ContainsKey('rev')) < $rev = "-$($matches['rev'])" >else < $rev = '' ># собираем единую строку версии $version = "$maj$min$rel.$bld$rev" # собираем пакеты dotnet pack -c Release -o . /p:Version=$version Добавляем скрипт в задачу pack and deploy job и наблюдаем сборку пакетов строго при наличии заданной строки в сообщении коммита. Итого Потратив примерно полчаса-час времени на написание конфигурации, отладку в локальном powershell и, возможно, пару неудачных запусков, мы получили несложную конфигурацию для автоматизации рутинных задач. Конечно, GitLab CI/CD гораздо обширнее и многограннее, чем может показаться после прочтения этого руководства — это совершенно не так. Там даже Auto DevOps есть, позволяющий automatically detect, build, test, deploy, and monitor your applications Теперь в планах — сконфигурировать пайплайн для развёртывания приложений в Azure, с использованием Pulumi и автоматическим определением целевого окружения, что будет освещено в следующей статье. Кровь, пот и GIT Ведущий разработчик 1С Андрей Карпов на конференции Infostart Event 2021 Post-Apocalypse поделился ошибками, которые совершают новички в работе с GIT. В докладе четыре кейса с пошаговыми инструкциями, которые позволят не допускать конфликтов в разработке. GIT – это система для хранения и ведения истории изменения файлов. Это своего рода аналог хранилища 1С, но со своими особенностями и ограничениями. Большинство статей о GIT демонстрируют только процесс его первоначальной настройки и подключения. Они не показывают, с какими проблемами столкнулись авторы во время его использования, как их решали, и какие нехорошие мысли у них возникали в процессе. Как обычно внедряется GIT Как обычно внедряется GIT: фаза 1 – внедрили GIT; фаза 2 – ? фаза 3 – все отлично. Так хочется узнать, что скрывается под этим вопросом во второй фазе. В этом докладе на примере истории разработчика Андрюши мы пройдемся по примерам использования GIT на практике и разберем основные ошибки, с этим связанные. Чтобы не возникало вопросов, давайте определимся с терминологией. Репозиторий – это каталог, где хранятся все версионируемые данные GIT. Commit – это фиксация текущих изменений и внесение их в историю вашей ветки. Конфликт – это ситуация, возникающая при объединении веток, когда изменения есть и с той, и с другой стороны. При этом GIT объединить их в автоматическом режиме не может. Merge – объединение одной ветки GIT с другой. Pull request – запрос на добавление ваших изменений в другую ветку. Он используется в том случае, если вам запрещен доступ для обновления через commit (пул-реквесты часто используются для объединения веток master и develop). Дисклеймер: образ Андрюши является собирательным. Все возможные совпадения с реальным человеком случайны. На слайде разработчик Андрюша. У него есть мечта – разрабатывать правильно, в большом коллективе единомышленников, и чтобы каждый был доволен процессом. В свои молодые годы Андрюша уже “осознал” каково это – использовать хранилище 1С на практике. А может и вы сталкивались с таким? Не приходилось ли вам восстанавливать затертые доработки форм в хранилище? Или, может, просили “корень” у коллеги? А может быть, у вас была доработка одного и того же объекта? Из-за таких вот ситуаций казалось, что GIT – это решение всех проблем. Рекомендации для разработки через хранилище Некоторые возразят, что хранилище 1С – это очень удобный инструмент, просто нужно грамотно настроить процесс разработки. Например: не захватывать надолго корень конфигурации; либо захватывать объекты только перед помещением в хранилище; или вообще воспользоваться рекомендациями фирмы 1С «Технология разветвленной разработки». И с этим можно согласиться, но спишем стремление нашего молодого человека к GIT на его неопытность и желание опробовать новый инструментарий. По счастливой случайности, а может и божественному провидению, Андрюша все же нашел ту самую “компанию мечты”, где 1С-ники недавно отказались от хранилища 1С в пользу использования GIT и вместе с нашим Андрюшей им предстояло пройти тернистый путь командной разработки. В процессе разработки поддерживалось две конфигурации. Жутко старый «Документооборот» еще первой версии, который был подключен к хранилищу; 1С:ERP, разработка которой перешла на GIT. Сам процесс разработки велся по SCRUM. У каждого разработчика были собственные базы, которые они могли сами актуализировать из копии продуктива. Помимо этого, использовался: Redmine – для учета задач и трудозатрат; Bamboo – для тестирования, формирования релизов и дополнительных служебных операций (в частности, для обновлений баз разработчиков); сервер Bitbucket, как система для версионирования, хранения и рецензирования кода; GIT Extension – локальный клиент для GIT. Он удобен тем, что бесплатный, имеет простой и удобный интерфейс, логирует действия пользователей и не вылетает при большом количестве файлов в одном коммите. Конечно же, все эти системы были на английском языке, ведь нужно приучаться к культуре тру-девелоперов и расширять свой словарный запас словечками: мердж, пул, фича и так далее. Как выглядит схема ветвления GIT и какие данные можно поместить Схема ветвления веток GIT похожа на GitFlow: основная ветка «develope», от нее формировались задачи «feature», соответствующие номерам задач из Redmine; при выполнении задачи, разработчик мерджил эту ветку с веткой «test»; ветка «test» была подключена к отдельной базе, на которой отдел сопровождения проверял доработки; после проверки ветку разработчика объединяли с веткой «develope»; раз в день, после проведения автоматизированных тестов, ветку «develope» объединяли уже с веткой «master», и из нее формировался релиз, который загружался в продуктив; помимо этого существовала ветка «origin1c» – в ней была размещена конфигурация поставки, ее использовали для обновления конфигураций через GIT и для сравнения, чем модуль из «develope» отличается от типового. Версионировались не только файлы конфигурации, но и расширения, внешние отчеты, обработки и правила обмена: Внешние отчеты и обработки выгружались стандартным способом через пакетный режим конфигуратора. Правила обмена – для выгрузки использовалась утилита Gitrules, разработанная Олегом Тымко. Утилиту пришлось немного доработать, добавив поддержку выгрузки не только правил конвертации, но и правил регистраций и их сборку. Конфигурация и Расширения. Раньше они выгружались стандартным способом через команду «Выгрузить конфигурацию в файлы», но разработчики вскоре перешли на другое решение – утилиту автономного сервера ibcmd. Утилита не требует лицензии 1С и не блокирует конфигуратор при выгрузке конфигурации в файлы, что позволяет при выгрузке одновременно работать и в конфигураторе. Плюс она не зависит от самого автономного сервера и ее можно использовать отдельно. Пример команды для выгрузки конфигурации в файлы с помощью утилиты: "C:\Program Files (x86)\1cv8\8.3.18.1334\bin\ibcmd.exe" infobase --dbms=MSSQLServer --db-server="Имя сервера" --db-name="Имя базы" --db-user="Имя пользователя SQL" --db-pwd="Пароль пользователя SQL" config export "Путь к репозиторию GIT" --base="Путь к ConfigDumpInfo.xml" В таком процессе и начались рабочие будни нашего Андрюши. Все было бы хорошо, и можно было бы сказать, что GIT – это удобный и практичный инструмент, но точно не для 1C:ERP. В ней все очень тормозило: переключение между ветками, сравнение 2-х коммитов или веток. Неприятной проблемой стало обновление на новый релиз – при этом коммитился cf-файл поставки, и в изменения попадали сразу все объекты конфигурации. Разработчиков это сильно не устраивало. Стали искать способы ускорения - один из них стал GIT LFS. GIT LFS – это расширение для GIT, которое преобразует выбранные файлы в текстовые ссылки, перемещая их в отдельное хранилище. После этого размер репозитория существенно сокращался. Но GIT LFS нужно настраивать сразу при первым коммитом, иначе придется создавать отдельный репозиторий и перемещать туда всю историю изменений – при этом каждый коммит тогда необходимо обрабатывать дополнительно, чтобы он перемещался в GIT LFS. Таким образом в GIT LFS были перемещены все бинарные общие макеты конфигурации и сам cf-файл поставки. Общая схема выглядела так: включаем GIT LFS на сервере Bitbucket; на рабочем месте разработчика устанавливаем расширение https://git-lfs.github.com/ , сейчас git-lfs уже включен в дистрибутив git по умолчанию; в консоли репозитория прописываем команду git lfs install указываем список файлов, которые необходимо отслеживать, командой git lfs track "*.cf" git lfs track "/Config/CommonTemplates/*/Ext/*.bin" Стоит обратить внимание, что GIT LFS по факту удаляет файлы из каталога. Чтобы корректно загрузить конфигурацию из файлов, необходимо вначале получить их из центрального хранилища командой: git lfs fetch --all И заменить текстовые ссылки на реальные файлы командой: git lfs checkout Популярные задачи с GIT, частые ошибки и их решение Задача №1: перенести из актуального релиза новый регламентированный отчет Андрюше поручили перенести из актуального релиза новый регламентированный отчет по 6-НДФЛ. Да так, чтобы все объекты при обновлении сопоставились. Как хороший разработчик, Андрюша знал, что для корректного обновления объекты должны иметь такие же идентификаторы, что и типовые. Для этого он сравнил и объединил с конфигурацией релиза, отметил отчет для объединения и выгрузил изменения в Git. Задача отправилась на тестирование и прошла его. Позже конфигурацию на сервере обновили до актуального релиза – для этого объединили ветку «origin1c» с «develop». Однако конфигурационный файл с релизом после всех этих доработок сформировать не удалось, потому что задублировались метаданные отчетов. В чем же была причина? Ошибка: весь список метаданных в выгруженном виде содержится в одном файле configuration.xml. Когда Андрюша добавил новый отчет, он был автоматически добавлен в конец этого списка. В релизе же все файлы хранятся по алфавиту. А GIT работает с 1С, как с текстом. Доработка и добавление Андрюшей нового отчета и вендором, рассматривались как две разные доработки, так как были добавлены в разные места одного и того же файла. И при этом даже конфликтов не возникало. Решение: вручную отредактировать файл Configuration.xml, удалив задублированные метаданные. Чтобы ситуация не повторялась, необходимо: либо перед выгрузкой конфигурацией файла, отсортировать метаданные конфигуратором по алфавиту; либо сделать специальный скрипт, который бы обходил все выгруженные файлы и делал бы автоматическую сортировку перед коммитом. Способы сохранения ConfigDumpIngo.xml Объекты из 1С попадают в GIT с помощью команды конфигуратора «Выгрузить конфигурацию в файлы». Чтобы выгрузка проходила быстрее, разработчики 1С в версии платформы 8.3.10 добавили возможность инкрементальной выгрузки. При этом формируется файл ConfigDumpInfo.xml, в котором содержатся идентификаторы всех выгружаемых объектов. Если в процессе разработки объект меняется, меняется и его идентификатор – таким образом, платформа может отследить, что именно изменилось, чтобы выгрузить только изменения. В теории, по сравнению с тем, что раньше нужно было всегда выгружать всю конфигурацию, это выглядело хорошим решением. Но на практике вам надо заботиться об этом файле: холить и лелеять его. Не дай Бог, 1С посчитает его не актуальным. Тогда начнется выгрузка всей конфигурации. ConfigDumpInfo.xml – это файл Шредингера. Его наличие в репозитории обязательно, но его нежелательно коммитить. Иначе он попадет в конфликты при объединении. И добавить в .gitignore нельзя, так как тогда он пропадет из видимости репозитория, и ты не поймешь, есть он в каталоге, или нет. Самое забавное, что возможность сформировать этот файл вручную разработчики платформы добавили только спустя два года от появления инкрементальной выгрузки – в версии платформы 8.3.15: для этого необходимо запускать конфигуратор в пакетном режиме с командой «load-config-from-files» и параметром «--update-config-dump-info only»; либо воспользоваться утилитой автономного сервера ibcmd и выгружать с помощью режима «infobase config export info». До выхода релиза 8.3.15, разработчикам пришлось сделать скрипт, который бы сравнивал два коммита, а разницу загружал в конфигурацию. При этом автоматически формировался актуальный ConfigDumpInfo.xml. Этот файл ConfigDumpInfo.xml они прятали из видимости GIT с помощью команды git stash – она перемещает выбранный файл в специальное отдельное хранилище, не добавляя в репозиторий. Из хранилища его можно доставать командой git stash pop. Единственное ограничение – чтобы git stash работал - надо один раз поместить configdumpinfo.xml в коммит репозитория. Если вы не сумели сформировать ConfigDumpInfo или забыли его застэшить, вам предстоит увлекательное мероприятие по поиску своих изменений в списке измененных файлов полной выгрузки конфигурации Так как требуется помещать только свои изменения, по лишним файлам придется откатить изменения, а вероятность случайно затронуть и затереть свои доработки при этом очень высока. Задача №2: создать «ОченьВажныйСправочник» Следующий пример. Андрюша разработал справочник, выгрузил изменения в GIT и отправил задачу на тестирование. Пока справочник тестировали, на сервере разработки обновили релиз типовой конфигурации и поменяли версию платформы с 8.3.15 на 8.3.16 – сборка релиза проходила на актуальной версии платформы. Протестированную задачу Андрюши тоже отправили в рабочую базу, но при этом произошел конфликт версий xml. Ошибка: в основном, файлы 1С в выгруженном виде представляют собой XML. В зависимости от версии платформы, структура XML для одного и того же объекта может меняться. Чтобы отслеживать версию структуры, разработчики платформы добавили при выгрузке дополнительный признак version. При слиянии типового релиза и изменений Андрюши как раз произошел конфликт этих версий, т.к. у Андрюши справочник был добавлен в более старой версии платформы, а после перехода на новую версию, этот файл тоже изменился – его версия поменялась. Решение: для правильного решения, Андрюше пришлось бы взять ветку до обновления и загрузить конфигурацию из файлов с этим обновлением. После этого сделать мердж его ветки с веткой «develope» с актуальным релизом. И заново выгрузить конфигурацию в файлы. При этом 1С обновит структуру метаданных в соответствии с новым форматом. И тогда уже можно делать пул-реквест. Однако кто в здравом уме будет этим заниматься? Достаточно просто вручную поменять версию XML через блокнот. Ошибок совместимости при этом не замечено. Задача №3: исправить ошибку версии формата XML С переходом на GIT появилась возможность редактировать конфигурацию, не прибегая к конфигуратору. Ведь правильно, зачем нам такая громоздкая IDE, если есть Notepad++ или Visual Studio Code? С более мелкими задачами они прекрасно справляются. Вернемся к задаче про справочник. Хитрый и ленивый Андрюша, чтобы исправить версию XML, решил воспользоваться глобальным поиском Visual Studio Code. Правда, когда коммитил, заметил небольшую странность – текст запроса динамического списка почему-то отображался, как «измененный». Хотя никаких изменений он не вносил. «Видимо глюк», подумал Андрюша GIT, и смело отправил задачу на тестирование. За такие смелые и быстрые решения его уже стали считать косячником. Но как ни странно, у Андрюши получилось сформировать конфигурацию. Однако ошибка есть. Она не существенная: в рамках текущей задачи ни на что не влияет. Андрюше не пришлось краснеть перед коллегами. Возможная ошибка: Ошибка из-за преобразования переносов строк LF и CRLF. Проблема была бы, если бы изменения внесли в типовые объекты конфигурации. Редактор VS Code автоматически преобразовывает переносы строк LF и CRLF к единому стилю, которые соответствуют форматам Linux и Windows. То, что Андрюша увидел как глюк GIT – это, на самом деле, было преобразованием формата переноса строк Linux на формат Windows. Решение: откатиться на предыдущую версию файла через GIT; либо написать специальный скрипт, который обходил бы все незакоммиченные файлы. Он бы подменял точечно некорректные переносы в тегах с многострочным текстом на корректный перенос строк; либо оставить все как есть. Главное знать, что могут быть проблемы с зарплатными модулями – других проблем не будет; и еще в GIT можно настроить автоматическое преобразование переносов строк. В GIT нет попроцедурного сравнения. С этим просто надо смириться. Реализовать сравнение модулей как в конфигураторе никак не получится. Задача №4: сменить неприятное имя документа и добавить верхний регистр Андрюша увидел, что «ОченьважныйДокументДляУчета» называется неправильно, нарушая стандарт CamelCase – буква «в» должна быть в верхнем регистре. Руководствуясь благими намерениями, он поправил букву. Однако в GIT отобразились только два измененных файла: файл Configuration и сам объект, хотя должно быть больше. Не чувствуя подвоха, Андрюша отправил задачу на тестирование. Тестирование она не прошла. Ошибка: проблема встречалась только на старых версиях GIT, потому что он не понимал смену регистра букв в именах файлов на файловых системах NTFS и Fat32. А регистронезависимая 1С все-таки учитывает регистр букв, но только в том случае, когда обходит список метаданных в файле Configuration. 1С ищет каталоги соответствующие точно этому списку. Важные документы для учета, которые были уже в правильном регистре, она просто не находила. Решение: необходимо воспользоваться консолью GIT и переименовать файл через консоль с параметром -f командой git mv filename.txt FileName.txt -f Он вносит эти изменения насильно, чтобы это фиксировалось в GIT. В команде Андрюши все формы редактировались программно. На это были объективные причины, так как, если это сделать интерактивно, возникали проблемы. Например, в таблицу товаров документа реализации добавили колонку «Себестоимость». Если колонку на форму добавить интерактивно, все выгрузится в GIT, протестируется и отправится в продуктив. Но ручное редактирование форм может привести к неприятным последствиям: Стоит фирме «1С» что-то поменять в этой таблице, в тех местах, где были сделаны доработки, появится конфликт, который придется решать в текстовом редакторе вручную, что влечет за собой высокую вероятность ошибки при некорректном мердже. Хотя, если у вас прямые руки и хорошее воображение, все пройдет замечательно. Однако конфликт может и не появиться, и тогда GIT объединит все изменения в автоматическом режиме. При этом он может нарушить структуру метаданных XML и при загрузке конфигураций из файлов, конфигуратор будет просто вылетать. Некоторые скажут, что нужно использовать расширения для редактирования форм. С этим можно согласиться, но: расширение также выгружается в GIT в виде XML-файлов, и теряется наглядность понимания, что именно поменялось на форме; разработчики не раз сталкивались с тем, что когда нажимаешь кнопку «Обновить форму», в захваченной форме слетал фильтр измененных объектов. Измененными становились сразу все объекты. И тогда уже не понять, что именно было доработано. Также в GIT есть механизм автоматического переименования файлов: в одном коммитe ищется удаленный или/и добавленный файл с одинаковым расширением и определенным уровнем схожести. Это может привести к ситуации, когда общий модуль преобразуется в общую команду. Это вроде как забавно, пока не появляется конфликт, и нужно определить, что же является источником. Как убрать такое поведение GIT, Андрюша просто не знал. Он привык, что в каждой системе для каждого параметра есть соответствующий флажок и галочка, как в 1С. Но в GIT он ничего такого не нашел: ни в Git Extensions, ни на форумах разработчиков. Ситуация разрешилась случайно. Блуждая по интернету, он забрел на официальный сайт платформы EDT, где на одной из страниц был текст: «Для комфортной работы воспользуйтесь следующими настройками». Последние два параметра как раз и убирают поиск переименования в GIT. Мораль: не будьте Андрюшами и читайте документацию. Наверное вы заметили, что здесь практически не упоминается EDT. Это связано с тем, что в компании Андрюши его практически не использовали. Были попытки перейти, но если для менее большой конфигурации его можно нормально использовать, то для ERP все сильно тормозило. Все плюсы перечеркивались невозможностью такой работы. Итоги Прошли месяцы. Если вы решили, что Андрюша сбежал, то это не так. Хотя и описанные в докладе проблемы позволяют думать, что GIT – это пытка, но Андрюша уже привык. Он прокачался – ему уже не резали слух иностранные термины, он мог вручную отредактировать коммиты, не внося изменения в конфигуратор, и отсечь чужие доработки, чтобы избежать конфликтов с его доработками. Смотря на себя из прошлого, он понял, каким был наивным идеалистом: не бывает волшебной кнопки, которая все делает за тебя. Отмечу, что на GIT очень тяжело перейти, так как это требует больше знаний и большего понимания всех процессов. И тогда некоторые разработчики скажут: «Ну и зачем нам тогда GIT?» Так данный доклад и не агитирует переходить на GIT. Это просто инструмент, который вы используете. Но надо знать, что у него есть определенные плюсы. В отличие от хранилища, GIT позволяет работать с большим пулом задач, когда: часть задач на тестировании; часть в разработке; а часть ждет, когда ты к ним вернешься, спустя полгода. Если рассматривать такую доработку не через GIT, то для каждой мало-мальски крупной задачи приходится создавать отдельное хранилище. В заключении, не совершайте ошибок, которые описаны в докладе, а совершайте свои и делитесь их решением с сообществом. Вопросы. На последней картинке с коммитами GIT я не увидел нормального описания, что сделал разработчик. Я бы посоветовал в тексте описания коммита все-таки писать, что сделал разработчик. Это так исторически сложилось, потому что настроен специальный скрипт, который парсит эту строку и автоматически закрывает задачи в Redmine. Он немного криво сделан, поэтому нельзя туда добавлять дополнительный текст, кроме стандартного. Какая конфигурация компьютера использовалась у разработчика? И почему он не мог использовать EDT для разработки ERP? Был достаточно мощный удаленный сервер – 240 Гб оперативной памяти. Но поскольку это удаленный сервер, на нем одновременно через RDP работало много разработчиков, и в EDT тормозила даже контекстная подсказка – в таких условиях работать было невозможно. На сайте 1С есть рекомендации по серверам для малых, больших и очень больших конфигураций. Если брать для ERP конфигурацию компьютера, на которой была запущена EDT, то это минимум 16 гигов оперативной памяти и все на SSD дисках. При нормальной конфигурации компьютера это рабочий вариант. Но да, не для RDP, а на одного человека. Для ЗУПа, для Бухгалтерии, для домашнего компьютера с 32-гиговой оперативкой, я использовал EDT, но на рабочем сервере это было проблематично. Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse. 30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на котором прозвучит 130+ докладов. Темы конференции: Работа с данными: архитектура, интеграции, отчеты. Программная инженерия. Решения 1С: архитектура, учет и практические задачи. Управление проектом. Управление продуктом. Soft skills, управление командой проекта. Кейсы автоматизации на 1С Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами! См. также Системы контроля версий для 1С-разработчиков. Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8 29.06.2022 7437 67 4 93 67 4 7437 Работа с GitLab API Работа с API GitLab на примере запуска pipeline с переменными, отслеживания его статуса и загрузкой полученных артефактов. 1 стартмани 06.10.2023 430 0 itsys 0 Наш путь в Git – история одного внедрения CI/CD Чтобы перейти от разработки в хранилище до полноценного релизного цикла CI/CD, с автотестированием кода, сборкой конфигураций из исходников и ветками разработки для каждой задачи, нужно пройти большой путь. Расскажем о том, как организовать полностью автоматическую доставку проверенного и рабочего кода в 2000 конфигураций. 02.10.2023 2547 MrWonder 4 Jenkins на службе 1С Основная специализация Jenkins – это, прежде всего, CI/CD. Но его можно использовать и для других важных задач: разбора хранилищ, настройки копий баз данных, раздачи прав пользователям, рестарта кластера и проверки кода проектов. 19.07.2023 1458 yukon 4 Приемы быстрой работы в EDT/Git Статья даёт ответы на некоторые вопросы, возникающие у разработчиков, которые погружаются в океан технологий EDT и Git, омывающий царство DevOps. Сколько и какие ветки нужны? Какой репозиторий выбрать? Кто должен сливать доработки в мастер ветку или ветку версии? Как не тратить время в EDT на ресурсоёмких операциях? Зачем нам сборочный конвейер и как его построить? Зачем нам нужно тестирование и как его реализовать? Как вести разработку, если есть разработчики, не умеющие вести разработку в EDT или не имеющие технической возможности, но нам нужны их skills в 1С? Что такое фантомы и нужно ли с ними бороться? Как слить 20 доработок с конфликтами и уложиться в 4 часа? Опыт использования модных технологий в реальных проектах. 30.03.2023 6723 check2 10 85 10 6723 Получаем статистику по git-репозиторию в разрезе разработчиков Итак! Представим, что наступил момент, когда разработка через исходный код реализована на предприятии в полном объеме. Мы разрабатываем в EDT или конфигураторе (но выгружаем конфигурацию в исходный код), версионируем внешние отчеты и обработки и расширения, собираем релизы, проверяем код статическим анализом, в разработке царит гармония и мир. Красота! Но менеджерам этого мало, всегда хочется чего-то еще, и вот мне прилетает задача - дай статистику по вкладу в код каждого разработчика. 13.03.2023 2163 ardn 3 Формула успешного внедрения DevOps и Agile в 1С: от неудачи к неудаче без потери энтузиазма На конференции Infostart Event 2021 Post-Apocalypse выступил директор практики БИТ:ERP компании Первый БИТ Глеб Стальной. В ходе доклада он рассмотрел трансформацию проектного подхода в продуктовый, рассказал про имплементацию «современных» практик DevOps и продемонстрировал инструменты для разработки, взаимодействия с бизнесом и клиентами, применяемые в его команде. 27.02.2023 1799 0 glebushka 2 13 0 2 1799 Прокси хранилища 1С (IIS, OneScript) Избавляемся от версионной зависимости, проверяем комментарии, вызываем веб-хуки, делаем красивые пути. И все это на привычном IIS и понятном OneScript. 08.12.2022 6718 kamisov 56 92 56 6718 Посмотреть ещё Комментарии Дата Дата Рейтинг всех уровней Рейтинг 1-го уровня Древо развёрнутое Древо свернутое Свернуть все 1. kuzyara 1779 17.01.23 12:12 Сейчас в теме > GIT Extension Рекомендую попробовать gitkraken 2. karpik666 824 17.01.23 12:29 Сейчас в теме (1) пробовал, очень красивый, только интерфейсно показался сильно не привычным, и так и не нашел где можно запускать произвольные скрипты прямо из интерфейса, плюс он вроде платный 3. Segate 207 17.01.23 14:04 Сейчас в теме (1) Vsode наше все ) Зачем еще что-то, когда в иде есть отличный гит клиент ) 4. karpik666 824 17.01.23 14:18 Сейчас в теме (3) vscode также используем, с подсветкой синтаксиса 1С, но это все равно целиком не заменит работу с конфигуратором, это хорошее дополнение, но не его полная замена, имхо. 5. Segate 207 17.01.23 14:20 Сейчас в теме (4) Ни в коем случае это не заменит конфигуратор. Но вот другой гит клиент -имхо ни к чему ) 6. karpik666 824 17.01.23 14:24 Сейчас в теме (5) все-таки не соглашусь, git клиент как расширение vs code не столь удобен, как отдельный git клиент, как минимум, для меня показалось не удобным переключение между ветками, также отмечу, что там также нельзя запускать произвольные скрипты из интерфейса, как это есть в git extensions, для меня vscode, это удобный инструмент редактирования кода, или его поиска по структуре каталога, но точно не удобный git клиент. 7. user1559729 17.01.23 16:52 Сейчас в теме Хорошая статья. Легко читается. Написано просто и доступно. 8. Brawler 444 17.01.23 18:31 Сейчас в теме Пока читал статью, в очередной раз понял нафига оно не надо. чтоб это поддерживать нужно тоже специалистов держать и гуру по решению нештатных ситуаций, которых не возникает при использовании "1С Хранилище конфигураций" + сервера хранилищ. Я уже 10 лет пользуюсь со своей командой "1С Хранилищами конфигураций", никаких биений лбами практически не происходит, захват корня минимизируем вполне может быть и смешным способом, например на примере обработок и отчетов. Создаешь в структуре метаданных: Отчет01, Отчет02. ОтчетХХ, Обработка01, Обработка02. ОбработкаХХ. Если кому требуется создать новый отчет или обработку, у него полно болванок, захватил и играйся от души. Создание болванок минутное дело, Ctrl+C, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V. Общие модули делим по типа ХХ_ПечатныеФормыПродажи, ХХ_ПечатныеФормыЗакупки, ХХ_Производство, ХХ_УправлениеСвойствами, ХХ_Константы, ХХ_ТЕкстЗапросов, ХХ_ОбщегоНазначения. по итогу дробится функционал и редко кто-то пересекается из разработчиков. Разработка вся только в расширении конфигурации, ОДНОМ ЕДИНОМ, а не зоопарке. Упрощен поиск ошибок, легко обновлять базу на новые релизы. Да все знают, что "Хранилище конфигураций" и конфигуратор не навороченный VisualStudio, но блин его мне хватает на все 100%, ибо и отладка пашет хорошо, и интерфейс не вырви глаз как в EDT, легкая среда разработки имеющаяся везде, даже часто на тачках пользователей. Устанавливается крайне быстро. Прикручивать всякие гиты почти кощунство. Надеюсь 1С просто доработку проведет у "Хранилища конфигураций" может не зря они опрос и провели недавно. triviumfan; Dimkasan; ivan1703; user658002_SvanMoscow; info1i; dima_home; ixijixi; + 7 – 1 Ответить 10. karpik666 824 17.01.23 19:30 Сейчас в теме (8) Отмечу только, что поиск ошибок в хранилище не такой уж и удобный, а просмотр чем текущая форма конфигурации отличается от предыдущей вообще превращается в геморрой, так как быстро сравниваются только изменения в модуле. Также без комментария, по какой задаче сделано, и авторства очень сложно определить, кто именно сделал доработку. Плюс невозможно вести крупные долгоиграющие проекты на несколько недель или месяцев, у тебя тогда должно быть постоянно захвачены объекты из хранилища, либо целиком отключено хранилище, и это при том, что ты должен выполнять работу и по другим задачам. Плюс использование больше одного расширения с хранилищем превращается в ад подключения. А так каждый волен использовать собственный инструмент, какой ему удобней использовать. VladC#; kuntashov; + 2 – Ответить 11. Brawler 444 17.01.23 20:20 Сейчас в теме (10) Ну как бы в хранилище есть функция выборочного сравнения объектов, где не тянется вся конфигурация целиком для сравнения, а только то что ты сравнивать хочешь. Мы доработками ERP занимаемся не снимая замков, и все дорабатываем в расширении, а поскольку расширение не такой гигант как сама типовая конфигурация, то даже полное сравнение в расширении происходит довольно быстро. По поводу долгоиграющих доработок. Ну вот сижу я пилю реально два с лихом месяца что-то. И тут кому-то понадобилось внести правку там, он как и принято всегда просит отпустить объект, я же понимаю что не могу. Но на самом деле могу. Сохраняю CFE, отпускаю объект. Там человек делает правку быстро. Я смотрю, что он менял. Захватываю объект, делаю сравнение и объединение, вношу такую же правку как тот человек и продолжаю работать. Это краааайне редко так делать приходится ибо как правило все разработчики занимаются разными областями. Я реально много чего переписывал комплексно и не один месяц, и я не сцу за свои доработки, я могу их сдавать тупо частями, освобождаю объекты, а есть (не в моей команде) туча программистов сыкунов, которые не могут гарантировать работу своего кода и потому будут миллион захваченных объектов держать. Я при том сдавая частями что-то могу уже даже наблюдать как что-то частично уже жить начинает, а я достраиваю все остальное, шаг за шагом. А могут мои сданные кусочки функционала начинать использовать и другие программисты. Меня веселят люди пытающиеся использовать докеры шмокеры для отладок, создают себе кучу работы искусственно, вместо того чтобы просто сесть и хорошо продумать систему чтобы она обладала свойствами самотестирования там где ну прям вообще труба и сложные алгоритмы расчетов. Вот и Git у меня ассоциируется с бесполезной созданной искусственной работой, где перед руководством потом можно козырять красивыми и все равно не понятными ему словами. Я не отрицаю, может для некоторых команд Git единственный выход, но я в такую опу еще не попадал к счастью! Dimkasan; dima_home; + 2 – Ответить 13. karpik666 824 17.01.23 22:22 Сейчас в теме (11) данная статья не агитирует за git, она только показывает какие ошибки могут быть, вы вольны использовать собственный инструментарий. Не понимаю такого негатива. И докеры и шмокеры хороши в определенных ситуациях, если вы их не используете это не значит, что они не нужны. Я правильно понимаю, что вы ERP дорабатываете через расширение? это проект на сколько программистов и пользователей? Лично мое мнение, если ERP находится на поддержке у команды разработчиков, что нужно всячески уходить от расширений, они только усложняют дальнейшую работу и поддержку, а расширение использовать как патчи, вместо динамического обновления. Также хотелось уточнить, а как вы храните документацию, или внешние обработки и отчеты, вы их не версионируете, или например доработанные внешние регламентированные отчеты? Использование GIT призвано стандартизировать работу команды, а не выделять личность, которая может сдавать проект частями (правда непонятно, зачем неготовые объекты в системе, еще не протестированные пользователями), и те кто имеют меньше квалификацию. Процесс разработки делится на этапы выполнения работы и дополнительного контроля со стороны более квалифицированного коллеги, который и принимает решение о корректности выполнения задачи, дополнительно может проводиться код ревью, плюс задачи проходит этап тестирования, которая проводится заказчиком или ответственным сотрудником, и после переезжает в рабочую базу. Все это можно делать и через хранилище 1С, и через GIT , просто через git это проще. В хранилище при такой реализации нужно как-то покрывать дополнительно скриптами для переезда доработок между отдельными хранилищами: разработка, тестирование, рабочие. Конечно, если ты сам себе постановщик, разработчик, тестировщик, и тимлид, то такая схема работа вообще не нужна. VladC#; kuntashov; + 2 – Ответить 15. Brawler 444 18.01.23 00:04 Сейчас в теме (13) Сейчас программистов 6 человек включая меня. Пользователей более ста. На предыдущей работе пользователей было свыше 300. Да как и писал выше сейчас нет того ада наверное, который есть у других, что они вынуждены использовать более так сказать серьезные системы типа Git. Я не негатювлю, просто люди должны понимать, что Git не панацея и не всегда нужен, можно обходиться и более простым функционалом. Я правильно понимаю, что вы ERP дорабатываете через расширение? Да дорабатываем через расширения все, при этом стремимся чтобы расширение было только одно, но сейчас их два. Второе заточено под интеграции с 1С ДО 2.1 (в нем тоже одно расширение). С Самого начала как начали использовать ERP, все дорабатывали только через расширения. Эта практика пока не подводила не считая иногда встречавшиеся глюки платформы. Разработка с применением расширений проходит куда интереснее чем портить типовой код, обновления на новые релизы протекают гладко, большое подспорье это проверка возможности применения расширений с автоматическим поиском проблем, хоть и не всех. В свое время я услал восстанавливать допилы в БП 2.0 - 3.0 при обновлении, в начале своей карьеры, кошмарная рутина стала. На ERP это было бы еще то удовольствие, не завидую тем кто пилит типовую. Если снимать замки с типовой ERP, то банально как было замечено, обновление ставится не 30 минут, а 3 часа. Применять хранилище на типовой конфигурации пробовал, лютый трэш с длительностью захвата всех объектов, со сдачей в хранилище. Само по себе хранилище растет в размере большими темпами. Также хотелось уточнить, а как вы храните документацию, Документации к сожалению мало, по сути как и везде кто-то ставит ТЗ на ломанном языке, мы пытаемся реализовать. В сложных отчетах или обработках сразу в расширении пишется справка, чего вполне хватает. От внешних отчетов и обработок планомерно уходим, разгребаем технический долг доставшийся в конце 2021 года, все переносим в то самое расширение где и версионируется оно уже хранилищем конфигураций. До этого программисты 1С на предприятии пытались Git использовать для внешних обработок и отчетов, посмотрев на что я прекратил эту практику на корню ибо времени на то чтобы запихнуть в Git обработку или отчет, а потом положить в базу в справочник внешних обработок, уходило больше чем просто работать с хранилищем (свыше 300 обработок и отчетов было внешних). А ведь те программисты гавкались даже на этапе размещения в базе своей обработки ибо кто-то на несколько минут раньше туда положил такую же, но со своими доработками, ну и закономерно доработки одного терялись, так что внешние файлики это очень плохое решение. Позволительно только с нуля что-то как внешнее писать, отлаживается, а потом вживляется в расширение и уже потом групповая доработка через хранилище. (правда непонятно, зачем неготовые объекты в системе, еще не протестированные пользователями), Вы там видимо в каки-то тепличных условиях доработки ведете, видимо в столице родины нашей. Мы тут в глубинке не избалованы огромным количеством тестировщиков, кодревьверов и еже с ними. Приходится полагаться на свой многолетний опыт и то как ты изначально код пишешь, то есть не как курица лапой, где ничего не понятно. Я гоняю за несоблюдения аккуратности. Так и вот сдается код в котором ты уверен и конечно же протестирован хоть даже и бегло на тестовых базах. От того, что ты например выполняя большую работу в некотором общем модуле изобрел новую функцию получения минимума из двух чисел и сдал ее в хранилище, система не упадет, зато другой программист получает возможность и свое что-то в модуль сдать, а ты в каких-то других частях еще не дописанной программы уже используешь свою функция получения минимума. И разве кто-то мешает допустим сделать костяк некоторого справочника, без блэк джэка и . и сдать его в хранилище и применить. Потом юзеры возможно без некоторого комфорта начинают туда вбивать данные, а ты тем временем пилишь кнопочки, которые добавят в будущем комфорта. Стоит упомянуть, что все же между программистами и юзерами у нас есть и только одна линия обороны в виде пяти специалистов 1С, которые в отличии от юзеров в состоянии материалы с 1С ИТС читать и так же проверить за программистом потыкав кнопочки в новом или допиленном старом функционале и то чисто для успокоения и отрапортованию юзеру, что работа сделана. В хранилище при такой реализации нужно как-то покрывать дополнительно скриптами для переезда доработок между отдельными хранилищами: разработка, тестирование, рабочие. У нас кощунство, мы и разрабатываем и тестируем, и применяем в боевые базы все из одного хранилища, экономия времени катастрофичная, отладке не мешает, ибо у программистов и так у всех свои базы, где еще до сдачи доработок может проверить функционал как он сам, так специалист 1С и юзер. Конечно, если ты сам себе постановщик, разработчик, тестировщик, и тимлид, то такая схема работа вообще не нужна. Вот вот, ближе к истине, я тимлид, а моя команда программистов молодцы, каждый сочетает в себе: постановщика (под контролем меня), разработчика, тестировщика. Такой состав функций у каждого программиста позволил за пол года без лишних соплей перевести 15 (1С КА 1.1) филиалов крупной фирмы в ERP, под знаменем новой одной организации. Потом в эту же базу за 3 месяца завести крупное производственное предприятие (1С УПП 1.3) являющейся материнским для той первой организации. Потом выполнить там же слияние организаций за 3 месяца. Предприятие видя, что программистов мало, а работ море пыталось привлечь много разных франчей. Только они слились все уже на этапе коммерческих предложений. И только из Первого Бита пару ребят удалось все же на процентов 5 работ задействовать на момент объединения фирм. На новой работе применяя тот же подход, за 2.5 месяца удалось перевести фирму с релиза ERP 2.4 на 2.5.7, очень запущенная база. Ударными темпами, но вытянули, теперь разгребаем технический долг доставшийся по наследству (и это не только ERP). И тут хранилищ конфигураций за глаза хватает. В каждый момент времени программисты видят, что кто-то уже колупает некий объект и что можно просто заняться или другой работой или узнать, а нужен ли он еще, решается все без конфликтов и быстро. Проблем со слиянием доработок разных программистов нет ибо разработка и изменения последовательные получаются, сначала один допилил, потом другой, и так далее. Мы уже готовы ставить 2.5.11 релиз ERP, как только он перекочует в колонку стабильных. При этом нужно переименовать в расширении только одну подсистему и мы обновились (проверено на тестовой). По сути можно или волокиту разводить бумажную с кучей прослоек специалистов разных уровней, чтобы перекладывать ответственность (обезьянку), или просто работать без лишних бесполезных порой людей, делать работы частями и отдавать в работу частями, если это возможно, нечего так сказать тянуть известно кого за известно что. Если работы сдавать частями, то и обратную связь от пользователей начнешь раньше получать и не придется переписывать все ибо они хотели по другому. Ладно все это не о Git. Кому надо тот его будет использовать. Но я надеюсь, что все же на волне санкций, фирма 1С развивать будет свой инструментарий. Git + 1С. Часть 1. Как подключиться к команде разработки и начать использовать Git Первая статья из цикла инструкций по работе с Git в 1С-разработке. Рассмотрим, как настроить рабочее место, как получить свою "копию" проекта для разработки и приступить к полезным действиям. Все примеры будут изложены в рамках трёх практических кейсов: 1. Моя команда дорабатывает типовую конфигурацию, использует приватный репозиторий на BitBucket, в котором версионируются внешние отчеты/обработки, расширения конфигураций и правила обмена; 2. Я участвую в стартап-команде, которая разрабатывает свою конфигурацию с использованием Git и GitLab; 3. Я принимаю участие в развитии OpenSource-продукта на GitHub как заинтересованный разработчик (контрибьютор). Часть 1. Как подключиться к команде разработки и начать использовать Git (эта статья) Содержание Содержание Начало работы над задачей Процесс жизнедеятельности задачи Фиксация изменений Отмена изменений и других последствий невнимательности Отказ от индексирования изменений Игнорирование файлов, файл .gitignore Отмена изменений в индексе Просмотр изменений Слияние готовой фичи в develop Вариант 1. Локальный merge Вариант 2. Создание запроса на слияние Вместо заключения. О чем договариваемся в команде Предисловие Несмотря на то, что еще в 2015 году в версии платформы 8.3.6 появилась возможность раскладывать конфигурацию в исходные файлы, до сих пор лишь малая доля команд разработчиков 1С используют Git в своей повседневной деятельности. Причин тому несколько, и здесь мы не будем на них останавливаться. Моя главная цель: популяризировать командную разработку на Git в мире 1С и понизить порог вхождения в нее наших коллег. Как раз этому посвящена данная серия статей, и перед вами - первая из них. Итак, поехали! Но для начала. Вводная, или куда послать 1С-ника, не знающего Git Если кому-то удобнее видео-формат, то рекомендую посмотреть официальную книгу. В ней же хорошо описывается суть и назначение систем контроля версий, поэтому я не буду тратить время на описание того, что такое Git, для чего он нужен и почему это круто. Вы можете самостоятельно нагуглить и другие источники, но этого базиса вполне достаточно, чтобы после его освоения начать перевод своей 1С-команды на использование Git. Организация рабочего места Прежде чем начать использовать Git в 1С-разработке, необходимо выполнить установку дополнительного ПО и его первоначальную настройку. Также выполним первое подключение к Git-репозиторию. То есть, подготовим всё необходимое сразу, чтобы уже не возвращаться к этому в процессе работы. Говоря о ПО, необходимом для работы с Git, следует отметить, что для каждой из рассмотренных ниже задач есть гораздо более широкий выбор вариантов, я опишу здесь только по одному из них. Вы же можете использовать то, что вам больше нравится или лучше подходит именно для ваших задач: Система контроля версий. Они, неожиданно, тоже бывают разные. Мы будем использовать Git; Интерфейсная оболочка для работы с Git, или т.н. Git GUI. Их разнообразие может впечатлить, о наиболее популярных можно почитать здесь. Я остановился на SourceTree от Atlassian. А вообще, можно и вовсе обойтись без нее, и выполнять все команды Git из командной строки. Но, как правило, 1С-ники не любят командную строку, им больше нравится нажимать на кнопки, поэтому займёмся установкой SourceTree; Git-сервер. Как правило, в корпорациях устанавливают свой собственный сервер версионирования для Git. Мы рассмотрим наиболее популярные открытые облачные сервисы (или хостинги) GitHub, GitLab и BitBucket; Конвертеры исходного кода 1С. OneScript, просто OneScipt; Редакторы кода. Эта тема вообще уходит далеко за пределы мира 1С. Просто поставьте себе Visual Studio Code, и будет вам счастье. Кстати, она же является неплохим Git GUI. Регистрация на GitHub, GitLab и BitBucket Чтобы иметь возможность работать с системой версионирования кода в группе разработки, прежде всего, необходимо иметь свой аккаунт на одном из хостингов Git. Очень вероятно, что такой аккаунт у вас уже есть, поэтому данная часть инструкции сделана опционально. Если нет - выбирайте, что вам больше по душе: Заходим на сайт Нажимаем кнопку "Sign up for GitHub" для регистрации нового аккаунта. В открывшемся окне вводим логин (проверяется уникальность имени), адрес электронной почты (проверяется уникальность) и пароль. После успешной верификации (две зелёные галки) нажимаем "Create an account". На следующем шаге можно выбрать рабочий план: по умолчанию установлена бесплатная регистрация с неограниченным числом публичных репозиторием. Если необходимо ипользовать приватные репозитории за 7$/мес., то указываем второй вариант. Нажимаем "Continue". Далее GitHub просит заполнить мини-анкету и ответить на несколько вопросов о вашем профессиональном уровне. Отвечаем, затем нажимаем "Submit" для завершения регистрации аккаунта. И наконец, для активации аккаунта необходимо пройти по ссылке, которая выслана вам на почту на указанный при регистрации адрес. (Если письмо не обнаружено, загляните в спам) Заходим на сайт Здесь указываем свои логин, адрес электронной почты и пароль. Ниже ставим галку о согласии с лицензией и "Я не робот". Затем нажимаем "Register". Теперь в своем почтовом ящике находим письмо от GitLab и проходим по высланной в нём ссылке для активации аккаунта. (Если письмо не обнаружено, загляните в спам) Далее, либо нажимаем ссылку LogIn, и тогда в открывшемся окне: жмём внизу "Sign up for an account"; Либо щелкаем по ссылке "Get Started", и сразу оказываемся на странице регистрации нового аккаунта: Вводим свой электронный адрес. Будет выполнена проверка существования такого же аккаунта. И, если такового еще нет, получаем зелёную галку и жмём Continue. На следующем шаге указываем своё имя, придумываем пароль и говорим "Я не робот". И снова Continue. После этого вам останется зайти в свой почтовый ящик и жмакнуть по высланной ссылке для подтверждения регистрации. На этом регистрация завершена, можно приступать к работе. Установка Git Установка Git описана для версии 2.18.0. Процесс установки и внешний вид окон для более поздних версий может немного отличаться. Запускаем скачанный с официального сайта проекта файл установки ( Про Git GUI Here и Git Bash Here Если оставить эти два флажка (установлены по умолчанию), то в проводнике Windows эти две команды будут доступны из контекстного меню текущего каталога. Таким образом, можно быстро выполнить команды Git из командной строки, "не отходя от кассы", если нужно выполнить что-то простое и нет смысла запускать большие GUI-приложения. Советую оставить. На 3-м шаге мастер установки предлагает выбрать редактор по умолчанию, который будет работать с Гитом. Тут вы вольны выбрать то, что вам больше нравится использовать для редактирования текстов. Но я настоятельно рекомендую присмотреться к Visual Studio Code. Идём далее, и на следующих трёх шагах оставляем все настройки по умолчанию. На 7-м шаге оставляем выбор по умолчанию консоли Windows для работы с Git Bash. На последнем шаге также ничего не меняем и запускаем установку. Процесс установки займёт какое-то время, после чего появится финишное окно, на котором нажимаем Finish. На этом установка Git завершена, однако перед началом его использования необходимо единожды выполнить некоторые глобальные настройки системы контроля версий. Первоначальная настройка Git Все команды будем выполнять из командной строки. Если во время установки Git у вас была запущена командная строка, перезапустите её. Внимание! Командную строку следует запускать под администратором, чтобы избежать ошибок прав доступа при выполнении некоторых команд. Во-первых, зададим имя пользователя и адрес электронной почты, которыми будет идентифицироваться авторство коммитов в репозитории Git: git config --global user.name "Your Name" git config --global user.email "your_email@whatever.com" Во-вторых, установим настройки правил коммита окончаний строк, это в дальнейшем поможет избежать ошибок при коммите изменений в исходных файлах конфигураций 1С: git config --global core.quotepath false git config --global core.autocrlf false git config --global core.safecrlf false Внимание! Ключ core.autocrlf влияет на кроссплатформенные приложения. Поэтому, если есть необходимость коммитить с этой же машины код, который должен работать под Mac/Linux, необходимо проявлять осторожность. Например, задавать значение параметра не глобально для всей СКВ Git, а для каждого репозитория в отдельности. Установка SourceTree Установка SourceTree описана для версии 2.6.9. Процесс установки и внешний вид окон для более поздних версий может немного отличаться. Запускаем скачанный с официального сайта Atlassian файл установки (скачать. ). На первом шаге соглашаемся с лицензионным соглашением и нажимаем "Вперёд". На этом этапе SourceTree требует ассоциации с аккаунтом Atlassian (появляется после регистрации на BitBucket). Можно либо указать свой существующий аккаунт (должен быть зарегистрирован до установки программы), либо выбрать вариант регистрации нового аккаунта, тогда SourceTree поможет пройти необходимые шаги регистрации и произведёт ассоциацию с новым аккаунтом. Далее рассматривается вариант, когда аккаунт на BitBucket уже зарегистрирован, и нам остаётся только к нему подключиться. Выбираем вариант "Учетная запись Atlassian": Появится окно авторизации, в котором указываем логин и пароль нашего аккаунта и нажимаем "Log in". После верификации учётной записи появится окно с сообщением об успешной авторизации. Идём "Вперёд": При установке SourceTree можно автоматически установить и сам Git, если на следующем шаге указать соответствующий флажок. Если у вас еще не установлен Git, можете сделать это сейчас. После нажатия кнопки "Вперёд" скачан и установлен Git, что займёт некоторое время, затем появится окно об успешном завершении установки: На последнем шаге можно загрузить SSH ключ, если таковой имеется. Мы пока пропустим этот шаг и нажмём "Нет": Сразу после этого откроется главное окно SourceTree, готовое к работе: Как создать ключ SSH В своей папке пользователя Windows создаём и заходим в папку .ssh (именно так, с точкой). Правая кнопка мыши -> Git Bash Here. В консоли набираем: ssh-keygen -t rsa, три раза Enter (имя файла и пароль вводить НЕ НАДО). В папке C:\Users\%Username%\.ssh появится пара файлов с именами id_rsa и id|_rsa.pub. Файл id|_rsa.pub - это публичный SSH ключ, который можно залить в свой профиль на GitHub/GitLab/BitBucket или локальный сервер-хранилище Git (тот же GitLab даёт такое), и который так же ассоциирует разработчика, как конкретного пользователя. Второй файл не надо отправлять никому, кроме самого себя на другой свой компьютер, с которого предполагается работа с тем же проектом в Git. Установка OneScript Установка OneScript (он же OScript, он же 1Script) описана для версии 1.0.20. Процесс установки, состав устанавливаемых компонент и внешний вид окон для более поздних версий может немного отличаться. Запускаем скачанный с официального сайта файл установки (скачать. ). Сама установка состоит всего из двух шагов, на каждом из которых оставляем всё по умолчанию и нажимаем "Next >" (на первом), "Install" (на втором), затем немного ждём, когда программа установится и в последнем окне нажимаем "Finish". Установка завершена! Установка дополнительных библиотек OScript Возможности OneScript легко расширяются путём установки дополнительных библиотек из серии возможностей существующих недостаточно. Как это сделать, подробно описано здесь. Установить дополнительные библиотеки можно с помощью менеджера пакетной установки opm, который у вас только что установился вместе с OneScript. Для работы с 1С, в общем случае, пригодятся следующие библиотеки: Precommit1C - при коммите в git-репозиторий изменений внешних отчётов, обработок или расширений конфигураций автоматически раскладывает их на исходные файлы. Это позволяет, во-первых, видеть авторство и причины изменений каждой строчки кода, а, во-вторых, не тратить время на самостоятельный разбор в исходные файлы и не ломать голову, куда их положить и как структурировать; opm install precommit1c Установка oscript-библиотеки считается успешной, если библиотека сама стала вызываться из командной строки как самостоятельное приложение, например: precommit1c --help Gitsync - занимается разбором конфигурации 1С из хранилища в исходные файлы для версионирования. opm install gitsync Packman - для обратной сборки файла конфигурации из исходных файлов из репозитория Git. opm install packman Deployka - содержит набор функций для поставки изменений конфигураций в тестовые и рабочие контуры. Подробную информацию о возможностях и порядке использования "деплойки" можно почерпнуть из вебинара, а здесь познакомиться с практическим примером ее применения. opm install deployka Установка Visual Studio Code Установка VS Code описана для версии 1.27.2. Процесс установки, состав устанавливаемых компонент и внешний вид окон для более поздних версий может немного отличаться. Запускаем скачанный с официального сайта файл установки (скачать. ). Первые 4 шага стандартные и не представляют особого интереса: соглашаемся с лицензионным соглашением, указываем папку для установки и т.п. Нажимаем везде "Далее". На следующем шаге выбираем настройки среды "под себя": необходимость добавить быстрый переход в VSC из контекстного меню файла или каталога, а также зарегистрировать VSC в качестве редактора по умолчанию для поддерживаемых типов файлов. При установке последней, для использования в VS Code будут зарегистрированы расширения файлов наиболее популярных языков программирования и конфигурационных файлов сред разработки. Для нас среди них представляют интерес *.feature и *.md. Если вам не нужна регистрация для всего "зоопарка" файлов, которые никогда не будут использованы, можете не ставить эту галку, но после установки не забудьте зарегистрировать для VS Code эти расширения. А также расширение *.bsl (по умолчанию не ставился) для редактирования текстов модулей 1С. После нажатия "Далее", останется согласиться с выбранными параметрами, запустить установку и дождаться ее окончания. Установка плагинов Прелесть VS Code заключается в том, что его функционал можно гибко расширять и настраивать с помощью плагинов (или расширений). Существует бесчисленное множество плагинов для различных языков программирования (и не только программирования) и удобства работы с отдельными инструментами, в том числе и для языка 1С. Чтобы установить плагин, в главном окне VS Code открываем раздел "Расширения" и строке "Поиск расширений в Marketplace" набираем "bsl". Среди найденных плагинов выбираем "Language 1C (BSL)" от известной нам команды коллег, и нажимаем на кнопку "Установить". После достаточно быстрой установки, останется нажать появившуюся кнопку "Перезагрузка", и действие плагина вступит в силу. Теперь при редактировании кода модуля на языке 1С мы получаем полноценную раскраску синтаксиса и работу контекстной подсказки при наборе точки или скобки. Всё как в конфигураторе, только еще лучше 🙂 - попробуйте сами! Как видно из рисунка, по щелчку на плагине, в рабочей области VSC появляется описание с инструкциями по использованию, что очень удобно при знакомстве с новыми плагинами. В дальнейшем, вы непременно захотите продолжить улучшение рабочей среды с помощью плагинов. Подборка наиболее интересных из них находится Подключение к проекту и создание локального репозитория Теперь, когда весь необходимый софт установлен, самое время перейти к созданию своего первого репозитория Git. В зависимости от формата проекта и способа взаимодействия в команде, существует несколько способов подключить у себя репозиторий. В большинстве случаев, при начале работы в команде, использующей Git, вам предстоит клонировать репозиторий с Git-сервера. Если репозиторий на сервере является публичных, то можно смело приступать к операции. Если же он приватный, то прежде необходимо запросить у владельца или мастера репозиторий выдать вам права доступа. При этом, если предполагается в дальнейшем выполнять коммиты (фиксировать свои изменения), то должны быть права разработчика, Для возможности клонирования достаточно иметь право на чтение. Клонирование репозитория с BitBucket Откройте страницу репозитория, нажмите кнопку «Клонировать» и скопируйте появившийся путь к репозиторию. Клонирование репозитория в SourceTree Далее, в SourceTree нажимаем кнопку с плюсиком в строке закладок и выбираем вариант Clone (Клонировать). Вставляем скопированный путь в поле «Исходный путь/ URL », указываем каталог для хранения локальной копии репозитория в графе «Целевой путь» и название нового репозитория. При необходимости можно дополнительно разделить репозитории на тематические группы, название группы выбираем в поле « Local Folder ». Нажимаем кнопку «Клонировать», и после завершения процесса клонирования (время зависит от объема репозитория) мы получим у себя локальную копию репозитория проекта, готового к работе. Установка Precommit1C Для реализации первого кейса нам предстоит версионировать внешние отчеты, обработки и расширения конфигураций. Но хранить их "как есть" не очень хорошо, поскольку в таком случае мы не увидим вносимых изменений и не сможем их проанализировать. Для решения этой задачи, у перечисленных объектов есть функция выгрузки в файлы. Но каждый раз нажимать эту кнопку и вспоминать, в какую папку их положить, чтобы ничего не нарушить, - тоже не хорошо. Эту операцию следует автоматизировать, и делать мы это будем с помощью Precommit1C. Precommit1C – это хук для автоматической выгрузки в исходные файлы внешних отчётов/обработок и расширений конфигураций. Его использование позволяет полностью отвлечься от рутинной операции выгрузки в исходные файлы, принятия решения о месте расположения этих самых исходников, и возложить эту работу на инструмент автоматизации. Подробно о работе Precommit1C можно узнать из первых 30 минут вебинара, также подробная инструкция находится на главной странице Установку Precommit1C можно произвести несколькими способами, рассмотрим два из них. Вариант 1. Клонирование репозитория инструмента Заходим на сайт проекта, находим кнопку «Clone or download» и копируем путь к репозиторию. Далее, в SourceTree добавляем новый репозиторий аналогично тому, как мы это делали для основного репозитория проекта (см. раздел "Клонирование репозитория в SourceTree). Из локального репозитория Precommit1C копируем следующие файлы и папки: pre-commit v8Reader v8files-extractor.os tools и вставляем их в папку hooks, которую необходимо создать в каталоге “.git” корня репозитория. Вариант 2. Установка через opm opm install precommit1c Устанавливаем хук в каталог проекта: cd c:\dev\repo\sed Precommit1c --install Клонирование репозитория с GitLab .Процесс клонирования репозитория с GitLab, пожалуй, самый простой из всех, поскольку ссылка-путь и кнопка для ее копирования находятся непосредственно на главной странице проекта. Поэтому просто копируем этот путь и далее повторяем шаги, описанные в разделе "Клонирование репозитория в SourceTree". Форкаем интересные проекты на GitHub Когда мы хотим присоединиться к OpenSource-проекту, размещённому на GitHub, то тут процесс подключения к проекту несколько отличается. Поскольку доступа к прямому коммиту в оригинальный проект нам никто не даст, необходимо сначала создать в своём аккаунте репозиторий-потомок оригинала (т.н. fork). Затем выполнить клонирование в локальную копию уже своей копии-потомка и выполнять разработку уже в нём. Затем, для того чтобы поделиться новым полезным функционалом с сообществом, мы будем выполнять запросы на слияние (т.н. pull request). На странице интересующего проекта нажимаем кнопку fork, дожидаемся появления нового репозитория в своём аккаунте и далее выполняем его клонирования согласно описанию в разделах "Установка Precommit1C" и "Клонирование репозитория в SourceTree". Заключение На первый взгляд может показаться, что объем работы и количество ПО, с которым предстоит работать, пугающе большое. Но после того, как вы настроите у себя пару первых репозиториев, дальше дело пойдёт "как по маслу". А уже в следующей статье мы рассмотрим, как выполнять отдельные операции в работе на проектом: взять задачу в работу, зафиксировать результат в основном стволе разработки, исправить ошибку в коде и другие действия, из которых состоит повседневная жизнь разработчика. Удачи! См. также Системы контроля версий для 1С-разработчиков. Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8 29.06.2022 7437 67 4 93 67 4 7437 Работа с GitLab API Работа с API GitLab на примере запуска pipeline с переменными, отслеживания его статуса и загрузкой полученных артефактов. 1 стартмани 06.10.2023 430 0 itsys 0 Наш путь в Git – история одного внедрения CI/CD Чтобы перейти от разработки в хранилище до полноценного релизного цикла CI/CD, с автотестированием кода, сборкой конфигураций из исходников и ветками разработки для каждой задачи, нужно пройти большой путь. Расскажем о том, как организовать полностью автоматическую доставку проверенного и рабочего кода в 2000 конфигураций. 02.10.2023 2547 MrWonder 4 Jenkins на службе 1С Основная специализация Jenkins – это, прежде всего, CI/CD. Но его можно использовать и для других важных задач: разбора хранилищ, настройки копий баз данных, раздачи прав пользователям, рестарта кластера и проверки кода проектов. 19.07.2023 1458 yukon 4 Приемы быстрой работы в EDT/Git Статья даёт ответы на некоторые вопросы, возникающие у разработчиков, которые погружаются в океан технологий EDT и Git, омывающий царство DevOps. Сколько и какие ветки нужны? Какой репозиторий выбрать? Кто должен сливать доработки в мастер ветку или ветку версии? Как не тратить время в EDT на ресурсоёмких операциях? Зачем нам сборочный конвейер и как его построить? Зачем нам нужно тестирование и как его реализовать? Как вести разработку, если есть разработчики, не умеющие вести разработку в EDT или не имеющие технической возможности, но нам нужны их skills в 1С? Что такое фантомы и нужно ли с ними бороться? Как слить 20 доработок с конфликтами и уложиться в 4 часа? Опыт использования модных технологий в реальных проектах. 30.03.2023 6723 check2 10 85 10 6723 Получаем статистику по git-репозиторию в разрезе разработчиков Итак! Представим, что наступил момент, когда разработка через исходный код реализована на предприятии в полном объеме. Мы разрабатываем в EDT или конфигураторе (но выгружаем конфигурацию в исходный код), версионируем внешние отчеты и обработки и расширения, собираем релизы, проверяем код статическим анализом, в разработке царит гармония и мир. Красота! Но менеджерам этого мало, всегда хочется чего-то еще, и вот мне прилетает задача - дай статистику по вкладу в код каждого разработчика. 13.03.2023 2163 ardn 3 Формула успешного внедрения DevOps и Agile в 1С: от неудачи к неудаче без потери энтузиазма На конференции Infostart Event 2021 Post-Apocalypse выступил директор практики БИТ:ERP компании Первый БИТ Глеб Стальной. В ходе доклада он рассмотрел трансформацию проектного подхода в продуктовый, рассказал про имплементацию «современных» практик DevOps и продемонстрировал инструменты для разработки, взаимодействия с бизнесом и клиентами, применяемые в его команде. 27.02.2023 1799 0 glebushka 2 13 0 2 1799 Кровь, пот и GIT Ведущий разработчик 1С Андрей Карпов на конференции Infostart Event 2021 Post-Apocalypse поделился ошибками, которые совершают новички в работе с GIT. В докладе четыре кейса с пошаговыми инструкциями, которые позволят не допускать конфликтов в разработке. 17.01.2023 8062 karpik666 45 67 45 8062 Посмотреть ещё Комментарии Дата Дата Рейтинг всех уровней Рейтинг 1-го уровня Древо развёрнутое Древо свернутое Свернуть все 1. Lok`Tar 85 18.10.18 12:53 Сейчас в теме Круто, плюс однозначно, спасибо за информацию berezin84; zuxelzz; manuel; wowik; + 4 – Ответить 2. int18h 101 18.10.18 12:58 Сейчас в теме "Меня часто спрашивают. с хранилища на использование системы контроля версий (СКВ)? Отвечаю на первую часть вопроса. . " тут нужно остановиться и воспроизвести слово "зачем" зачем тонна софта в инфраструктуре по типу карточного домика и для каких задач? Я бы понял если нужно разгребать тучу коммитов и форков драйвера или утилиты для Linux (для чего собсто git и делался), а в 1С зачем? Устраивать самому себе стрельбу в ногу - когда надо сдать подсистему а у тебя отвалилось что-то вроде v8Reader или v8files-extractor.os глюкнул, а ты такой полдня в поиске проблемы вместо нажатия на кнопку "Поместить в хранилище"? Да ну подождите вы EDT monkbest; user1549775; rabota.v8.1c; Altavista.roman; korppinen; METAL; shiaju; Rabot; vladimirmatancev; JIEX@; globalfoods; Maximum.proger; Zeskord; timurkhann; Yakud3a; vl_vedernikov; hiduk; Irwin; igor_demin@mail.ru; Трактор; ShurikDM; ni032mas; ll13; paybaseme; zqzq; FreeArcher; rpgshnik; AleAPetrov; surikateg; nayd; krollzlat; d4rkmesa; frkbvfnjh; CyberCerber; + 34 – 9 Ответить 6. Захаров_Николай 11 18.10.18 13:50 Сейчас в теме (2) Что-то не жду я уже EDT. (5) VSCode нужен для написания скриптов OScript и для Gerkin. "Зачем?" - статья только основание дальше станет понятно. berezin84; ��️��; stas_ganiev; gradi; + 4 – Ответить 9. gradi 5 18.10.18 14:43 Сейчас в теме (6) до написания скриптов я как-то не добрался. Если честно, пока не нашел где их применить. 41. stas_ganiev 1727 22.10.18 22:21 Сейчас в теме (9) У вас ещё всё впереди)) 31. GreenDragon 19.10.18 16:29 Сейчас в теме (2) Они запилят в EDT поддержку обычных форм? Нет? Чего тогда мне и сотням тысяч других разработчиков ждать? Dach; Waanneek; + 2 – 2 Ответить 35. ipoloskov 161 21.10.18 12:31 Сейчас в теме (31) ждать, очевидно, естественной смерти УПП и иже с ними. Я тоже жду. user717534; vladimirmatancev; Ignatov_mu; amoiseev; Yakud3a; zeegin; + 6 – Ответить 38. GreenDragon 22.10.18 12:02 Сейчас в теме (35) А это тут при чём? Не совсем понял мысль 39. ipoloskov 161 22.10.18 15:56 Сейчас в теме (38) отомрет УПП - и необходимость поддержки обычных форм исчезнет. vladimirmatancev; Yakud3a; + 2 – Ответить 49. GreenDragon 23.10.18 09:37 Сейчас в теме (39) Когда отомрёт УПП, наша организация перестанет использовать УТ 10.3? Не совсем понял ход мысли. Конкретно в нашей организации используется git + precommit. Основная конфигурация на базе сильно переписанной УТ 10.3 Что у нас должно поменяться со смертью УПП и для чего нам EDT? 40. stas_ganiev 1727 22.10.18 22:19 Сейчас в теме (2) никто не утверждает, что описанная метода - панацея. Нравится хранилище и кажется более надежным? - пожалуйста, никто по рукам бить не будет. Но лично я ощутил на себе и своих разработчиках массу плюсов в использовании Git, поэтому и родилась идея этой серии статей. Куча софта? Да не такая уж и куча, если учесть, какой кучей вы уже пользуетесь. Просто для вас это стало естественным. Пройдёт совсем немного времени, и так же естественно будет открыть VS Code для редактирования модуля. Глюки? Бугага! За два года ни разу ничего не глюкануло! А вот хранилище глючит с завидной регулярностью. И приходится сидеть ждать, пока админы что-то починят на серверах и роутерах, пока можно будет снова захватить или поместить объект. А это время, а это деньги. Alex_YAM; Alex_Iz; Vladimir Litvinenko; + 3 – 1 Ответить 55. nvv1970 04.11.18 10:58 Сейчас в теме (40) вывод: плохие админы мотивировали перейти на git)) У нас сотни хранилищ по http, централизованно, по интернету. За много лет нигде ничего не отвалилось. ivan_luzinov; + 1 – Ответить 60. palsergeich 26.11.18 12:39 Сейчас в теме (55) Гит позволяет очень быстро ответить на вопрос - кто и когда добавил эту строчку кода. git-blame После одного случая, где для поиска автора и породившей изменение задачи потребовалось более 6 ти часов, для меня это стало очень большим преимуществом. С хранилищем - при большой истории изменения объекта - печаль и боль. alei1180; gmzhukov; METAL; bomber99544; + 4 – Ответить 61. nvv1970 26.11.18 14:00 Сейчас в теме (60) в этой части - полностью с вами согласен. Я бы и без мотивации перешел, но не с кем (((( 62. AntonSm 30 26.11.18 14:26 Сейчас в теме (60) gitsync позволяет и при работе в хранилище получить эту фичу. gitsync 50. ArchLord42 83 23.10.18 15:37 Сейчас в теме когда надо сдать подсистему а у тебя отвалилось что-то вроде v8Reader или v8files-extractor.os глюкнул Да ну подождите вы EDT тем временем в комментах с новостями про EDT люди пишут. "зачем нам EDT, вдруг он у нас отвалится и мы не сможем сдать подсистему" Я заметил, что 1Сники очень консервативные люди и очень сильно боятся чего-то нового, постоянно аргументируя тем, что все атвалицтся и они бедненькие не успеют чего-то там, при этом то же хранилище, скажем так, немного не стабильно порой, да в принципе все кто связан с 1С уже привыкли страдать Юзеры, которые уже давно не удевляются тому, что "1С глючит", разработчики, которые ходят по отделам и спрашивают, "а кто это написал" и тд. Собственно хайп вокруг git + 1C возник именно на этой почве, людям и бизнесу в целом надоело страдать в то время, когда коллеги из других направлений разворачивают "гиты", "сиай", пишут тесты и крепко спят по ночам, при этом еще и на выходных отдыхают. Есть конечно 1 кейс, при котором git скорее будет излишним усложнением: Количество разработчиков ~1 и в вашей компании баги и простои 1С не сильно сказываются на работоспособности бизнеса, если это так, то тут действительно git возможно не нужен, хотя даже при таком раскладе, версионировать обработки \ ВПФ и тд без гита в принципе сложно сейчас. Trampic; Kosstikk; int18h; neikist; + 4 – Ответить 90. aakolov 04.02.23 14:06 Сейчас в теме Ну хотя бы для того, чтобы видеть, кто и когда внес изменения в код. Актуально для работы в больших командах, с неколькими подрядчиками и т.п. stas_ganiev; + 1 – Ответить 3. DPotapov90 18.10.18 13:03 Сейчас в теме Крутота. Давно хотел поковырять Git, после прочтения руки зачесались еще сильнее. Спасибо, жду продолжения 🙂 link_l; stas_ganiev; manuel; + 3 – 1 Ответить 4. herfis 489 18.10.18 13:09 Сейчас в теме В части стартового пинка одинэсников в сторону СКВ все очень круто. Толково написано, все по делу, очень емко и информативно - пять с плюсом короче. Много вопросов за кадром, но вероятно они будут освещены в следующих статьях. Но один все же меня мучает: "Использования Visual Studio Code в качестве основного инструмента при работе с Git-проектом в 1С" - это как? Хоть в двух словах? Как, например, быть с созданием и редактированием форм в "основном инструменте"? JIEX@; stas_ganiev; manuel; + 3 – 1 Ответить 5. gradi 5 18.10.18 13:20 Сейчас в теме (4) Хороший вопрос, самому интересно зачем нужен VSCode в работе с 1С. Сам активно использую Git в своих проектах. Как-то обхожусь без студии и о-скрипт. 11. ��️�� 519 18.10.18 14:45 Сейчас в теме (5) Насколько наблюдал за чужим опытом на инфостарте. VSCode используют в двух сценариях: 1) В паре с OneScript 2) Когда вы выгрузили свою конфигурацию в git разобрав её на исходный код - для поиска нужной вам информации. Тк поиск в самом конфигураторе может быть несколько продолжительным. METAL; stas_ganiev; + 2 – Ответить 43. stas_ganiev 1727 22.10.18 22:27 Сейчас в теме (11) (12) (14) (33) Всем спасибо, добавить нечего )) 12. t.v.s. 109 18.10.18 14:47 Сейчас в теме (5) Иногда бывает проще и быстрее поправить исходник напрямую, чем запускать конфигратор, править в нем, и выгружать обратно. Я лично такой возможностью пользуюсь постоянно Irwin; ArchLord42; stas_ganiev; + 3 – Ответить 14. gradi 5 18.10.18 14:54 Сейчас в теме (12) Согласен. Я одну проблему решил только через выгруженные в xml файлы. Решения через конфигуратор я так и не нашел. stas_ganiev; + 1 – Ответить 33. kuzyara 1779 19.10.18 20:36 Сейчас в теме зачем нужен VSCode в работе с 1С сценарии gherkin Прикрепленные файлы: stas_ganiev; zuxelzz; CSiER; gradi; Vladimir Litvinenko; + 5 – Ответить 42. stas_ganiev 1727 22.10.18 22:24 Сейчас в теме (4) возможно, погорячился с заголовком. Формы - пока никак, хотя знаю, что в некоторых кругах работы над этим ведутся. Подумаю над корректировкой, спасибо за замечание. 7. DoctorRoza 18.10.18 14:13 Сейчас в теме Да, это реально круто! Жду остальных статей! stas_ganiev; + 1 – Ответить 8. ��️�� 519 18.10.18 14:42 Сейчас в теме Отличная серия статей намечается. Гитом активно пользуюсь, но все руки никак не доходили настроить настроить разбор обработок на исходный код, так и храню бинарниками. Было бы здорово, если бы 1с добавила в конфигуратор кнопочку для выгрузки в git (EDT очень не нравится). Ну а пока, видимо, придется заморочиться и разобраться с Precommit1C 10. t.v.s. 109 18.10.18 14:44 Сейчас в теме (8) Эта кнопочка называется "Выгрузить конфигурацию в файлы" GreenDragon; ��️��; + 2 – 1 Ответить 13. ��️�� 519 18.10.18 14:51 Сейчас в теме (10) Так и как мне выгружать ей обработки в автоматическом режиме? Разобрать обработку сейчас можно очень большим количеством способов. Но так чтоб из коробки, одной кнопкой из ide и без гемороя - таких я не знаю. 15. t.v.s. 109 18.10.18 14:54 Сейчас в теме (13) Ключи командной строки вам в помощь. /DumpExternalDataProcessorOrReportToFiles - разбирает обработку на исходники /LoadExternalDataProcessorOrReportFromFiles - собирает из исходников GreenDragon; ��️��; + 2 – Ответить 16. ��️�� 519 18.10.18 15:04 Сейчас в теме (15) Вы, кажется, меня не понимаете. Я не утверждаю, что невозможно положить исходники обработки в git. Утверждать подобное было бы вдвойне глупо в комментариях такой статьи. Судя по всему все сведется к попытке подружить precommit1C с gitKraken. Просто руки до сих пор не дошли. Я говорю об отсутсвии "пердолинга": Прикрепленные файлы: 44. stas_ganiev 1727 22.10.18 22:32 Сейчас в теме (16) Precommit - это хук, и не зависит от используемой среды, работает напрямую с Git. Хоть gitKrsken, хоть cmd - велкам! 20. int18h 101 18.10.18 15:54 Сейчас в теме (15) Да не нужно чтоб разбирало ВСЮ обработку/конфигу. Нужен инструмент, чтоб только изменения в тексты пихало прям из конфигуратора 1С, а лучше вообще сразу их в git коммитила. stas_ganiev; ��️��; + 2 – Ответить 45. stas_ganiev 1727 22.10.18 22:33 Сейчас в теме (20) По результату так и получается - коммитятся только изменения 17. ImHunter 284 18.10.18 15:12 Сейчас в теме (8) Особой заморочки с precommit вроде и нет. Как было написано в статье, скопировать его файлы в каталог хуков. И все на этом. Потом держать открытым SourceTree и время от времени делать commit (и пуш может быть). Автоматически из конфига не получится. stas_ganiev; ��️��; + 2 – Ответить 18. ��️�� 519 18.10.18 15:18 Сейчас в теме (17) Ага, именно так я и планировал поступить очень давно. Только вместо SourceTree (нет под линь, а я какт предпочитаю инструменты которые есть и под пингвина и под форточку) использую GitKraken Нужно было придумать некий git hook (как написано в статье) который перед коммитом будет разбирать обработки. Эта статья вышла очень кстати и вероятно поможет наконец сделать то, что стоило сделать давным-давно. stas_ganiev; + 1 – Ответить 19. Darklight 32 18.10.18 15:41 Сейчас в теме Хорошая статья, не хватает только сравнения разных git-серверов (хостингов), в чем плюсы минусы, какие особенности у тех и у других. И ещё, хорошо бы уделить внимание не только к подключению к существующим проектам, но о создании собственных проектов и репозиториев (с уже имеющимися локальными исходниками). 21. ��️�� 519 18.10.18 16:22 Сейчас в теме Хорошая статья, не хватает только сравнения разных git-серверов (хостингов), в чем плюсы минусы, какие особенности у тех и у других. Все что есть, реализует git, по сути это как сравнивать одноклассники с вк, вроде интерфейс разных цветов, а суть одна и таже. GitLab вы можете поднять на локальном сервере. GitHub довольно популярен для публичных репозиториев. Если хотите практически бесплатно и большой любитель похардкодить приватные данные - используйте GitLab. И ещё, хорошо бы уделить внимание не только к подключению к существующим проектам, но о создании собственных проектов и репозиториев (с уже имеющимися локальными исходниками). Самый простой способ: 1) Создаете новый репозиторий прям через web интерфейс 2) Клонируете его к себе на диск 3) Закидываете свои локальные данные в появившуюся папку, коммитите (git commit -m "first push") 4) Толкаете (git push) 46. stas_ganiev 1727 22.10.18 22:37 Сейчас в теме (19) Мысль о сравнительном анализе была, но быстро отпала. Так же как нет смысла сравнивать разные GUI. Тут на вкус и цвет. А эта тема будет освещена в третьей части. 54. ��️�� 519 01.11.18 14:01 Сейчас в теме (46) Если что, установка gitlab'а на домашнем/рабочем сервере крайне проста, только он из коробки жрет очень много. Можете сразу списывать 4 гига оперативы. Но мне не жалко, ведь жаба давит ежемесячно платить гитхабу 7$ за приватных репозиториев (а мне нужно больше) С: Прикрепленные файлы: 22. Vladimir Litvinenko 2830 19.10.18 01:39 Сейчас в теме Классная статья, с нее начинал работу с этими инструментами. Хорошо, что теперь есть и на Инфостарте. Пара моментов. Функционал deployka сейчас переехал в runner . Использовать стало удобнее. Приведен к стандарту формат длинных и коротких ключей. Сейчас есть смысл переписать команды с deployka и vrunner на runner и рекомендовать использование последнего. При установке git для работы с 1С все же лучше выставлять настройки отличные от настроек по умолчанию. Лучше выставлять commit as is + checkout as is. Перегонять окончания строк в Unix-style и обратно кажется нецелесообразной тратой ресурсов, особенно при работе с большими конфигурациями на 5-7 миллионов строк. Также лучше не отказываться от инструментов, входящих в пакет git, они выручают. Возможно покажется полезной еще такая информация. Наиболее удобным способом работы c git в сочетании с 1С кажется даже не использование Gitlab/Github/Bitbucket, а создание репозиториев на собственном сервере и работа с ними либо напрямую как с локальным каталогом, либо через ssh-сервер. При этом упрощается обслуживание и контроль. Такие инструменты как Upsource и Fisheye/Crucible позволяют работать с Native репозиториями, расположенными прямо на локальных дисках. Мы получаем все преимущества облачных систем внутри компании. За исключением пул/мердж реквестов, которые при работе с хранилищем и не нужны. Экономим на дорогих лицензиях Bitbucket или Github Server, нет необходимости обслуживать Linux / Docker для того, чтобы хостить GitLab. В случае совместной работы с репозиторием лучше все таки поставить ssh-сервер. Для Windows перебирал разные варианты ssh-серверов и самым удобным и беспроблемным в отношении именно git оказался Bitvise. Дополнительным плюсом являются оповещения о входящих подключениях, попытках успешной и не успешной авторизации, это сильно ускоряет первоначальную настройку сервера. Поставить для изучения - бесплатно. Для компании - копейки. Есть не очевидные тонкости настройки, если будет интересно - пишите, расскажу. По темам для следующих публикаций. Очень интересно было бы прочитать про разработку Конфигуратор 1С + Git без хранилища , если у Вас есть такой опыт. Какие сложности при этом возникают, особенности настройки и организации процесса. Возможно вторая тема "Организация Git workflow в 1С-разработке" как-то затронет этот вопрос? Также интересна тема "Использования Visual Studio Code в качестве основного инструмента при работе с Git-проектом в 1С". Буду ждать. Сейчас использую VSC для скриптов OneScript, пайпланов Jenkins и файлов Gherkin. Было бы интересно узнать, можно ли расширить область применения VSC в отношении именно разработки на 1С. Похожие публикации: 9600 бод это сколько байт в секунду Какая функция выводит что либо в консоль Флаппинг что это Что такое джуниор