"Война и мир" или DevOps в большом Enterprise

Публикация № 1233786 08.05.20

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

DevOps – это концепция разработки и поставки программного обеспечения, которая расширяет практики гибкой разработки Agile на весь жизненный цикл продукта. Но как применить эту концепцию в крупной компании, где любое изменение традиционно должно проходить большое количество согласований и проверок? Про свой опыт внедрения DevOps в большом Enterprise на конференции Infostart Event 2019 Inception рассказал руководитель направления DevOps в «Дирекции региональных продаж Газпром нефть» Марат Биккин.

Всем привет! Меня зовут Марат Биккин. В Enterprise я работаю уже около 10 лет. За это время я прошел путь от разработчика 1С, был экспертом по технологическим вопросам, корпоративным архитектором, и вот теперь руковожу командой, которая внедряет DevOps.

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

Поднимите руки - кто из присутствующих в зале работает в Enterprise или на Enterprise? Руки подняли где-то 20-30% – значит, вы точно в правильной аудитории. Всем остальным, я думаю, будет интересно заглянуть за занавес. Поехали!

 

Наше подразделение – дирекция региональных продаж (ДРП) Газпром нефти

 

 

Зададим контекст. Когда я буду говорить «мы», я буду говорить про Дирекцию Региональных Продаж (ДРП) – это бизнес-единица «Газпром нефти», которая непосредственно работает с клиентами (с физическими лицами, с мелкооптовыми клиентами).

  • у нас около 6 миллионов клиентов;
  • из них примерно 2 миллиона пользуются нашими мобильными приложениями;
  • мы управляем примерно 1200 АЗС, правильнее сказать – точками продаж, потому что на них мы продаем не только бензин, но и кофе и сопутствующие товары.

 

 

  • Для того чтобы все это работало, нужно достаточно много Ит-продуктов– их у нас действительно много, больше 70.
  • По каждому продукту мы релизимся 1-2 раза в месяц.
  • Время реализации проекта (Time-to-market) в среднем 130 дней для всех продуктов и примерно 70 дней для продуктов на 1С.

 

 

1С – это не самая большая и, может быть, не самая важная, но довольно значимая часть нашего ландшафта. Большая часть бэкенда ДРП работает на 1С.

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

 

Зачем нужна цифровая трансформация?

 

 

Давайте попробуем ответить на вопрос: «Зачем разрабатывать такое количество продуктов?»

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

  • Во-первых, маржинальность нефтепродуктов падает. Рынок очень конкурентный и сильно зарегулированный поэтому нужны новые источники дохода.
  • Во-вторых, буквально из ниоткуда появляются цифровые платформы. Это ребята, которые построили бизнес там, где, казалось бы, невозможно его сделать – например, «Яндекс.Такси» или «Додо Пицца».
  • В-третьих, появились новые технологии, которые радикально поменяли клиентский опыт – опыт того, как клиент взаимодействует с нашим товаром или с нашей услугой. Самый простой пример – это, конечно, мобильный телефон. Я прихожу со своим телефоном на заправку – я могу выпустить из него карту лояльности, могу оплатить товары, могу заправиться с помощью приложения, не выходя из машины, могу изменить рецепт своего кофе, который будет приготовлен на АЗС. Если мы не будем этим заниматься, значит, этим будет заниматься кто-то другой, и мы рискуем остаться – если не без всех клиентов, то без большой их части.

 

Как масштабировать Agile-подходы к разработке в Enterprise?

 

 

Чтобы все это работало, большие компании внедряют гибкие практики разработки - все знают про Agile. Но вот беда – эти практики очень тяжело масштабируются на уровень большой компании. Это действительно трудно.

 

 

Существует множество фреймворков масштабирования. Один из них показан на слайде, называется SAFe. Глядя на него лично мне хочется сказать: «Это слишком сложно, пожалуйста, верните мне мой Waterfall».

 

 

