Меня зовут Эмиль Карапетян, я являюсь руководителем группы автоматизации предприятий в компании Синимекс. У меня будет теоретический доклад, в нем не будет ничего особо практического. Я расскажу о том, что такое DevOps в команде специалистов 1С, и о том, как мы, 1С-ники, желтые котики, хотели лучше работ Инфостарт ать.

 

Немного о себе и компании Cinimex

 

 

Познакомился я с 1С в 2006-2007 году, начинал карьеру системным администратором, работ Инфостарт ал в HelpDesk, в розничной сети МТС. И на текущий момент с 2017 года я работ Инфостарт аю в компании Cinimex.

Компания Cinimex на рынке уже достаточно давно – основана в 1997 году, сертифицирована по ISO 20022.

 

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

 

О чем поговорим

 

 

В своем докладе я расскажу о том:

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

 

Что такое DevOps

 

 

На текущий момент на российском сегменте ИТ DevOps – это достаточно новая тема, она хайповая. Это стильно, модно, молодежно.

 

 

Если загуглить DevOps в гугл-картинках, то мы увидим вот такие картинки:

 

 

Все картинки разные, но у всех у них есть нечто общее – это наличие Dev и Ops.

 

 

Dev и Ops – это сокращение от слов Development и Operations.

Это не название профессии, это нечто большее, чем профессия, и нечто большее, чем инструменты.

 

 

DevOps – это культура, идея и философия.

Чтобы понять, почему это именно культура, идея и философия, нужно немного окунуться в историю появления DevOps.

 

 

Движение DevOps появилось в 2007-2009 годах. Оно берет свое начало из Бельгии, и считается, что его основоположник – это Патрик Дебуа, ИТ-консультант в одной ИТ-компании Бельгии. Он занимался госпроектом, в котором были задействованы две команды – команда разработ Инфостарт чиков и команда эксплуатации/сопровождения. И каждый раз, когда команда разработ Инфостарт чиков выпускала релиз с ошибкой, команда эксплуатации говорила, что это разработ Инфостарт чики написали неправильный код, потому что он не запускается на каких-то машинах, а разработ Инфостарт чики говорили, что у них все работ Инфостарт ает – это админы все виноваты.

Наверное, у всех была ситуация, когда мы выпускаем какую-то обраб Тарифы на абонементотку/конфигурацию, заливаем ее на продакшен или на тестовый сервер, и когда у пользователя что-то внезапно падает (где-то какой-то ресурс недоступен), тут возникает вопрос – кто виноват? Все обращаются к программистам, а они отвечают: «Ничего не знаем. У нас все работ Инфостарт ает. Все вопросы к сисадминам – они вам порты какие-то залочили».

И тогда Патрик Дебуа задался вопросом – почему между ИТ-сотрудниками такая преграда?

И в 2009 году он провел первую конференцию DevOps Days, в которой собрал в одном месте сисадминов и разработ Инфостарт чиков, и сказал: «Ребята, вы все ИТ-шники, и у вас достаточно много общего. Разработ Инфостарт чики пишут код в какой-то IDE, сисадмины пишут какие-то скрипты на bat и Powershell. Но и у тех, и у других – приемы и алгоритмы одинаковые. Почему между вами такая стена?»

 

 

 

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

 

Компоненты DevOps

 

 

Были выделены определенные компоненты DevOps:

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

 

 

Также, DevOps – это:

• Работа с техническими метриками и мониторингом. Все системы должны всегда мониториться, вам должны приходить какие-то сообщения о том, что у вас rphost доходит до какой-то пиковой ситуации. Не надо ждать, когда rphost поднимется до 100%. Надо уже на 70% понимать, что у вас что-то не так.
• Непрерывный обмен знаниями между разными командами:
  • разработ Инфостарт чики всегда должны знать, что делают консультанты;
  • консультанты должны понимать, как проходит процесс работ Инфостарт ы у разработ Инфостарт чиков.
  • разработ Инфостарт чики должны понимать, как устроена их инфраструктура, для которой они разрабатывают программный продукт. Это, априори, просто должно быть. Если кто-то не понимает, как работ Инфостарт ают другие члены команды – это печально.

 

 

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

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

 

