APDEX 1C + Prometheus + Grafana + Superset, а точнее наоборот

Публикация № 1606108 16.02.22

Приемы и методы разработки - DevOps и автоматизация разработки

APDEX 1C Prometheus Grafana Superset

Вы не задумывались о том, что расчет APDEX должен быть онлайн? Онлайн для всех - от бизнес-пользователей до команды разработки. Если задумывались - то в статье мы расскажем, зачем это делать, и поделимся наработками, как подключить 1С+APDEX к такой штуке, как Prometeus.

Здравствуйте, мои маленькие любители программирования. Сегодня мы поговорим об ….

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

В порядке знакомства

Зовут меня Валентин Козлов. Я начинал свою карьеру простым разработчиком 1С и дошел до руководителя отдела ИТ в компании являющейся частью глобального концерна. За годы работы мы смогли создать уникальную команду ИТ, способную решать задачи любой сложности, со средним сроком работы разработчиков 6 лет, и нам было совершенно не важно на каких технологиях мы решим ту или иную задачку. Поэтому я могу с полной уверенностью сказать, что в ИТ главное люди - а не технологии. По моему мнению, сработанная команда из 3-5 инженеров, которым «непофиг», может полностью изменить компанию изнутри и вывести её на первые места в отрасли. Для того, чтобы это произошло, этими людьми должны управлять люди, способные понимать все нюансы работы в ИТ и самое главное, что мотивирует и демотивирует инженеров. Именно поэтому сейчас есть огромный спрос на ИТ-лидеров, способных своими руками «делать страшное», а эра классических ИТ менеджеров потихоньку уходит в закат (да простят меня классические ИТ менеджеры 😊).

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

Постановка проблемы и формулировка задачи

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

Итак - предположим, у вас как в свое время и у нас есть проблема

  • В условиях непрерывной разработки неизбежна ситуация, когда системы и продукты начинают “тормозить”
  • Отдать технический долг быстро почти невозможно, для начала много времени будет затрачено на поиск неоптимальных мест

Отсюда и возникла задача:

  • Измерить производительность наших ключевых операций для всех наших сервисов-продуктов, которых у нас больше 30 и количество их постоянно растет

На момент написания статьи у нас было 4 основных стека: 1C, Python, GoLang и C#, поэтому нам нужна была стандартная методология замера производительности операций, вместе с этим было важно предоставить “сервис для команд” который будет помогать им каждый спринт видеть какой технический долг отдать надо сегодня и какую ключевой операцию починить

Особенности решения (ADR)

В качестве рекомендуемой методики мы, недолго думая выбрали APDEX. И не потому, что она простая - есть и более качественные методики. Самыми главными критериями были:

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

И для тех, кто совсем не в курсе “за методику” APDEX дам вам небольшое определение из ссылки выше:
Apdex (Application Performance Index) - это открытый стандарт для измерения производительности программных приложений в вычислениях. Его цель - преобразовать измерения в информацию об удовлетворенности пользователей, указав единообразный способ анализа и составления отчетов о том, в какой степени измеренная производительность соответствует ожиданиям пользователей. Он был разработан альянсом компаний.

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

  • Prometheus для сбора метрик - “Коллектор”
  • Grafana для оперативного отслеживания метрик инженерами - “Отображатель и оповещатель”
  • Superset для анализа накопленной аналитики - “Анализатор”
  • В качестве хранилища и источника данных для Superset был выбран PostgreSQL с расширением TimescaleDB - “Хранилище накопленных метрик”

Мы получили следующую схему:

 

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

 

Инфраструктурный сервис

Особенность сервиса

Потенциальный выигрыш в перспективе

Prometheus

Сервис провоцирует разработчика думать о метриках самому - то есть идея сервиса в том, что “Только разработчик продукта знает какие точки и метрики ему мониторить”, в отличие от Zabbix агента - где метриками управляют админы, которые ничего не знают про продукт

Обучающий эффект - когда команда продукта еще на этапе проектирования будет расставлять точки мониторинга - и это будет часть официального беклога команды

Grafana

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

Накопление готовых элементов в формате JSON/YAML с последующим переиспользованием между командами продуктов - вне зависимости от языка программирования

Superset

Сервис провоцирует инженеров погружаться в концепцию SelfService-Bi - а не ждать пока выдадут доступ на платные сервисы типа PowerBI/1C-Аналитика/Tableu/etc

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

TimescaleDB

Сервис провоцирует инженеров изучать специализированные хранилища данных - в частности хранение временных рядов

Обучающий эффект - позволяет изучать экосистему PostgreSQL, без необходимости внедрять спец средства типа Yandex ClickHouse - то есть инженер развивается как DBA изучая теорию СУБД.

 