Есть менее сложные, менее объемные фреймворки, например LESS HUGE. Но даже здесь появляется множество новых менеджерских ролей, таких как Scrum-мастер сегмента, многочисленные координаторы, множество каких-то совещаний. И роль инженерных практик, значимость того, как разработчики взаимодействуют с эксплуатацией и другими функциями Enterprise, отходит на второй план. Это не очень здорово.

 

 

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

 

 

Что с этим делать?

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

Однако это практически не оказало влияние на Time to Market, потому что разработка – это еще не все процессы.

 

 

Тут на сцене появляется DevOps, который обещает Enterprise масштабировать практики Agile с разработки на эксплуатацию и инфраструктуру – обещает вовлечь в этот процесс контролирующие функции, такие, как информационная безопасность и  корпоративные архитектура. Вообщем, много чего обещает. В  ходе моего доклада попробуем ответить на вопрос: «А все ли эти обещания  реализуются?».

 

Особенности DevOps в Enterprise

 

 

Когда вы приходите в команду и говорите: «Давайте внедрим DevOps», команда говорит: «Да сейчас, за день сделаем – возьмем BitBucket, Bamboo, Jira, Kubernates, соединим все это одной линией и все заработает».

Да, заработает, если у вас одна команда, одно окружение, одна среда развертывания…. Но в Enterprise обычно много команд и все они совершенно разные..

 

 

Вот это – наши основные языки программирования и фреймворки. На самом деле, их гораздо больше, порядка 20 – все на слайд я собирать не стал.

 

 

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

А если у вас 100 команд, получится спутанный клубок…

Я не стану показывать эту картинку, чтобы вас не травмировать.

 

 

Кроме того, есть и другие Enterprise-особенности, о которых я уже говорил. Это:

  1.  требования аудиторов / регуляторов;
  2.  ограничения информационной безопасности и корпоративной архитектуры;
  3.  какие-то сложные сложившиеся процессы согласования.

Со всем этим в DevOps нужно как-то выживать.

 

Зачем тогда нужен DevOps в Enterprise?

 

 

Возникает очень простой вопрос: «Если так сложно, может не стоит и начинать?». Действительно, некоторые консалтинговые агентства говорят, что примерно 50% внедрений DevOps в Enterprise неуспешны. Я не могу прийти к своему финансовому директору и сказать – мне нужно X миллионов рублей, чтобы внедрить DevOps. DevOps – это такая крутая штука, современный способ разработки. Но с вероятностью 50% у нас ничего не получится.

 

 