Практики DevOps

 

 

Мы сейчас поговорили о компонентах DevOps. Также в DevOps есть практики, которые направлены на создание благоприятной атмосферы для работ Инфостарт ы.

Одна из основных первоначальных практик – это непрерывная интеграция (Continuous Integration). Эта практика нацелена на облегчение работ Инфостарт ы разработ Инфостарт чиков.

• Каждое изменение кода должно отслеживаться.
• Код всегда должен версионироваться. 
• И должна быть проверка сборки конфигурации (выпуска релиза).

 

 

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

 

 

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

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

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

 

 

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

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

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

 

 

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

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

 

 

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

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

 

 

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

 

Можно ли примен стилиять DevOps в 1С

 

 

Мы подошли к вопросу о том, есть ли DevOps в 1С.

Чтобы ответить на этот вопрос, нужно понять, что мы можем использовать – какие практики, идеи, компоненты и инструменты DevOps примен стилиимы в 1С.

 

 

Давайте вспомним, какие люди могут быть в 1С?

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

 

 

Какие есть люди вне мира 1С? Те же самые. Никакой разницы нет.

 

 

Собственно, DevOps в 1С есть. Есть те же люди и те же проблемы. И практики мы используем те же самые. И то, что мы все сейчас собрались на Инфостарте, как раз подтверждает то, что DevOps в 1С есть.

Внедрение практик DevOps необходимо для того, чтобы все получали от работ Инфостарт ы удовольствие, а не думали все выходные с грустными лицами о том, что в понедельник опять на работ Инфостарт у.

 

 

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

 

 

Внезапно – таких правил нет.

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

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

 

Практики DevOps в 1С

 

 

На предыдущих слайдах я рассказал о том, какие бывают DevOps-практики. Давайте сейчас подумаем – какие могут быть DevOps практики в 1С?

 

 

Чтобы понять, какие могут быть DevOps-практики в 1С, нужно немного узнать, как это все было и есть в другом мире, не в мире желтых котиков. Как это происходит у Java и C#-разработ Инфостарт чиков.

 

 

Если мы говорим о практике непрерывной интеграции Continuous Integration, то помним, что код всегда должен версионироваться и все изменения кода должны отслеживаться. За это должна отвечать некая система версионирования.

Сейчас все разработ Инфостарт чики не мира 1С – практически поголовно в качестве системы версионирования используют Git. А что было до Git’а?

• CVS – централизованная система управления версиями. Первое ее упоминание в 1986 году. Если мы посмотрим, что это за система контроля версий, то увидим, что на эту систему контроля версий очень сильно похоже наше хранпотому илище 1С – так же все централизовано. Есть одно отличие – в хранпотому илище 1С можно захватывать объект. И этот момент захвата объектов исключает несколько багов, которые были в CVS, когда патчи могли уйти без проверки изменений. Первоначально CVS использовалась Линусом Торвальдсом, когда он разрабатывал ядро Linux. И именно недовольство системой CVS и спровоцировало то, что появился Git (мерзавец).
• Линус очень долго искал, что же все-таки может ему помочь в его разработ Инфостарт ке ядра. После CVS он попробовал использовать Darcs. Это тоже система контроля версий, в ней был очень серьезный баг с производительностью, когда какие-то рекурсивные методы могли сервер просто положить.

 

 

• Позже Линус Торвальдс использовал BitKeeper. Эта система очень похожа на Git за единственным минусом – до 2016 года это был проприоритарный проект, на него распространялась коммерческая лицензия – его было необходимо приобрести. Более того, разработ Инфостарт чики BitKeeper заключили с сообществом разработ Инфостарт чиков Линукс определенный договор, условием которого был запрет на использование любой другой системы контроля версий, которая отличается от BitKeeper.

Если вы заметите, Git появился в 2005 году. А 1С версии 8.0 появилась в 2002 году. Между ними был разрыв три года. И как раз хранпотому илище, которое появилось в версии 8.0 – вполне соответствовало ведущим разработ Инфостарт кам того времени (было очень похоже на CVS). Мы помещаем изменения в хранпотому илище постоянно, каждое изменение версионируется, да структура хранпотому илища непростая, НО код версионируется.

 

 