В качестве пилота был выбран один из наших сервисов написанных на Python. Для сбора метрик использовалась стандартная SDK “Prometheus Python Client”. Мои коллеги, успешно реализовали пилот и быстро получили свой дашбоард и быстро поправили неоптимальности…

То есть - в данном случае, исследовать особенности “прометея и не пришлось”

1С конфигурация про Open Telemetry не знает ничего

После пилота дошла очередь и до 1С. С ней все оказалось сложнее так как «проклятые буржуи» не сделали SDK для 1С, поэтому пришлось «колхозить» свой вариант реализации 😊. Для этого пришлось изучить формат выгрузки метрик и разобраться с их типами. Согласно документации Prometheus данные по APDEX должны «ехать» с типом метрик «histogram».

Вообще здесь важно обратить ваше внимание на несколько особенностей сервиса Prometheus которые заложены в нем архитектурно

  • Первая особенность Prometheus: Модель API максимально абстрагирована, чтобы позволить загружать и рассчитывать любые метрики приложений

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

1 раз в минуту. Да - мы хотим видеть Continuous APDEX !!!

То есть команда может глядеть на свой APDEX раз в день, а сервис должен получать их раз в минуту — это важное требование. Потому что почистить и сжать метрики мы сможем всегда - а вот переделывать загрузку, когда нам понадобится изменить частоту отправки совершенно не хочется, плюс это стало дополнительным тестом на производительность самого “Прометея”.

  • Вторая особенность Prometheus: Служба “Прометея” желает подключаться к API приложения и делать оттуда PULL метрик

А у нас при интеграции есть одно из наших любимых правил

 «сосать плохо»

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

Адаптер 1С-Prometheus

Как же в итоге сделан - адаптер на стороне 1С. Внимание - сейчас будет минутка программиста.

В расширении перехватываем запись стандартного регистра "ЗамерВремени” из БСП и формируем данные в нужном нам формате в регистре “APDEXMetrics”:

 

 

По итогу получаем данные по каждой ключевой операции с количеством раз выполнения нарастающим итогом в разрезе бакетов. Бакеты — это временные интервалы выполнения ключевой операции. Для оптимизации скорости сбора данных было денормализовано общее количество для ключевой операции и в отдельно записали общее фактическое время всех измерений (Время выполнение операций):

 

 

Для отправки метрик выбираем данные из регистра APDEXMetrics:

 

 

Формируем метрику в нужном формате:

 

 

и отправляем данные в Pushgetway:

 

 

Ну и из Ынтересного. Обратите внимание, что все метки (Labels) формируются в кодировке base64. Это нужно, чтобы русские букавки выводились корректно:

 

 

Красивые результаты, что видят наши команды

Когда метрики были доставлены до Prometheus, дошла очередь для формирования красивых бордов в Grafana:

 

 

 

Далее метрики из Prometheus были перенаправлены в PostgreSQL и выведены в общий борд Superset-а по APDEX:

 

Заключение

Все доработки по 1С живут в моем репозитории 1C_PrometheusExporter там же есть подробная инструкция по адаптации расширения. Есть множество микро идей как его можно развить, например:

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

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

В любом случае - в следующей статье я расскажу вам, как мы «вывезли» в Superset логи журнала регистрации, какие проблемы у нас были и как мы их решили, ну и конечно выложу рабочие инструменты позволяющие повторить «наш подвиг» 😊.

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