Что с этим делать? Можно пойти за знаниями к тем, кто уже однажды прошел этот путь, кто уже достиг каких-то успехов и уже набил шишек. Я обращаю внимание на отчет DORA State of Devops (http://amp.gs/SHxu). Здесь и дальше в моей презентации на сером фоне будут приведены ссылки. Их можно скачать и использовать.

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

 

 

Я не буду говорить обо всех интересных выводах из отчета DORA State of Devops, вы можете почитать его сами. Обращу внимание на эту таблицу – по сути, это разница между тем, как разрабатывают те, кто только начинают использовать DevOps, и тем, как разрабатывает “элита” .

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

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

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

 

 

Другими словами, цифровая трансформация – это такой большой авиалайнер:

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

 

Пять условий для старта внедрения DevOps

 

 

Подведем итоги – что нужно, чтобы вы могли стартовать проект по DevOps в вашей компании?

  • Во-первых, вашей компании нужны цифровые продукты. Если у вас их нет, если у вас нет необходимости разрабатывать быстрее, тогда вам не нужен DevOps.
  • Вы должны получить поддержку руководства – о том, как это сделать, мы немного поговорили.
  • Важный пункт, который все недооценивают, который я недооценивал – это то, что у вас должна быть поддержка разработчиков. Мне всегда казалось, что стоит прийти к ним и сказать: «Ребята, тут есть классная штука, DevOps, внедрите его, и все будет быстрее» и все пойдут за тобой. На самом деле, нет. Очень много команд, и хорошо, если они тебе сразу скажут: «Нет, нам это неинтересно, у нас нет времени», еще хуже, если начнется режим итальянской забастовки. Они скажут: «Да, это крутая штука», а потом ничего не будут делать. Другими словами, это очень важно, нужно получить поддержку, а это достаточно сложно сделать, особенно если вы работаете с подрядчиками, а не с собственной командой.
  • Вы должны понимать, как повлиять на метрики разработки в лучшую сторону
  • И еще для старта проекта нужно, чтобы у вас был план.

 

Дорожная карта

 

 

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

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

Вроде все достаточно просто.

 

 

Нам казалось, что нас ждет ровная дорога и где-то вдалеке светит солнце – символ того, что DevOps внедрен.

 

 

На самом деле, будет вот так – пороховой дым, локальные стычки, смешались в кучу кони, люди, и не все доживают до конца проекта.

 

Выбор инструментов для DevOps

 

 

Давайте пойдем по шагам

Я, наверное, не открою секрет, как в Enterprise обычно выбирают инструменты. Берут отчет Gartner, смотрят на лидеров в каждом классе и выбирают из этих лидеров.

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

Худшее, что вы можете сделать – это поверить какому-то вендору, поверить в то, что у него есть суперприложение, которое объединяет несколько классов и внедрить его. Вы попадете в ловушку вендорского lock-in, из которой будете потом долго выбираться. Но по счастью, у нас получилось не попасть, мы выбрали, по факту, лучший инструмент в каждом классе, и пошли дальше.

 

Процесс внедрения новых инструментов в большой компании

 

 

А что дальше? Те, кто работают в большой компании, наверное, знают, что дальше. Дальше – архитектурный комитет, который должен утвердить ваш выбор.

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

Предположим, вы все это сделали. Что дальше?

 

Пилотирование и создание прототипов

 

 

Дальше вы должны пилотировать.

И тут очень важно выбрать правильные пилоты:

  • Я уже говорил про «итальянскую забастовку» и про то, что очень нужно, чтобы команда хотела внедрить DevOps, и у нее должны быть на это ресурсы.
  • Нужно чтобы владелец продукта вас полностью поддерживал.
  • Важно выбрать такую команду, которую можно было потом масштабировать:
  • Если вы возьмете слишком технологически сложную команду, вы, скорее всего, споткнетесь.
  • Если слишком простую, то скорее всего, ее решения невозможно будет масштабировать.
  • Если вы возьмете какой-нибудь фреймворк, который использует только эта команда, скорее всего, это будет бессмысленно.

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

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

 

Платформа DevOps ДРП

 

 

То, что у нас в итоге получилось, мы назвали это «Платформа DevOps ДРП» – это инструменты и сервисы, которые крутятся внутри корпоративной сети и предоставляют возможность использовать командам разработки инженерные практики.

 

 

Если погружаться глубже в детали, то получилось что-то наподобие вот этого. Хочу сразу сказать, что тут нет никакого rocket science, этот стек очень типовой для России в целом. Это практически повторение того, о чем рассказывал Валерий Максимов в своем докладе за исключением каких-то дополнительных инструментов.

  • вы собираете требования, трекаете их в Jira, Confluence;
  • вы разрабатываете в своей любимой IDE, где угодно – это может корпоративная сеть или вне нее, в каком-то облаке, это может быть какая-то среда разработки;
  • дальше все это попадает в единую точку входа – GitLab;
  • после этого проходит всевозможные проверки качества кода с помощью SonarQube, проверки информационной безопасности с помощью X-Ray, статических и динамических анализаторов;
  • дальше все это тем или иным способом собирается Jenkins;
  • развертывается на виртуалке или в контейнере;
  • тестируется;
  • и устанавливается на прод.

 

 

Важно сказать, что для 1С никаких отличий нет, все то же самое.

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

 

Основная проблема внедрения DevOps

 

 

Слайд, который мне дался с трудом.

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

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

 

 

Поэтому важно понимать, что DevOps – это не квантовый скачок. Это не переход из состояния 0 в состояние 1. Это больше похоже на лестницу, по которой вы будете долго подниматься наверх. И да, это – выход из зоны комфорта.

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

 

Взаимодействие команды DevOps с продуктовыми командами

 

 

Мы, команда «Платформы DevOps ДРП», взаимодействуем с продуктовыми командами примерно так. По сути, это три направления взаимодействия.

  • Первое – это «DevOps как сервис». К нам приходит команда, говорит: «Ребята, помогите». И мы делаем pipeline «от и до».
  • Второй вариант – это совместная работа. К нам приходит команда, мы не знаем, как это делать, они не знают, как это делать. Мы вместе садимся и начинаем изобретать. Это может в итоге стать сервисом. А может навсегда остаться какой-то уникальной фичей для команды.
  • И третья история – это фасилитация. Мы садимся вместе с Product Owner и пытаемся понять, отчего же в платформе кардинально не хватает, чтобы мне было удобно работать.

 

 

Надо сказать, что не мы это изобрели. Буквально на этой неделе вышла книжка Team Topologies. Это те ребята, которые делали сайт https://teamtopologies.com/ где были такие кругляши OPS\DEV, которые как-то пересекались между собой.

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

 

Поменяйте подход к согласованию изменений

 

 

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

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

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

 

Привлекайте союзников

 

 

Чтобы изменить процессы в компании, нужно искать союзников, потому что любую битву невозможно выиграть без союзников.

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

Дальше на примере информационной безопасности я попробую рассказать, как это можно сделать.

 

Побочный эффект от использования чужого кода

 

 

Картинка, которая, надеюсь, всем понятна – все сообщество Инфостарт возникло потому, что кто-то писал код и выкладывал его на сайт, а другие это использовали в своих проектах. Общемировая практики, все так делают (все видели мемы про stackoverflow ?). Когда я хочу что-то разработать, я первым делом поищу, не разработал ли это кто-нибудь другой.

 

 

Но когда мы берем такой код, мы, возможно, заносим с ним уязвимости. Или уязвимости, которая есть у существующей в коде библиотеки.

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

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

 

 

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

 

Причины появления DevSecOps

 

 

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

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

Поэтому возник акроним DevSecOps, который рассказывает о том, как инструмент информационной безопасности встроить в pipeline, как сделать эти проверки автоматизированными.

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

 

 

Важно понимать, что для 1С все работает абсолютно точно так же. Есть разработка в EDT, в конфигураторе, где-то в облаках, по GitFlow или не по GitFlow – неважно. Все это попадает в GitLab. А на GitLab натравливается статический анализатор или динамический. Здесь для меня это просто черный ящик. Важно понимать, что мы не нашли такого анализатора для 1С на рынке и наша служба безопасности написала его сама для себя на 1С для 1С. Этот анализатор, по сути, зажигает красную или зеленую лампочку.

  • Красную – если есть какие-то уязвимости в коде.
  • Зеленую – если все ОК, можно выкатывать ваш pipeline дальше.

 

Стратегия масштабирования

 

 

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

Вы можете начинать масштабироваться, когда:

  • у вас уже есть успешные пилоты;
  • есть ресурсы в команде, чтобы делать это масштабирование;

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

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

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

 

Кривая успеха или «кривой успех»

 

 

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

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

 

DevOps в большой компании

 

 

Давайте финализировать – что такое DevOps в большой компании.

  • Убедиться, что вы, ваша компания, готовы к этому. Это – пять условий, про которые я говорил выше
  • Реализовать успешный Proof-of-concept,
  • Правильно выбирать и утвердить инструменты - та самая картинка про “архитектурного мамонта”
  • Развернуть платформу внутри или использовать готовую платформу в облаках ( если, конечно, вы имеете возможность использовать облака)
  • Собрать правильную команду – без правильной команды, к сожалению, ничего не получится. Скорее всего, с помощью сторонних подрядчиков и консультантов вы этого не сделаете никогда, нужна именно сильная внутренняя команда
  • Привлечь союзников которые участвуют в процессе разработки
  • Тиражировать успех

Думаю, что с этим гайдлайном и с теми граблями, про которые я рассказал, вам будет проще и дорога к DevOps у вас будет более ровная.

Удачи!

 

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

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Выбрать мероприятие

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Sergant 51 10.05.20 12:12 Сейчас в теме
... без технических деталей и конкретных примеров эта статья кажется бесполезной
BomjBandit; kuzyara; +2 Ответить
Оставьте свое сообщение

См. также

Получаем статистику по git-репозиторию в разрезе разработчиков

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) OneScript Бесплатно (free)

