Командная разработка облачных продуктов, используя 1С:EDT

05.09.23

Разработка - DevOps и автоматизация разработки

Даже в рамках одной компании подходы к организации командной разработки могут отличаться: методикой работы с ветками, организацией тестовых и разработческих контуров, параллельным использованием хранилищ или полным переходом на Git. Расскажем, какие варианты распределения серверных стендов и организации CI/CD выбрали для своих команд тимлиды двух отделов, и как у них происходило внедрение 1С:EDT.

 

 

Владислав: Меня зовут Владислав Маковеев, я выступаю вместе с моим коллегой Виталием Черкасовым.

 

 

Расскажем о том, как мы разрабатываем: что к нам пришло вместе с EDT, как мы вообще пытаемся адаптироваться в этом мире.

 

 

Владислав: Особенность нашей разработки в том, что мы дорабатываем облачные решения, поэтому все наши информационные базы обязательно должны быть опубликованы на сервере 1C и взаимодействовать между собой.

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

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

Владислав: Мы вывели несколько подходов к тому, как можно с этим работать.

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

  • Второй – когда свой стенд есть у каждого разработчика.

  • И третий подход – это когда существуют только основные и тестовые серверные стенды, а все доработки этого облака ведутся на локальных машинах разработчиков. У каждого из них на ПК развернута виртуальная машина с мини-сервером для локальной разработки.

Мы выбрали первые два подхода и сейчас про них расскажем.

 

Распределение серверных стендов: когда под каждый технический проект выделяется отдельный стенд разработки

Виталий: Наша команда разработки пошла по первому пути – у нас на один стенд назначен один технический проект.

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

Схема работает следующим образом:

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

  • При получении задачи разработчику необходимо создать ветку и связать ее с соответствующим стендом.

  • Когда разработка завершена, разработчик выполняет слияние с веткой master, которая находится на основном стенде.

  • И потом изменения в ветке master, в свою очередь, вливаются в общий с заказчиком репозиторий.

 

 

Виталий: Схема сама по себе достаточно простая, но хочется затронуть ее недостатки:

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

  • Второй минус – если много активных технических проектов, нужно разворачивать новые стенды. А когда мы разворачиваем новые стенды, возрастает нагрузка на сервер.

 

 

Виталий: Теперь о плюсах.

  • Возникает единое пространство для разработчика и тестировщика. После того как разработчик завершил внесение изменений на стенд, к работе подключается тестировщик и выполняет проверку. Они вместе работают на одном стенде и друг другу никак не мешают.

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

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

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

Схема достаточно простая, и она нас сейчас полностью устраивает.

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

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

  • добавляются локальные базы, где разработчики добавляют свою функциональность;

  • после чего они делают мерж-реквест в ветку, которая привязана к основному тестовому стенду;

  • и опять-таки выполняется слияние с мастер-веткой.

 

Распределение серверных стендов: когда отдельный стенд разработки выделяется под каждого разработчика

Владислав: Теперь о порядке разработки в нашей команде.

Изначально мы придерживались такого же подхода, и стенды у нас разворачивались под техпроект. Единственным отличием было то, что под каждый техпроект разворачивалось два стенда:

  • первый – для разработки, Dev;

  • и второй – тестовый сервер, TSN (Test Server N).

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

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

Владислав: Поэтапно пройдемся по этой схеме:

  • У нас появился стенд RC (Release Candidate), на котором содержится самая актуальная версия, выпущенная в релиз.

  • Также используются стенды DM (Develop Master) и TM (Test Master). На них также находится актуальная версия, но уже с внесенными доработками, исправлениями ошибок и прочим – с тем, что войдет в будущий релиз.

  • И далее к этим стендам уже присоединяются стенды DevN, которые относятся к конкретным разработчикам. Разработчики делают на них фиксы, фичи и потом отправляют мерж-реквест, чтобы влить это в Develop Master. Таких стендов может быть несколько, потому что разработчиков у нас много, и их количество может увеличиваться.

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

 

 