P.S. Обратите внимание, пока мой аккаунт "отбрендирован" как корпоративный - это временное решение, так как мы хотим уже начать делиться с сообществом, а наши корпоративные закупщики пока согласуют деньги ;-) на корпоративный аккаунт.

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. ImHunter 247 16.02.22 12:24 Сейчас в теме
2. digital-samolet 102 16.02.22 12:31 Сейчас в теме
(1) Вопрос больше евангелистический - над нами давлеет то что нам нужно на несколько платформ - а у Python/Golang - Prometeus+loki+graphana - это стандарт. ELK как бы нет
3. comol 4662 16.02.22 12:59 Сейчас в теме
(1) "Стеку ELK гореть в аду". По крайней мере для таких задач. Ну оооочень дорого.
4. ImHunter 247 16.02.22 12:59 Сейчас в теме
(2) Ясно. Так исторически сложилось)
5. comol 4662 16.02.22 13:00 Сейчас в теме
А вот почему push gateway... не пытались pull сделать - классический для прометеуса подход?
8. Frog 16.02.22 13:06 Сейчас в теме
мы не любим когда у нас сосут :-).
anosin; amon_ra; botokash; +3 Ответить
6. ImHunter 247 16.02.22 13:00 Сейчас в теме
(3) Гхм. А в чем дорого? Если спец модули не нужны, то как бы и забесплатно.
7. comol 4662 16.02.22 13:02 Сейчас в теме
(6) x10 к объёму хранения + процессор/память сопоставимы с продом. + 3 ноды + если более 1ТБ журналов получится (а у вас получится) на Elastic gold попадаете. Ну или если хоть какой то инфобез есть в компании и нужна ролевая модель к эластику
16. IT_Magnit 16.02.22 15:01 Сейчас в теме
(7) На одной ноде живем с более 1 ТБ журналов
17. comol 4662 16.02.22 15:06 Сейчас в теме
(16) Отвага и .... :)))
Эластик в принципе официальная рекомендация от 3-х нод. Но можно и на одной конечно запустить и в докере на десктопе без рейда, кто же запретит :)
18. IT_Magnit 16.02.22 15:18 Сейчас в теме
(17) Всегда все делаешь по официальным рекомендациям?))) И в 1С в СУБД не ногой?)
Для разбора логов прекрасно подходит и одна нода, проблем не наблюдаем. В день около 60 млн записей.
20. comol 4662 16.02.22 15:55 Сейчас в теме
(18) Ну вообще я ещё "немного" его внутри знаю. И собственно говоря потерять все данные вообще не проблема. Кроме всего прочего нагрузка на диск просто лютая. 60 млн в день это ни о чём конечно, но добавить ноду уже будет проблемно - придётся индекс пересоздавать. Дисковая подсистема которая в одиночку выдерживает даже такую нагрузку это конечно круто, но... очень уж смело, да как и в принципе логи в эластик это смело.
IT_Magnit; +1 Ответить
9. ImHunter 247 16.02.22 13:06 Сейчас в теме
(7) Понял, пасиб.... Буду сильно иметь в виду.
10. Tavalik 2702 16.02.22 13:12 Сейчас в теме
Спасибо, что поделились. Хоть задач таких нет, но было интересно прочитать какие проблемы у других и как они их успешно решают.
11. Tavalik 2702 16.02.22 13:13 Сейчас в теме
На Инфостарте, как и давно уже на Хабре, начали появляться корпоративные аккаунты. Это радует! Лишь бы качество контента не падало за счет заказных статей ради статей.
15. IT_Magnit 16.02.22 14:01 Сейчас в теме
(11) В 2020 Инфостарт Магниту не разрешил публиковать статьи под корп. аккаунтом. Сказали, что только человек может статьи писать. И, мол, вообще нельзя, чтобы публикующийся аккаунт содержал название компании или её лого.
19. digital-samolet 102 16.02.22 15:54 Сейчас в теме
Мы явно хотим создать корпоративный аккаунт - но пока идут согласования бюджетов просто поделились интересным параллельно. Я так понимаю - это временное исключение, за что мы искренне благодарны команде Инфостарт
38. ix5s 60 21.02.22 11:55 Сейчас в теме
(15) такая же была ситуация, удаляли аккаунт с логотипом и названием компании
12. vovast 16.02.22 13:20 Сейчас в теме
Я правильно понял, что у вас для всех ключевых операций целевое время выполнения - 1 секунда?
13. digital-samolet 102 16.02.22 13:24 Сейчас в теме
(12) так точно - а для некоторых меньше секунды. Это сделано специально - чтобы 1С разработчики не делали ключевых операций длинных, а разделяли их на многопоточные. Такой подход используется в соседних платформах - стиимулировать разработчиков писать асинхронные многопоточные алгоритмы
JohnyDeath; It-developer; +2 Ответить
21. Tavalik 2702 16.02.22 16:55 Сейчас в теме
(13) Интересно. И как? Удается? Как быть с кодом типовых конфигураций?
JohnyDeath; +1 Ответить
23. It-developer 20 17.02.22 10:58 Сейчас в теме
(13)При этом понимание чужого кода или своего кода через время - нормальное?
14. Frog 16.02.22 13:52 Сейчас в теме
22. kraynev-navi 561 16.02.22 22:32 Сейчас в теме
(0) Вдохновляюще! С нетерпением ожидаю продолжение про superset. Спасибо!
24. digital-samolet 102 17.02.22 12:04 Сейчас в теме
25. JohnyDeath 300 17.02.22 21:29 Сейчас в теме
Режим совместимости расширения указан как "Версия 8.3.17". А типовые сейчас на 8.3.16 подзастряли.
Будут ли какие-то проблемы, если я изменю режим совместимости? Может вы завязывались на некие плюшки этого режима совместимости?
26. digital-samolet 102 18.02.22 08:44 Сейчас в теме
(25) Приветствую.
Не знаю, не тестировал. Я думаю, что может не работать только в части функционала расширений. Например, в 17 версии есть какая-то фишка с объектами, а в 16 нет. В любом случае сам алгоритм сбора и отправки метрик будет работать и переделать стандартный функционал не проблема.
По факту это просто MVP и вы можете дорабатывать его как хотите :-)
27. JohnyDeath 300 18.02.22 08:51 Сейчас в теме
(26) в любом случае - спасибо!