Итак! Представим, что наступил момент, когда разработка через исходный код реализована на предприятии в полном объеме. Мы разрабатываем в EDT или конфигураторе (но выгружаем конфигурацию в исходный код), версионируем внешние отчеты и обработки и расширения, собираем релизы, проверяем код статическим анализом, в разработке царит гармония и мир. Красота! Но менеджерам этого мало, всегда хочется чего-то еще, и вот мне прилетает задача - дай статистику по вкладу в код каждого разработчика.

13.03.2023    778    ardn    3    

23

SonarQube: про объемы, ветки, покрытие кода и интеграцию с Gitlab

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

Опыт применения SonarQube в нескольких командах. Плюс некоторые тонкости: уменьшение объемов базы SQ, интеграция, покрытие кода.

26.02.2023    1904    kraynev-navi    10    

42

DevOps для Плейстоцена. Скрещивание обычных форм толстого клиента с практиками CI/CD

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

Плейстоцен — эпоха четвертичного периода, начавшаяся 2.588 миллионов лет назад и закончившаяся 11,7 тысяч лет назад. В 1С этот период характеризуется обычными формами, использованием толстого клиента и вызовом «Предупреждение» без таймаутов прямо из модулей проведения документов. О том, как внедрять инженерные практики для огромного монолита легаси и тестировать функциональность без менеджера и клиента тестирования под разными пользователями, на конференции Infostart Event 2021 Moscow Premiere рассказал ведущий программист компании BCS FinTech Сергей Голованов.