Владислав: Таким образом, мы столкнулись со следующими недостатками.

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

  • Исходя из первого минуса, появляется второй. Если мы замещаем конфигурацию, у нас и данные могут удалиться – у нас же на разных проектах объекты метаданных в большинстве случае будут меняться. А при изменении метаданных данные в информационной базе могут очищаться. Чтобы обойти этот эффект, мы пока что используем внешнюю обработку «Выгрузка и загрузка данных XML» и выгружаем нужные данные в XML, а потом при необходимости загружаем обратно. Но также думаем, как вообще можно оптимизировать данный шаг.

  • Третье – это то, что при увеличении размера команды у нас увеличивается количество стендов. Изначально мы пытались уйти от нехватки серверного пространства, чтобы под каждый проект, которых у нас много, не нужно было разворачивать отдельный стенд. И поскольку у нас разработчиков меньше, чем техпроектов, мы смогли решить эту проблему. Но если количество разработчиков в нашей команде увеличится, то и стендов станет больше. И места опять станет не хватать.

  • И последний недостаток – это то, что для QA в некоторых случаях нужны отдельные стенды, потому что стенды разработчиков могут не соответствовать тому, что нужно протестировать. А это опять же у нас сжирает место на сервере, за счет чего увеличивается потребление.

 

 

Владислав: Но было бы грустно закончить на недостатках, поэтому поговорим про преимущества данного подхода.

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

  • Второе – это то, что мы экономим ресурс сервера. Мы не создаем лишних стендов, т.к. у нас их количество ограничено. А разработчиков меньше, чем техпроектов. Плюс мы также можем не все приложения разворачивать для разработчика, так как некоторые приложения фреша ему не нужны. В этом случае, опять же, экономится место. А если ему позарез понадобилось какое-то приложение, его развернуть не составит труда.

  • Третье – это то, что мы убрали боль из-за очереди в конфигуратор. Просто представьте: когда над одним проектом работают три программиста, у них начинается драка за то, чьи изменения нужно залить в первую очередь. Такие конфликты приходится решать либо тимлиду, либо они сами создают какую-то свою очередь. Мы убрали эту боль, и у нас нет драк за стенды – у нас все тестируют на своих стендах.

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

    • Первое – на стенде всегда должны быть валидные тестовые данные. Например, недопустимо, чтобы в справочнике «Контрагенты» элементы назывались просто «Тест1» и «Тест2».

    • Второе – версии конфигурации на стенде обязательно должны быть актуализированными и не отставать от релизных.

    • И последнее – нужно писать код так, чтобы не ушатать сервер.

  • И пятое преимущество – в такой парадигме удобно работать в небольшой команде. Мы всегда знаем, где кто работает.

 

Работа с ветками Git. Вариант доработанного GitFlow

Владислав: Теперь немного поговорим про Git. В нашей команде разработки мы используем методологию GitFlow. Выглядит она примерно так, как на слайде, но с небольшими изменениями.

Владислав: Изменения состоят в том, что из веток future и веток HotFix у нас создаются дополнительные ветки. Они нужны, поскольку у нас есть джуниор-разработчики, которые иногда не понимают, как правильно писать код и допускают ошибки в оптимизации.

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

Для этих веток есть некоторый регламент:

  • они должны называться так же, как и основная ветка;

  • они не должны жить более одного рабочего дня – это важно, чтобы они у нас не плодились, иначе их будет очень много. Но есть исключения:

    • когда ветка не прошла мерж-реквест – тогда в нее сначала нужно внести исправления, а потом снова вливать;

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

На подобных код-ревью мы джуниоров обучаем и не допускаем, чтобы они пушили в основные ветки (у них на это нет прав).

 

Владислав: Для трека задач мы используем Jira – в ней удобно работать, и у нее есть интеграция с Git-сервером:

  • можно использовать Bitbucket;

  • либо скачать в маркетплейсе Jira приложение для интеграции с GitLab и установить его для определенной доски – мы разрабатываем в GitLab, потому что там есть бесплатные закрытые репозитории, и нет ограничений по пользователям.

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

Владислав: После выбора открывается диалог создания ветки, где мы указываем, где ее создать и как назвать.

Интеграция автоматически подставляет наименование этих веток с единственным отличием:

  • в GitLab имя ветки пишется транслитом на латинице и полностью;

  • а в Bitbucket имя ветки пишется на кириллице, но при этом вставляется не полностью.

Эти особенности разворачивания следует учитывать.

Владислав: В GitLab интеграция с Jira тоже встроена – там в коммитах можно указывать ссылки на задачи. При этом неважно, откуда вы сделаете коммит – из EDT или из консоли. Мы в коммите GitLab можем нажать на ссылочку, а дальше нас перекинет на карточку задачи.