Осталось только с Графаной разобраться ) На "интуитивно" создать графики не получилось. Придется, наверное, документацию читать ))
28. digital-samolet 102 18.02.22 08:53 Сейчас в теме
(27) У меня в репозитории есть уже борд готовый в формате JSON, просто разберитесь как его загрузить ;-)
29. JohnyDeath 300 18.02.22 08:59 Сейчас в теме
(28) его я подгрузил, но что-то там полупустое всё. Поэтому вот и пытаюсь разобраться.
34. vovast 18.02.22 11:31 Сейчас в теме
(25) С режимом совместимости 8.3.16 работает
30. digital-samolet 102 18.02.22 09:20 Сейчас в теме
Скорее всего для борда нужно еще переменную создать. Скрин приложил
Прикрепленные файлы:
JohnyDeath; +1 Ответить
31. digital-samolet 102 18.02.22 09:23 Сейчас в теме
(30) Извиняюсь за дурацкий скрин: label_values(onec_business_transaction_duration_seconds_by_key_operation_­sum, exported_instance)
Прикрепленные файлы:
JohnyDeath; +1 Ответить
32. Jimbo 9 18.02.22 11:26 Сейчас в теме
Что за конфигурация 1с ?
После этих замеров нашли и оптимизировали хоть что-то ? Хотелось бы пару слов ещё конкретики.
33. JohnyDeath 300 18.02.22 11:30 Сейчас в теме
(31) Вроде бы импортировались сразу вместе с настройками
35. digital-samolet 102 18.02.22 12:01 Сейчас в теме
(33) Тогда придется ковырять. Не знаю.
36. user1407676 18.02.22 16:58 Сейчас в теме
Валентин, у меня вопрос по методике.
Все приведено к "односекундному" интервалу. Т.е. разработчики должны мегатяжелые операции раздробить. А как быть с теми, для которых 1 секунда это уже очень долго? Т.е. запрос в соседнюю систему за данными выполняется в разы меньше и это считается ключевой операцией. Укрупнять?
Я к тому, что почему не пошли по пути передачи непосредственно вычисленного апдекса из системы, например?

p.s. Может кому-то пригодится:
При применении дашборда в Графану пришлось немного руками код подправить в части источника. Почему-то Прометеус не распознавался.
Заменил rate на delta - так как-то понятнее с количеством операций в промежутке, в отличии от "Операций в секунду". Хотя все равно не целое значение отображается.
JohnyDeath; +1 Ответить
37. digital-samolet 102 19.02.22 21:07 Сейчас в теме
(36) Тут вопрос методический - мы скорее приглашаем наших продактов к дискуссии - они могут поменять свои целевые времена - мы решили что 1Секунда это прикольно - потому что во первых показывает что длительные операции это плохо. С другой стороны на микрооперации мы закрываем глаза - если пользователь хочет быстрей - ему ничего не стоит попросить нас уменьшить время - в формате я хочу чтобы "Операция XXX выполнялась за 0.2 секунды". По сути - наши команды живут в дружбе с пользователями - поэтому если кто-то не согласен - он может в рамках дискуссии изменить время. Сейчас среди программистов сложилась нехорошая практика - целевое время меняет сам программист - а ему выгодно поставить побольше время, ну чтобы сильно не заморачиваться. Причем такая порочная практика сложилась не только у 1С программистов, но и у GoLang/ Python/C#/Java программистов