20.02.2023    1240    Golovanoff    17    

14

Жизнь платформы 1C:Предприятие в кластере Kubernetes

Сервера DevOps и автоматизация разработки Облачные сервисы, хостинг Бесплатно (free)

Во многих сферах запуск приложений в Kubernetes является де-факто стандартом архитектуры, так как это позволяет быстро и эффективно задействовать ресурсы, не затрачивая на это большие деньги. Но с платформой 1С:Предприятие не все так просто, но потенциально возможно. Руслан Жданов на митапе «DevOps в 1С: CI/CD. Непрерывная интеграция и поставка решений на 1С» рассказал про то, как с помощью Kubernetes организовать в облаке управление кластером из серверов 1С и реализовать там тестирование приложений на 1С или запуск скриптов на OneScript.

24.01.2023    5236    ZhdanovR    3    

22

Концепция ландшафта 1С-систем на предприятии

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

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

09.12.2022    1170    roman72    13    

7

Работа с 1С:Аналитика Промо

Онлайн-курс предусматривает изучение возможностей системы “1С:Аналитика”, которая работает как составная часть платформы “1С:Предприятие” и обеспечивает оперативный просмотр и анализ необходимых данных.

4500 рублей

Прокси хранилища 1С (IIS, OneScript)

Групповая разработка (Git, хранилище) OneScript DevOps и автоматизация разработки Платформа 1С v8.3 Россия Бесплатно (free)

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

08.12.2022    4825    kamisov    24    

81

Что, если Continuous Integration – это прежде всего практика, а не набор инструментов?

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) Бесплатно (free)

Рано или поздно многие компании приходят к практикам DevOps. И начало этому – Continuous Integration. О том, что происходит в команде специалистов 1С, когда они переходят на Git, и почему простое внедрение CI-инструментов не решает проблему подходов к разработке, в докладе на Infostart Event 2021 Post-Apocalypse рассказал руководитель компании ПрогТехБизнес Александр Анисков.

07.12.2022    1387    vandalsvq    0    

23

Управление хранилищами без боли

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) Бесплатно (free)

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

28.11.2022    6336    Evil Beaver    11    

86

Как избавиться от большого количества комментариев в коде с использованием EDT + Git

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