Владислав: Настроить такие интеграции в самом GitLab можно на вкладке «Интеграции». Если на стороне Jira интеграция настроена, там появится зеленая галочка, что все окей, и вы сможете указывать в коммитах ссылки на задачи.

 

Работа с ветками Git. Вариант доработанного GitHub Flow

 

Виталий: Теперь про использование Git в нашем отделе.

Мы используем методологию GitHub Flow, только немного измененную. Причем мы используем GitHub Flow для GitLab.

Особенность нашего GitHub Flow в том, что мы не делаем мерж-реквесты в мастер-ветку, а делаем слияние в ветку разработки – почему мы так делаем, я расскажу чуть позже.

У нас есть небольшой регламент по наименованию веток для техпроектов:

  • сначала идет feature – то есть мы добавляем что-то новое;

  • дальше идет код технического проекта в СППР;

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

 

CI/CD. Подход через полный переход на EDT и Git

Владислав: Пока мы разбирались с EDT и разворачивали Git, нам пришла мысль: почему бы нам не организовать у себя CI/CD?

Мы подошли к этому основательно, поскольку у нас уже были свои написанные приложения, которые позволяют нам: администрировать кластер; автоматически разворачивать в нем информационные базы; загружать туда dt-шники или конфигурации. В общем, все, что нужно, чтобы пройти автотесты либо еще что-то.

Владислав: Пока что у нас CI полностью не реализован, но я с вами поделюсь планами, каким он будет:

  • Первое, что у нас происходит – это push либо merge request. Таким образом, мы сначала что-то мержим.

  • Далее у нас запускаются ранеры от GitLab, которые у нас развернуты на сервере, и эти ранеры уже начинают запускать скрипты Jenkins.

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

  • После того как все это было успешно развернуто, запускается скрипт Jenkins, использующий фреймворк тестирования Vanessa, который начинает прогонять на этом новом стенде сценарии тестирования.

  • И далее уже по исходу у нас приходит сообщение от специального telegram-бота, что мерж-реквест успешно прошел автотест, его можно заливать.

  • Или, если все плохо, то он пишет, какие ошибки есть, их количество. В будущем потом это можно будет посмотреть в отчете Allure либо в СППР.

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

 

CI/CD Подход с использованием хранилищ и 1С:ГитКонвертер

 

Виталий: Теперь немного про CI/CD в нашем отделе.

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

  • Исходя из этого, у нас вытекает второй пункт – мы используем 1С:ГитКонвертер, чтобы выполнять синхронизацию наших репозиториев в Git и хранилищ.

  • Третий пункт – разработку мы выполняем с помощью EDT в рамках технических проектов. Hotfix выполняем с помощью расширений с прямой установкой на прод руками и помещением напрямую в хранилище.

  • Четвертый пункт – как я уже говорил в блоке про Git, слияние мы выполняем не в мастер-ветку, а в ветку разработки. Это важно, чтобы использовать полную функциональность EDT для разрешения конфликтов Git – мы сначала делаем слияние, затем получаем итоговую конфигурацию, выгружаем ее, и дальше уже выполняется стандартная работа по перемещению доработок в хранилище.

Виталий: Для проверок мы используем SonarQube. Это удобно, потому что:

  • Он работает с исходниками ровно так же, как и EDT. Не нужно ничего конвертировать, выгружать. Взяли локальный репозиторий, запустили проверку SonarQube, и все хорошо работает.

  • У него есть фильтр по автору ошибки – это работает, когда SonarQube используется в связке с Git.

  • У него есть большое количество проверок – там есть проверки как на сам код, так и на восприятие (когнитивная и цикломатическая сложность)

  • И в SonarQube достаточно удобный просмотр замечаний – они выполнены в виде карусельки.

 

 

Виталий: Выглядит это так как на слайде. У нас есть проект SonarQube. В левом нижнем углу выделен блок с отбором по автору, который выводит в основную область мои косяки.

 

 

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

А слева предоставлена каруселька, где можно смотреть замечания.

 

