Меня зовут Эмиль Карапетян, я являюсь руководителем группы автоматизации предприятий в компании Синимекс. У меня будет теоретический доклад, в нем не будет ничего особо практического. Я расскажу о том, что такое 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 вообще мало кто слышал. И сейчас мы практически ледоколом врезаемся в нашу инфраструктуру и начинаем применять все эти инструменты, практики, создаем 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.