Публикация освещает вопрос улучшения качества и читабельности кода путем отказа от излишних комментариев. Рассматривается пример из опыта работы команды разработки на EDT + Git. Команда работает в EDT меньше года. Конфигурация сильно доработана и не обновляется типовыми релизами.

15.11.2022    981    shastin87    5    

9

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

Быстро в Jenkins

DevOps и автоматизация разработки Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

21.06.2022    6085    nixel    49    

81

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

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

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

16.02.2022    7341    digital-samolet    42    

95

Как Gitlab-CI и OneScript могут отсортировать массив (Часть 2)

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

Продолжение сквозного примера настройки Gitlab-CI - вывод результатов теста, условия запуска и таймауты.

12.12.2021    2330    SaschaG    4    

16

Как Gitlab-CI и OneScript могут отсортировать массив (Часть 1)

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

С приходом в 1С EDT мы получили git. С git-ом пришел и gitlab, а он уже дает инструменты по CI. Что такое CI? Ну все же знают, как обычно просят обновить прод? Желательно ночью? Желательно проверив на копии, что ничего не сломаем? Ну так вот: CI – это личный помощник, который все сделает сам. Надо только правильно его попросить...

18.11.2021    3880    SaschaG    9    

73

Распознавание и загрузка документов в 1С Промо

Универсальная программа-обработка для распознавания любых сканов или фото первичных документов в 1С (счета-фактуры, УПД, ТТН, акты и тд). Точность распознания до 98%.

от 11 рублей

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

DevOps и автоматизация разработки Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

22.06.2021    8500    artbear    2    

72

Микросервисы на Golang. Часть 6. Докеризация, Начальная оркестрация, CD\CI

DevOps и автоматизация разработки Конфигурации 1cv8 Бесплатно (free)

Создадим микросервис, поместим его в докер, проведем его масштабирование на нескольких виртуальных машинах с помощью оркестрации Docker Swarm, выполним также CD\CD микросервиса с помощью GitHub Action (Микросервис взят с прода, обрезан лишний функционал) будет показан пример его взаимодействия с 1С клиентом.

21.06.2021    2883    dmitry-irk38    3    

6

Docker для 1Сника

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

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

07.06.2021    12543    ZhdanovR    34    

41

Осторожный DevOps

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

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

24.05.2021    4036    ig1082    4    

32

Видеокурс-практикум: как подготовить и написать ТЗ, ЗНР, ЧТЗ. Промо

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

3 500 рублей

Ненавязчивая локальная разработка с traefik2, docker и letsencrypt

Групповая разработка (Git, хранилище) DevOps и автоматизация разработки Бесплатно (free)

Перевод статьи по проксированию HTTP траффика до сервисов развернутых в docker контейнерах. Оригинал от 24.09.2020.

16.05.2021    5031    malikov_pro    0    

8

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

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

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

07.04.2021    2910    yaroslavkravets    2    

24

Тестируем в Docker

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

Чтобы продукт гарантированно отвечал функциональным требованиям, нужно писать для него тесты и часто их запускать. О том, через какие этапы проходит компания, которая хочет автоматизировать тестирование – от одного клиента на локальной машине до запуска тестов по запросу в Kubernetes, на INFOSTART MEETUP Ekaterinburg.Online рассказал Андрей Крапивин.

29.03.2021    7611    Scorpion4eg    8    

52

1С on demand – скажи "нет" постоянным билд-агентам

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

Каждый, кто пытался запускать на своем компьютере тесты для 1С, сталкивался с тем, что процесс тестирования не позволяет что-то делать параллельно. О том, как изолировать тестовые окружения и организовать «Агент по запросу» с помощью Docker на примере Jenkins CI, рассказал ведущий разработчик компании «Первый БИТ» Никита Грызлов.

25.01.2021    5488    nixel    12    

68

DevOps: бери и делай!

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

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

15.01.2021    5711    OPM    2    

38

1СПАРК РИСКИ. Сервис оценки благонадежности контрагентов. Промо

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

Практика применения DevOps. Автоматизированная сборочная линия

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