Сейчас разработ Инфостарт чики из не-1С-мира используют разного рода системы для сборки и выпуска релизов на продакшен – это Jenkins и Teamcity. А до этого были Cron, Scheduler и скрипты – практически то же самое, что сейчас в 1С.

Так что же получается?

 

 

А получается то, что DevOps-практики в 1С есть. Если мы вникнем в эти инструменты, все то, что было когда-то у других разработ Инфостарт чиков, потихоньку перейдет к нам в 1С:

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

 

 

Но – да, нужно только напильником немного поработ Инфостарт ать.

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

 

 

Собственно, магии нет. Чтобы переложить практики DevOps в 1С нужно просто изучить эти инструменты и решить, что вашей команде подойдет на этом конкретном проекте – что мы можем сделать в 1С.

Чтобы мы могли переложить DevOps в 1С, нужно просто понять, что у нас все то же самое, что и в другом мире – у нас тоже есть build, тоже есть deploy, тоже есть delivery и есть автотесты.

• Что такое build? Это просто сборка. Что такое сборка в 1С? Если мы откидываем Git и остаемся в хранпотому илище, то build – это просто выгрузка cf-ника из хранпотому илища. У нас есть репозиторий (хранпотому илище 1С), соответственно, мы выгрузили cf-ник, мы сделали build на основе тех исходных кодов, которые лежат у нас в хранпотому илище 1С.
• Deploy – это установка конфигурации в базу данных.
• Delivery – это доставка нашей конфигурации конечному пользователю.
• И автотесты – Vanessa Automation, Vanessa ADD – про них все уже знают.

 

С чего начать внедрение DevOps

 

 

С чего стоит начать?

 

 

Чтобы реализовать культуру DevOps в команде, нужно начать с себя. Все просто! Начните с себя.

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

Как вы видели, Cinimex – это ИТ-компания, которая занимается разработ Инфостарт кой софта для банковского финансового сектора, но при всем при этом вся наша инфраструктура полностью построена на 1С. Поэтому у нас есть внутренняя команда разработ Инфостарт чиков, которая разрабатывает наши конфигурации для себя. И когда я пришел, про тесты все слышали только отдаленно. Про Git вообще мало кто слышал. И сейчас мы практически ледоколом врезаемся в нашу инфраструктуру и начинаем примен стилиять все эти инструменты, практики, создаем1С DevOps-культуру у себя в отделе.

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

Раньше к нам ко всем 1сникам было примен стилиимо понятие «1С головного мозга», поскольку мы кодим на русском, у нас нет никаких других инструментов – возникало ощущение какой-то ущербности. А сейчас инструментов у нас больше. Я уже не просто 1С-ник, я – разработ Инфостарт чик 1С. Я разрабатываю бизнес-приложения. Ну да, на русском языке. Подумаешь!

 

 

Что стоит сделать, чтобы научиться практикам DevOps?

• Начните пробовать Git, начните работ Инфостарт ать с Docker, разверните контур разработ Инфостарт ки для себя. На Инфостарте буквально за последние полгода появилось очень много статей, где рассказывается, как построить правильное Workflow разработ Инфостарт чика – не 1С-ника, а разработ Инфостарт чика.
• И взгляните на ваш программный код, на ваш продукт именно глазами разработ Инфостарт чика, а не глазами просто 1С-ника.

Дам совет от себя – есть две замечательные книги.

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

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

 

Как мы организовываем DevOps у себя

 

 

Немного о том, как мы организовываем DevOps у себя.

• Мы укрепили сотрудничество в команде, укрепили доверие между участниками и членами команды, чтобы они взаимодействовали между собой так, чтобы им было приятно работ Инфостарт ать.
• Мы провели обучение, много обучения. Обучили Git’у, стараемся участвовать во всех мастер-классах. И что самое интересное, каждый участник команды хочет это. Мы его не заставляем, а мы его подталкиваем к этому.

 

 

Вот так у нас сейчас выглядит Confluence, это часть из оглавления.

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

 

 

Также мы сформиров внешние компонентыали матрицу компетенций и начали проводить внутренние семинары.

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

А сейчас мы начали проводить внутренние семинары. Мы начали больше общаться между собой, между аналитиками, между руководителями проектов, между инженерами эксплуатации.

 

 

