Разберем, как организовать работу с GIT, не покидая конфигуратор, и зачем может понадобиться автономный сервер. Вы узнаете о скриптах, которые автоматизируют взаимодействие с GIT прямо из 1С, а также о методах сборки / разборки обработок и расширений «на лету», которые значительно ускоряют процесс разработки и совместной работы.
Все больше команд начинают использовать при разработке 1С GIT. На самом деле производительность GIT так же ограничена и зависима от различных настроек и подходов, как и всеми нами любимая платформа 1С. Для комфортной работы с GIT в случае больших репозиториев необходимо выполнять оптимизацию алгоритмов взаимодействия. Опишу свой опыт.
В данной публикации рассматривается пример реализации скрипта, который автоматизирует получение ветки из GIT репозитория и обновление конфигурации, если разработка проекта ведется в EDT.
В процессе использования 1С:EDT и репозитория Git для обновлений релизов доработанных конфигураций появилась необходимость в регулярной загрузке конфигураций от вендора 1С в Git-репозиторий. Описанное в статье решение позволяет автоматизировать эту операцию и может быть полезным специалистам, занимающимися обновлениями с использованием 1C:EDT+Git
Внедряем проверку новых версий прямо в расширение. Оповещайте о новых версиях и показывайте пользователям список изменений. Для разработчиков, которые хотят сэкономить время и повысить лояльность клиентов!
Когда в хранилище одновременно разрабатывают несколько команд, сортировка сделанного и несделанного при формировании релиза и проведение code review по задачам превращаются в непроходимый квест. В таких случаях нужен бранчинг. Расскажем об опыте перехода на новую схему хранения кода для ИТ-департамента.
Называть Git новой технологией – уже смешно, но для многих 1С-ников это действительно «новое и неизведанное». Расскажем о плюсах и минусах двух главных систем контроля версий в мире 1С: Git и хранилища.
Во многих командах незаслуженно забывают о том, что в базе меняются расширения (как от вендора, так и собственные) и внешние отчеты и обработки. Вплоть до того, что релиз происходит каждый день – меняются печатные формы, отчеты, обработки. Расскажем о том, как выгружать в Git не только изменения конфигурации рабочего контура, но и файлы внешних обработок и расширений.
Заказчики любят EDT+Git за прозрачность и контроль качества. А у разработчиков есть две основные причины не любить EDT – это тормоза и глюки. Расскажем о том, что нужно учесть команде при переходе на EDT+Git.
В «долгоиграющих» проектах стандартный захват объектов 1С в хранилище может привести к длительным простоям других разработчиков. Но и создавать под каждую доработку отдельное хранилище, чтобы использовать технологию разветвленной разработки конфигураций от фирмы «1С» – избыточно. Расскажем о том, как разрабатывать в отдельной базе без ожиданий, а потом с легкостью перенести изменения в хранилище, используя основную идею технологии 1С – конфигурацию на поддержке хранилища.
Скрипт для работы с SonarQube и локальным репозиторием Git.<br>
Цель проекта – возможность выполнить быструю проверку качества кода перед тем, как помещать доработки в рабочее хранилище. В Sonar и Git выгружается не вся конфигурация, а только объекты из заданного списка.<br>
https://github.com/vkrivov/go/
Не знаете, чем бы таким заполнить свой профиль Github? Заполните его своими статьями на Инфостарт! Этот простой workflow сам соберет список ваших последних статей и будет периодически обновлять его для актуализации данных.
Доработки 1С:ERP на крупных проектах можно организовать, не внося изменения в саму типовую конфигурацию, а используя только расширения и отдельные «микроконфигурации». Расскажем о том, как это сделать без EDT, используя процесс разработки GitHub Flow.
Сегодня мы посмотрим на Github Actions - встроенный инструментарий Github для автоматизации рабочих процессов. Разберем, что это такое, зачем и причем тут OneScript.
GitFlic – первая в России полностью самостоятельная реализация сервиса для хранения репозиториев с исходным кодом. За три года разработки сервис GitFlic стал полноценным инструментом, которым можно заменить GitLab, GitHub и BitBucket. Расскажем о том, как выстроить в GitFlic процесс автоматического тестирования, статического анализа кода и сборки приложений.
Open-source проекты - важная часть мира программного обеспечения. 1С привычно держится немного в стороне от глобальных трендов, но бросить холодный статистический взгляд на положение дел мне показалось небезынтересным.
Продолжение истории с прокси хранилища, но уже не на HTTP, а на TCP и без падений по памяти веб-сервера. Проверяем комментарии хранилища, вызываем веб-хуки, старты пайплайнов, gitsync по событию помещения версии в хранилище. И все это полностью на знакомом и понятном OneScript.
Хранилище конфигурации 1С - это инструмент групповой разработки. Работают с хранилищем следующим образом: захватывают какой-либо объект, редактируют, потом отдают его в хранилище. Хранилище помечает уже захваченные объекты и не дает возможности захватить их другим пользователям. Это рождает и самый большой недостаток хранилища - невозможность работы с одним объектом нескольких пользователей, например в случае доработки разных методов в одном большом модуле.
Корень конфигурации - это самый верхний ее узел. Только захватив корень, мы можем добавить в конфигурацию новые общие модули, документы, справочники, регистры и подобное. Только захватив корень можно изменить настройки поддержки конфигурации. Соответственно, если корень захвачен одним программистом, другой программист не может добавить новые объекты или снять что-то с поддержки.
Потому то и всплывает эта фраза - отдай корень, мне нужно тоже что-то добавить.
Чтобы перейти от разработки в хранилище до полноценного релизного цикла CI/CD, с автотестированием кода, сборкой конфигураций из исходников и ветками разработки для каждой задачи, нужно пройти большой путь. Расскажем о том, как организовать полностью автоматическую доставку проверенного и рабочего кода в 2000 конфигураций.
Основная специализация Jenkins – это, прежде всего, CI/CD. Но его можно использовать и для других важных задач: разбора хранилищ, настройки копий баз данных, раздачи прав пользователям, рестарта кластера и проверки кода проектов.
Статья даёт ответы на некоторые вопросы, возникающие у разработчиков, которые погружаются в океан технологий EDT и Git, омывающий царство DevOps... Сколько и какие ветки нужны? Какой репозиторий выбрать? Кто должен сливать доработки в мастер ветку или ветку версии? Как не тратить время в EDT на ресурсоёмких операциях? Зачем нам сборочный конвейер и как его построить? Зачем нам нужно тестирование и как его реализовать? Как вести разработку, если есть разработчики, не умеющие вести разработку в EDT или не имеющие технической возможности, но нам нужны их skills в 1С? Что такое фантомы и нужно ли с ними бороться? Как слить 20 доработок с конфликтами и уложиться в 4 часа? Опыт использования модных технологий в реальных проектах.
Итак! Представим, что наступил момент, когда разработка через исходный код реализована на предприятии в полном объеме. Мы разрабатываем в EDT или конфигураторе (но выгружаем конфигурацию в исходный код), версионируем внешние отчеты и обработки и расширения, собираем релизы, проверяем код статическим анализом, в разработке царит гармония и мир. Красота!
Но менеджерам этого мало, всегда хочется чего-то еще, и вот мне прилетает задача - дай статистику по вкладу в код каждого разработчика.
Ведущий разработчик 1С Андрей Карпов на конференции Infostart Event 2021 Post-Apocalypse поделился ошибками, которые совершают новички в работе с GIT. В докладе четыре кейса с пошаговыми инструкциями, которые позволят не допускать конфликтов в разработке.
Избавляемся от версионной зависимости, проверяем комментарии, вызываем веб-хуки, делаем красивые пути. И все это на привычном IIS и понятном OneScript.
Рано или поздно многие компании приходят к практикам DevOps. И начало этому – Continuous Integration. О том, что происходит в команде специалистов 1С, когда они переходят на Git, и почему простое внедрение CI-инструментов не решает проблему подходов к разработке, в докладе на Infostart Event 2021 Post-Apocalypse рассказал руководитель компании ПрогТехБизнес Александр Анисков.
Когда хранилищ много, возникает вопрос удобного управления ими. Андрей Овсянкин на онлайн-митапе «Инструменты автоматизации рутины в 1С-разработке» рассказал, как настроить перенос хранилища на новую версию платформы без перепрописывания путей у каждого разработчика, и как безболезненно обеспечить для хранилища запрет коммита с пустым комментарием.
Как обычно происходит процесс доработки типовой? Разворачивается и используется рабочая база из какой-то типовой поставки 1С (БП/ERP/ЗУП и т.д.).
Далее бизнес постоянно приносит требования по доработке типового функционала (отдельный вопрос, зачем это нужно).
Возникает задача организовать постоянное изменение типовой конфигурации группой программистов.
На мой взгляд, это довольно частая задача. Хотелось бы рассмотреть возможные варианты ее решения.
Нигде не нашел упоминаний о подходах решения такой задачи, хотя, думаю, многие работают в таком режиме.
Бывают ситуации (в моей практике - постоянно), когда нужно работать с одним хранилищем конфигурации из-под разных версий платформы.
Предлагаю свой вариант решения.
Стек технологий, которые могут быть полезны разработчику на 1С и около 1С. По каждой технологии постарался объяснить, зачем она нужна и с чего начать изучение, если заинтересует.