Применение внешнего сервиса контроля целевого времени APDEX позволяет вынести данную метрику в зону публичного обсуждения - в том числе с группой QA.
Ta_Da; Shmell; +2 Ответить
39. vovast 24.02.22 09:29 Сейчас в теме
(37) Но ведь при текущей реализации у вас не получится в Grafana считать APDEX для операций с разным целевым временем выполнения? У вас в Grafana 1 сек в формулу расчета APDEX в явном виде внесена.
40. digital-samolet 102 24.02.22 10:07 Сейчас в теме
(39) У нас не было такой цели. Мы считаем, что любая бизнес-операция должна выполняться не более 1 секунды. С этим можно соглашаться или нет, но мы так считаем.
Если у вас стоит задача сделать несколько границ, то я бы сначала их логически разбил на несколько блоков (сейчас в 1С это неуправляемая штука, где можно поставить все что угодно), а дальше сделал бы дополнительный lable со значением этих блоков и построил бы несколько бордов. В любом случае, если конфигурация большая вы никогда не достигните 100% APDEX, но сразу будете видеть отклонения, с которыми нужно работать.
41. fregl 06.03.22 00:27 Сейчас в теме
Спасибо за статью, очень познавательно.
Подскажите, когда планируете следующую про логи журнала регистрации?
42. digital-samolet 102 07.03.22 10:51 Сейчас в теме
(41) Здравствуйте.
Спасибо за обратную связь.

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

См. также

Быстро в Jenkins

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

Написать свою сборочную линию для решения на 1С – задача нетривиальная: собрать конфигурацию из исходников, конвертировать между форматами, запустить множество инструментов, агрегировать результаты, сформировать отчеты... А хочется ведь просто ЗапуститьСвоюСборку()... Можно? Можно! О том, как создать сборочную линию за 5 минут в формате «Далее-далее-готово» на конференции Infostart Event 2021 Moscow Premiere рассказал Никита Федькин.

21.06.2022    3005    nixel    24    

Как начать разработку проекта 1С, чтобы легко перейти к DevOps-практикам

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

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

22.06.2021    6771    artbear    2    

Docker для 1Сника

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

На онлайн митапе «DevOps в 1С» Руслан Жданов рассказал, для чего 1С-нику нужен Docker, как его применять, какие сервисы можно вынести в контейнеры и как организовать взаимодействие контейнеров друг с другом.

07.06.2021    8484    ZhdanovR    33    

Осторожный DevOps

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

Начальник отдела разработки в компании «Билайн» Игорь Сухоруков на Meetup Infostart DevOps поделился особенностями работы своего ИТ-подразделения и рассказал о том, как устроено производство и внедрение ПО в режиме нон-стоп в компании, подразделения которой работают по всей России: от Москвы до Владивостока.

24.05.2021    3355    ig1082    3    

Шпаргалка установки сервера взаимодействия без MSI(9.0.33) использованием Postgresql в docker-compose

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

Какой бы не был бизнес - он нуждается в коммуникации. У кого-то Telegram, у других - Whatsapp, у кого то - электронные письма. Возникла задача наладить общение между пользователями базы 1С без мессенджеров. Скачав самую свежую версию на момент написания статьи 9.0.33, обнаружились некоторые подводные камни при установке.

07.04.2021    2277    yaroslavkravets    2    

Управление конфигуратором в режиме агента с помощью python

Инструменты администратора БД Архивирование (backup) DevOps и автоматизация разработки v8 1cv8.cf 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

Управление конфигуратором 1С:Предприятие в режиме агента. Опыт применения с реализацией на языке python. Результат получен с использованием интерактивной сессии оболочки через invoke_shell().

06.08.2020    2528    Alex10166    2    

Jenkins: конфигурируем сервер и подключаем к нему виртуальные машины. Цикл "Многопоточный CI для 1С c Packer, Vagrant и Jenkins", часть 4

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

Выполним основные настройки Jenkins как CI-сервера. Подключим к нему развёрнутые через Vagrant виртуальные машины в качестве сборочных узлов.

13.03.2020    25296    Vladimir Litvinenko    8    

DevOps. Как это выглядит у нас

DevOps и автоматизация разработки v8 1cv8.cf Россия Бесплатно (free)

DevOps в департаменте разработки 1С в крупной компании.

01.10.2019    12843    Repich    19    

Сказ про то, как я DevOps-ом занимался (OneScript, Deployka, Jenkins)

OneScript DevOps и автоматизация разработки v8 1cv8.cf ИТ-компания Бесплатно (free)

Решаем задачу: автоматизировать обновление тестовых баз 1С из хранилища конфигурации при появлении в нём новых изменений. Данная статья родилась в муках хождения по граблям и поиска безопасного форватора среди подводных камней. Изложение постарался представить в виде инструкции для новичка, в которой собрал всё, с чем пришлось столкнуться. Сам я не DevOps-ер, ни на что не претендую, просто делюсь опытом :)

17.06.2018    26751    stas_ganiev    37    

Автоматизация процесса 1С-разработки

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

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

07.06.2017    28147    ekaruk    9    

Автоматическая интеграция внешних обработок в конфигурацию 1C

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

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

06.11.2014    12854    akomar    2