Вот так выглядит наша матрица компетенций.

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

 

 

Мы составили список всех процессов и текущего состояния инфраструктуры.

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

• Мы составили список всех процессов и немного втянули в это наших инженеров по эксплуатации и по ИТ-сопровождению. Мы их втянули в свою деятельность. Они сначала были немного недовольны и не рады – но потихоньку втягиваются.
• Мы создали карту всех наших процессов для внутренних и внешних проектов. Раньше если у нас были внешние команды, они были отдельно от внутренних команд. И часто можно было увидеть, что мало того, что у 1С-ников и других разработ Инфостарт чиков стена, так и еще и в одном отделе между несколькими командами стена. Потому что одни занимаются одним проектом, другие – другим. И им вообще друг на друга наплевать. А когда мы начали друг с другом общаться, мы начали делиться знаниями и информацией, стало интереснее работ Инфостарт ать.
• И мы выделили некоторые процессы, которые можно было прямо сейчас взять и автоматизировать. Это – разного рода deploy, пуши в хранпотому илище, автотесты, процессы разворачивания тестовых и разработ Инфостарт ческих контуров. То есть раньше нам просто разворачивали виртуальную машину, и мы в ней что-то делали. А сейчас мы это пытаемся делать в Docker. У нас Docker-контейнеры собираются с сервером 1С. С недавних пор они собираются и с PostgreSQL. Есть, правда, одна проблема – мы не можем прокинуть связку, чтобы не добавлять в консоль администрирования базы и сервера, чтобы оно само сразу делалось. Но пока что наши ребята из службы эксплуатации начали этим заниматься и помогать нам в автоматизации нашей работ Инфостарт ы.

 

 

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

 

 

• Выделили отдельные проекты, на которых можно было использовать DevOps инструменты и организовать практики. Один проект (нашу внутреннюю конфигурацию) мы перевели в EDT. Несколько наших сотрудников, которые раньше всего прошли обучение по Git, начали ее разработ Инфостарт ать непосредственно в EDT с Git. Чуть позже расскажу, как мы переводили этот проект на EDT.
• И – то, что я уже говорил, мы разрушаем стену между 1С и остальными разработ Инфостарт чиками. Мы все являемся равноправными сотрудниками ИТ-компании, поэтому нет особой какой-то разницы между 1С и Java.

 

С чем можно столкнуться и как с этим бороться

 

 

С чем мы столкнулись?

• В первую очередь – это отсутствие компетенций. Не все знали про автотесты, не все умели в Git, и не все понимали, зачем нам Jenkins. Мы начали проводить обучение, начали общаться, и компетенция начала расти. Грамотные и компетентные сотрудники – это залог компании и это залог выпуска качественного программного продукта. Поэтому в первую очередь мы начали поднимать компетенции. Была ошибка, когда мы попробовали сразу разработ Инфостарт ку нашей внутренней основной конфигурации полностью автоматизировать, засунуть в Git, прогонять тесты, деплоить – команда не была к этому готова. Не все знали, зачем и как работ Инфостарт ать, и какой можно от этого получить профит.
• Еще один важный момент – непонимание руководства самой компании , зачем нам все это нужно. В Синимексе этой проблемы нет, но на предыдущем месте работ Инфостарт ы такая ситуация была – мы там внедряли автотесты своими силами, но нам на это не выделялось никакого времени. Мы это делали ночами просто потому, что нам было это интересно. Соответственно, не все сразу запускалось, не на все хватало времени, не все готовы были по ночам и в выходные дни работ Инфостарт ать. Не всегда это оплачивалось. И нам стало неинтересно работ Инфостарт ать.
• Нужно понять, зачем и что автоматизировать. Автоматизация, как на предыдущих слайдах говорилось, должна облегчать работ Инфостарт у, а не усложнять. Был момент, когда мы попыткой реализовать отправку конфигурации в репозиторий Git только усложнили разработ Инфостарт ку. Из-за того, что у нас обычное приложение, на одном из первых билдов у нас конфигурация неправильно собралась, и мы на тестовом контуре упали в «Ошибку формата потока».
• Ошибочный подход к автоматизации – не всегда уменьшение кликов мышки может привести к тому, что мы будем лучше работ Инфостарт ать.
• Не нужно хвататься за все сразу. Как я уже говорил, что мы попробовали сразу – составили кучу регламентов, много документации – ничего не пошло. Захотелось «все и сразу», и на все это времени не было –  компетенции не хватало и не получилось. Откинули идею «все и сразу», начали по чуть-чуть, от малого к большому. Ия уверенузнавать программистов мы придем к успеху.
• И неверно подобранные инструменты. Для автоматизации деплоя мы попробовали использовать несколько скриптов на OneScript. Но они не подходили нашей инфраструктуре. Нам наши инфраструктурщики позвонили и сказали: «У нас тут своя инфраструктура, она отлажена, а вы со своими батниками приходите сюда и все нам рушите». У нас все в докер-контейнерах – хотите, давайте тоже в докер-контейнерах. Поэтому нужно обязательно правильно подобрать инструменты. Нужно сначала сделать то, о чем я говорил – мы начали составлять карту процессов для того, чтобы правильно подобрать инструменты, которые в тот или иной момент, в том или ином процессе нам подойдут.

 

 