Разработка в 1С:EDT. Плагины

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

  • Первое – наша команда для проверок внутри EDT использует проект v8-code-style, который встроен в EDT, начиная с версии 2021.2 и выше. Плюс v8-code-style в том, что он проверяет соответствие стандартам не только кода, но и еще метаданных.

  • Второй плагин, который мы используем активно, это 1C:SSL – он хорошо помогает при работе с БСП.

  • Мы отказались от «Коннектора BSLLS для 1С:EDT», потому что он достаточно сильно тормозил систему и не всегда адекватно реагировал на исправление. Джунов это иногда вводило ступор – они бежали, спрашивали: «Что у меня произошло? Я ошибку исправил, она не исправляется». Смотрю – действительно, ошибка исправлена, но все равно помечено, что осталась.

  • И четвертый плагин – Open Editors. Он хорошо помогает, когда есть много открытых вкладок.

Владислав: Мы используем те же самые плагины. За исключением того, что у нас в отделе пока что пользуется спросом «Коннектор BSLLS для EDT», и на v8-code-style мы не перешли – но это на самом деле вопрос времени.

Также я пробовал использовать разные плагины для работы с GitLab, чтобы можно было внутри EDT автоматически проводить мерж-реквесты и не переходить при этом в отдельное приложение – не запускать ради проверки браузер. Но подходящего плагина пока что под себя не нашел и возможно в будущем уже сам напишу для себя плагин, при помощи которого можно будет выполнять мерж-реквесты внутри EDT.

 

Боли использования 1С:EDT

Виталий: Теперь про сам опыт.

Первое, что необходимо при работе с EDT – это добавить в исключение антивируса каталоги, которые он использует:

  • каталог программной среды;

  • каталог с локальными репозиториями;

  • и workspace.

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

Владислав: А второе – это то, что при работе с EDT могут происходить ошибки, которые вообще не очевидны.

Например, мы переименовали какую-нибудь общую команду в глобальном контексте, и у нас при импортировании проекта в конфигурацию информационной базы возникает ошибка: «Неверное имя команды формы».

Мы понимаем, что проблема в файле объекта, и, чтобы ее найти, воспользоваться обычным поиском по конфигурации не получится.

 

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

 

Владислав: Все, что здесь остается – это просто открыть этот файл объекта через текстовый редактор и поправить, в зависимости от того, что вы сделали – переименовали или удалили.

Владислав: Третий пункт – это добавить в конфигурацию Git параметры, которые предоставлены на слайде.

Немного о самих параметрах.

  • Первый – это core.quotePath в значении false. Он нужен, если используется команда Git, которая выводит какие-то пути, где используется кириллица. В мире 1С кириллица используется почти всегда, а Git по умолчанию преобразует символы кириллицы в нечитаемый вид.

  • Следующий параметр – это core.autocrlf в значении true. Очень помогает, если есть разработчики на разных операционных системах. Этот параметр преобразует все окончания строк в единый вид.

  • Следующий параметр – это core.safecrlf в значении true. Он работает в связке с параметром core.autocrlf и выполняет отмену. Когда у Git не получается выполнить преобразование окончаний строк, он делает откат.

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

Следующий пункт стал у нас в команде регламентом – это не обновлять EDT до самой последней версии. Это связано с тем, что самые актуальные версии выходят в бете, и при работе с ними могут возникнуть критические ошибки, которые либо очень сильно замедлят работу с EDT, либо вообще ее застопорят. Поэтому мы держимся хотя бы за одну версию до актуальной.

Еще из общих моментов хочу сказать, что в EDT:

  • пока достаточно тяжело работать с макетами табличных данных;

  • и достаточно тяжелая отладка при больших конфигурациях.

 

Вопросы

 

В каком интерфейсе разработчик делает запрос на мерж-реквест? В GitLab заходит?

Владислав: Да, заходит в GitLab.

И ответственный за мерж-реквест выполняет это код-ревью тоже в интерфейсе GitLab?

Владислав: У нас это можно трекать либо в задаче Jira, либо он проводит код-ревью в интерфейсе GitLab.

А не было идеи, чтобы все это было в Jira – чтобы в Jira можно было и запрос сделать, и получить задачу на выполнение?

Владислав: Идеи были. Но мы сейчас с Jira работаем как с экспериментальным продуктом, потому что все равно пользуемся СППР. Нам удобно дорабатывать СППР под свои нужды при необходимости.

А Jira для нас пока – не обследованный до конца объект, мы там пока что нарабатываем опыт и улучшаем процессы. Возможно, позже, как вариант, реализуем.

Поделитесь опытом, как много времени нужно, чтобы перевести разработку из конфигуратора на EDT? В масштабе одного разработчика.

Владислав: Я не буду говорить о масштабе одного разработчика. У нас все же целая команда, и если мы переходим, то все.