В четвертой части мастер-класса «Практика применения DevOps» на конференции Infostart Event 2019 Inception выступил Валерий Пронин. Он рассказал, как развернуть автоматизированную сборочную линию, которая будет контролировать качество кода в проекте и в зависимости от прохождения порога отдавать релиз в виде cf-файла либо отправлять письмо об ошибках.

16.12.2020    7573    proninvvp    5    

65

Практика применения DevOps. Автоматизация процессов разработки, инструментарий и работа с Git

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

Автоматизация процессов разработки с применением DevOps-практик помогает получать более качественный и осмысленный результат. На конференции Infostart Event 2019 Inception в ходе мастер-класса «Практика применения DevOps» команда Инфостарта разложила «по полочкам» инструментарий, который используется для каждого из процессов DevOps, и показала, как работать с ними на практике. В первой части выступил Павел Олейников – он сделал обзор инструментов, которые можно использовать при автоматизации процессов разработки, и рассказал про работу с Git (в том числе в EDT).

03.12.2020    6404    OPM    3    

44

Взаимодействие 1С со сторонними продуктами посредством REST и Golang (middleware). Часть 4 - NoSQL (MongoDB, Redis)

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

Если в ИТ-инфраструктуре есть NoSQL решения, с которыми требуется взаимодействовать из 1С, можем использовать прослойку на Golang в стиле RESTful

21.09.2020    7070    dmitry-irk38    12    

35

Взаимодействие 1С со сторонними продуктами посредством REST и Golang (middleware). Часть 2 - Docker

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

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

07.09.2020    4893    dmitry-irk38    0    

18

DevOps в команде специалистов 1С или сказ о том, как желтые котики хотели лучше работать…

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

Основные компоненты, на которых строится идея DevOps – это сотрудничество, доверие, инструменты и масштабируемость. И команда специалистов 1С, не подготовленная к соблюдению этих принципов, может столкнуться с проблемами при внедрении DevOps-практик. Как преодолеть эти сложности, и какие выгоды в результате применения DevOps-инструментов может получить компания, на конференции Infostart Event 2019 Inception рассказал руководитель отдела автоматизации предприятий ОП «Синимекс-Воронеж», Эмиль Карапетян.

04.09.2020    10373    amon_ra    2    

25

Готовые переносы данных из различных конфигураций 1C Промо

Рекомендуем готовые решения для переноса данных из различных конфигураций 1C. C техподдержкой от разработчиков и гарантией от Инфостарт.

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

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

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

06.08.2020    2987    Alex10166    2    

20

Использование vanessa-runner/deployka в сборочных линиях Jenkins

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

Библиотеки (shared-libraries) для Jenkins, пример сборочной линии.

26.03.2020    5547    ImHunter    3    

25

Пайплайны Jenkins - программирование и настройка. Загружаемые модули. Цикл "Многопоточный CI для 1С", часть 5

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

Рассмотрим создание пайплайнов Jenkins и библиотек собственных методов, язык Groovy, подходы к хранению настроек и обработке ошибок.

17.03.2020    35583    Vladimir Litvinenko    18    

68

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

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

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

Автоматизируем установку и конфигурирование Linux, PostgreSQL, 1C, Apache, Java с возможностью выбора версий дистрибутивов. Упаковываем результат в образ виртуальной машины.

28.02.2020    13832    Vladimir Litvinenko    11    

89

CI/CD для 1С проектов, унифицировано, с кастомизацией

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

Тема CI/CD в связке с 1С не нова, но многих пугает сложность использования и поддержки, необходимость обучения команды. Про то, как унифицировать и упростить поддержку сборочных конвейеров для большого количества решений, в своем докладе на конференции Infostart Event 2019 Inception рассказал начальник отдела компании BIA-Technologies Валерий Максимов.

20.02.2020    10977    theshadowco    13    

76

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

DevOps и автоматизация разработки Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

01.10.2019    13164    Repich    19    

57

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

OneScript DevOps и автоматизация разработки Платформа 1С v8.3 Конфигурации 1cv8 ИТ-компания Бесплатно (free)

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

17.06.2018    27818    stas_ganiev    37    

137