• Надо быть готовым, что с первого раза ничего не получится. У нас в прошлом году все запустить не получилось. И в марте тоже запустить не получилось. Но в июне начали уже более успешно.
• Страх перед чем-то новым и выход из зоны комфорта – привыкли работ Инфостарт ать в конфигураторе: «Visual Studio Code? Нет. BSL-плагин? Да ну. У меня есть конфигуратор, я к нему привык, о чем вы. EDT? Неее. Он съел мне 15 гигов оперативы. Ни за что!»
• Отсутствие конкретных сроков внедрения – к сожалению, это так. Это тот самый момент, что с первого раза может ничего не получиться. По планам у нас было в мае месяце всю внутреннюю разработ Инфостарт ку перевести на управляемые формы, какие-то проекты – на EDT, реализовать Git, написать кучу автотестов. Мы сорвали сроки. В следующий раз, когда спросили: «Когда внедрите-то?» – «Не знаем». Это такая культура. Мы начали с практик, а они не взлетели, не была команда к ним готова. Мы начали с культуры, с создания сотрудничества, взаимодействия, общения – и что-то пошло.

 

 

Что помогло?

• Как я уже сказал, мы сертифицированы по ISO, и через риски и возможности начало получаться. Мы составили риски, у нас раз в две недели проходят встречи СМК, и на этих встречах нам удалось выделить реальный бюджет на то, чтобы команда не делала это просто по ночам, чтобы они в рабочее время получали от этого удовольствие. И через ISO это получилось. Это классно. И это работ Инфостарт ает.
• ITIL v4 – он вышел в этом году, я лично об этом узнал в мае месяце. Когда мы начали читать ITIL v4 – мы поняли, что это круто, это то, что мы говорим. Это то, что дополняет DevOps и подталкивает для создания качественного программного продукта. Теперь ИТ в ITIL v4 – это не затраты, это помощник бизнесу для получения высокой прибыли и более хорошего дохода.

 

Инструменты DevOps в 1С

 

 

И немного о DevOps-инструментах в 1С. Выписал основные, которые существуют, которые мы используем у себя.

Если кто-то знает, то здесь практически все основные инструменты выписаны.

• Для CI/CD используем Jenkins, EDT, Git, OneScript,
• Для мониторинга сейчас прикручиваем к Zabbix. Реализовываем проект по интеграции со стеком ELK (Elastic Search, Logstash и Kibana).
• Автотестирование – это xUnitFor1C, Vanessa-ADD, Vanessa Automation + СППР (в СППР добавили поддержку сценариев, написанных на Vanessa Automation).
• Для практики «Инфраструктура как код» можно использовать OneScript, python, Powershell, Bash и Docker. Туда же Jenkins. Если вы понимаете, то практика «Инфраструктура как код» помогает создавать практику CI/CD за счет того, что мы можем автоматизировать создание билдов и деплоя.

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

Планируется еще для мониторинга прикрутить Telegram, чтобы мы могли получать в Telegram информацию о том, прошла ли сборка нашей конфигурации, было ли что-либо установлено в продакшен, чтобы разработ Инфостарт чики просто могли знать, что в 22:50 был деплой в продакшен, и он успешный.

 

 