В нашей команде мы разрабатываем облачный продукт, и я его смог перевести на EDT полностью за две недели. В это входил импорт исходников из хранилища в Git с помощью 1С:ГитКонвертер.

И в дальнейшем мы проводили обучение наших сотрудников, чтобы они полностью вникли, как работать с EDT и как работать с GIT – до этого они EDT видели, но не работали в ней полноценно.

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

Мы занимаемся проектами, и у нас, как правило, разработка идет на среде заказчика – мы разрабатываем чисто в хранилищах. Что можно предложить заказчику, чтобы мы на его среде разрабатывали с использованием CI/CD-технологий?

Виталий: Тут можно использовать переходную схему работы EDT, когда хранилища остаются, а 1С:ГитКонвертер конвертирует хранилища в Git. Тогда и заказчик остается со своими хранилищами, и вы организуете CI/CD на основе исходников в Git.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.

 

10 - 12 октября 2024 года состоится конференция INFOSTART EVENT, на которой прозвучит 130+ докладов.

Темы конференции:

  • Администрирование серверов 1С и СУБД. HighLoad оптимизация
  • Инструментарий разработчика. Приемы и методы разработки 
  • Интеграция и обмен данными 
  • Мобильная разработка и чат-боты 
  • Управление проектом и продуктом 
  • Управление командой 
  • Управление ИТ 
  • Мотивация, лидерство и личная эффективность 
  • Идеи и тренды в разработке

INFOSTART EVENT - крупнейшая профессиональная конференция для программистов 1С.


Подробнее о конференции.

 


См. также.

DevOps для 1С DevOps и автоматизация разработки Программист Стажер Платные (руб)

Данный онлайн-курс (интенсив) предусматривает изучение процессов, инструментов и методик DevOps, их применение при разработке на платформе 1С. 

9000 руб.

20.06.2023    17024    1    3    

253

Тестирование QA DevOps и автоматизация разработки Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.16.115.

2220 руб.

04.07.2022    7327    32    1    

25

Тестирование QA DevOps и автоматизация разработки Программист Пользователь Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.144.49.

1728 руб.

20.01.2022    6992    17    0    

11

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Программист Стажер Платформа 1С v8.3 Платные (руб)

Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8

4900 руб.

29.06.2022    10000    81    4    

114

DevOps и автоматизация разработки Системный администратор Программист Руководитель проекта Платформа 1С v8.3 Конфигурации 1cv8 1С:Франчайзи, автоматизация бизнеса Платные (руб)

Подсистема «Управление сборкой GLI» предназначена для динамического формирования сборочных линий Gitlab и отслеживания процесса доработок систем на базе1С:Предприятия Позволяет упростить выпуск новых релизов системы, подготовить описание доработок системы. Интегрируется с GitLab API по событиям Push, Merge-request, Pipeline. Уведомляет пользователей о результатах сборки/тестирования сборочных конвейеров через СВ, либо при её недоступности или отсутствию по E-Mail. Поможет при отправке исправлений ошибок в общую базу тестирования, сформирует запросы на слияние в ветку версии только по протестированному и подтверждённому функционалу. Подсистема рассчитана исключительно на клиент - серверную архитектуру тестовых ИБ. Поддерживаемая версии СППР 2.0.4.15, платформа не ниже 8.3.17.1549, 2.0.7.3 / не ниже 8.3.21.1664, начиная с релиза 1.0.4.30 требуется платформа не ниже 8.3.23 рекомендуемый релиз 8.3.23.1997

7000 руб.

26.08.2022    11333    8    5    

32

DevOps и автоматизация разработки OneScript Системный администратор Программист Стажер Бесплатно (free)

Рассмотрим создание самоформирующейся документации через комментарии и соглашения: как это сделать и зачем, с описанием полного цикла от исходников конфигурации до странички в интернете

17.06.2024    2447    bayselonarrend    2    

54

DevOps и автоматизация разработки 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

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

27.05.2024    2112    PROSTO-1C    25    

24

DevOps и автоматизация разработки Бесплатно (free)

Можно ли идеи подхода «Архитектура как код» положить на 1С или иную платформу, чтобы не изобретать ещё какой-то язык и сразу получить множество готовых библиотек функций и инструмент достижения главной цели подхода AaC.

01.02.2024    3196    roman72    9    

9
Оставьте свое сообщение