Небольшое отступление. Расскажу – зачем нужен тот или иной инструмент. Все уже примен стилияют Git у себя в работ Инфостарт е? Зачем он нужен, знаете?

 

 

Git нужен, чтобы такого не было.

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

Кроме обраб Тарифы на абонементоток, я подключаю хранпотому илище к gitsync и отправляю конфигурацию на GitHub.

 

 

Про инструменты для работ Инфостарт ы с Git в 1С я уже сказал. GitSync и Precommit – это скрипты, которые написаны на OneScript.

 

 

А всегда ли нужен Git в 1С?

 

 

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

 

Как мотивировать команду

 

 

Как мотивировать команду работ Инфостарт ать с Git?

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

На прошлом месте работ Инфостарт ы моим руководителем был Евгений Павлюк – кто не знает, он один из разработ Инфостарт чиков фреймворка для тестирования xUnitFor1C. Для того, чтобы нас всех посадить в Git, он придумал отличную идею геймификации – раньше во времена dial-up были такие MMO RPG в виде текста, где выводится: «Нажмите 1, если хотите попасть в пещеру, введите 2, чтобы сражаться со скелетами и т.д.» На основе такой идеи был реализован этот подход. Чтобы нас посадить, у каждого из нас был свой перс, которого нужно было прокачать, завоевать какие-то дополнительные скиллы, и за счет выполнения каких-то определенных заданшаблоний мы прокачивали своего персонажа. На Хабре есть статья про геймификацию, как это было реализовано у нас в команде – достаточно интересно, можете почитать.

OpenSource внутри команды – мы у себя попробовали это реализовать. Мы выделили несколько проектов, которые были заморожены. И всем, кому было интересно, кто хотел поработ Инфостарт ать с Git, с EDT, прокачать свои знания, прокачать свои скиллы, мы предоставили такую возможность. Если не было задач у сотрудника, если он справился с задачей раньше срока, чтобы он не простаивал, чтобы ему было интересно работ Инфостарт ать, и если ему надоел текущий проект, чтобы он мог немного переключиться и поработ Инфостарт ать с другим проектом – общим для нашей компании. Чтобы он мог себя в нем как-то показать. Плюс он мог себя показать в другой роли – РП, аналитик.

К сожалению, эта мотивация сразу не взлетела, она до сих пор еще прокачивается. Не у всех было время, не все были готовы работ Инфостарт ать просто так. Когда мы эту идею ребятам презентовали, они сказали: «Зачем мне для компании что-то делать?» Мы думаем над возможностью если этот продукт был достаточно качественный, мы какой-то процент от продажи могли распределить по участникам команды.

И говорить о Git так, будто ты веган. Есть один момент – когда я пришел в Синимекс, у нас мало кто знал, что Git можно прикрутить к 1С. Но когда они видели, что я в своей работ Инфостарт е использую Git, когда они постоянно слушали о том, что вот так это можно было сделать в Git – вот так это прикольно.

В итоге одним прекрасным днем я смотрю, как один из коллег открыл EDT и что-то кодит. Я его спрашиваю: «Зачем тебе EDT?» – «Я посмотрел, что в EDT есть поддержка Git, и перевел свой проект в EDT». Это маленький внутренний проект, над которым работ Инфостарт ает 3 человека, и они полностью перешли на разработ Инфостарт ку в EDT. Около полгода они уже работ Инфостарт ают – есть проблемы, есть свои нюансы, EDT еще глючная и падает, не всегда понятно, что там за ошибки, потому что ошибки Eclipse. Но все равно эта фишка сработ Инфостарт ала.

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

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

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

 

Заключение

 

 

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

• В первую очередь, Инфостарту. Я считаю, что эта конференция, подобного рода встречи, они как раз являются чем-то DevOps-оподобным в 1С.
• Хотел бы сказать благодарность команде «Серебряной пули» за их идеи и инструменты, выложенные как OpenSource-проекты.
• Хочу сказать спасибо Андрею Овсянкину за OneScript.
• Рад, что у нас в Воронеже существует сообщество разработ Инфостарт чиков “Желтый Клуб”
• И всем тем, кто помогает развивать DevOps в 1С, всем участникам сообщества 1С.

Всем спасибо.

 

Вопросы

 

• У вас Docker-хаб на чем реализован?
• У нас свой ресурс, он называется Artifactory.
• А Kubernetes используете у себя?
• На других проектах Kubernetes используем, но на проекте с 1С хотим прикрутить Swarm, потому что 1С до определенной версии платфорплатформамы некорректно работ Инфостарт ает в докере, оркестрируемом Kubernetes – там есть разрывы. Про момент с Kubernetes нам «Серебряная пуля» рассказала – мы сами у себя пока не пробовали.
• Вы сказали, что работ Инфостарт аете с EDT – а как у вас поставлена работ Инфостарт а с ветками и автоматизацией их слияния? Как реализован CI, если каждый делает свой тикет в отдельной ветке?
• CI с EDT на текущий момент делать печально. Только с костылями. Но нас эти костыли не устраивают, потому что нужно использовать Windows, а у нас Docker-контейнеры и все сборки Docker-images на Linux. Мы сейчас придумываем свой инструмент, который будет нам обеспечивать CI. На текущий момент – это работ Инфостарт ает пока что очень криво. По поводу веток – подходов несколько. Попробовали обычный GitFlow – не взлетел. Насколько мне известно, сейчас на этом проекте есть GitHub-flow, есть GitLab-flow. По-моему, GitLab-flow использует одну ветку master и там сам делает ответвление на каждого разработ Инфостарт чика. И сейчас, по-моему, используется такой метод. То есть у нас есть master-ветка, куда все разработ Инфостарт чики сливают свои изменения.
• Я правильно понимаю, вы выделили отдельную ветку, в ней завершили разработ Инфостарт ку, потом смержили. А где промежуток, на котором можно провести автотесты и все остальное?
• Выгружается cf-ник в базу в конце рабочего дня и из нее уже деплоится на продакшен
• А если ошибки?
• С EDT пока что печально, мы только отшлифовываем его.
• У нас тоже проблема с тем, чтобы поднять процесс CI на ветках, которые выделяются на тикет
• У нас такой CI не поднят еще. Пока что, к сожалению, это можно сделать только костылями. Ждем какого-то изменения от 1С, чтобы они в каком-нибудь релизе EDT нам дали какой-нибудь инструмент или библиотеку, чтобы это можно было реализовывать, как в Java – если мы прикручиваем какой-нибудь инструмент, чтобы мы сразу делали  build и деплоили при необходимости. Но пока что это либо OneScript, либо Powershell, либо батники. На Инфостарте, кстати, есть интересная идея через батник, который делает билд из EDT и деплоит. Мы сейчас примерно похожий подход хотим сделать. Но у нас пока что только ручками собирается.
• Кто у вас пишет функциональные тесты?
• Сначала их никто не писал. Потом их начал пробовать писать я – но, к сожалению, у меня на это много времени не было. Потом мне на это выделили одного из начинающих разработ Инфостарт чиков – он тоже начал немного тесты писать. Вообще в нашей компании есть выделенный отдел тестирования, они знают, что такое Gherkin, они тоже пишут свои тесты на Cucumber. И сейчас мы хотим все это передать тестировщикам. Мы обучаем наших тестировщиков в компании для того, чтобы они писали сценарии и тесты. Пока что это делает отдельный разработ Инфостарт чик, джун – мы его взяли, чтобы он постигал 1С через тесты.
• Есть ли какие-то способы костылизации 1С7.7 в направлении DevOps?
• У нас нет 7.7. Но единственное, что я могу вам подсказать – есть несколько Telegram-чатов, где вы можете задать этот вопрос ребятам, которые используют DevOps практики для 7.7. Насколько мне известно, DevOps-практики и подходы были еще достаточно давно опробованы кем-то из участников команды «Серебряная пуля» на 7.7. Можете в их чате задать этот вопрос. Есть чат «1С, БСП, DevOps и Архитектура», где админ Никита Грызлов, там тоже могут помочь.

 

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

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

Приглашаем всех принять участие в тематических митапах Инфостарта: infostart.ru/events/