Консультации и совместные проекты по внедрению DevOps-практик в Вашей компании

Что было хорошо видно в опросах при разработке курса по EDT и Git – что (при том, что все заинтересованы в управлении качеством кода) у компаний физически не хватает времени/ресурсов на то, чтобы не просто освоить технологии, но и внедрить их у себя.

Ok, есть возможность помочь друг другу.

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

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

Кому это наиболее актуально

DevOps, как и любые другие практики разработки, нужен не всегда и не всем.

Для кого он будет полезен:

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

Почему это обычно не внедряется

Есть 10+ разработчиков в штате, компания хочет внедрить практики, и – ничего не получается…

Почему?

• Все это интересно, и даже понятно, что это даст, но есть текучка – и из-за нее все откладывается… Надо оторвать ведущих разработчиков и нацелить на “разобраться” – но снять их с проектов и текущих задач компания не может, так как это потеря денег.
• Ok, пусть даже нашли время и ведущие разработчики запустили элементы командной разработки, тестирования и поставки. Теперь это все нужно донести до остальных разработчиков – собирать всех вместе, проводить обучение, а это никогда не делали. Это опять время, ресурсы, неопределенность.
• Это новые практики и не понятно, как их вообще выполнять, не понятно, что делать с тестами, ревью кода и так далее – и спросить не у кого, показать проблему некому и попросить показать “как должно работать” – некого.
• Делались отдельные попытки, но “не пошло”. Нормальная история, когда начали, но бросили на первом же шаге. Просто, скажем, выгрузить конфигурацию в GIT – это не работа с GIT, а просто – хранение конфигурации в GIT. Не дожали и теперь хочется не экспериментировать, а сделать так, чтобы сразу работало.

И т.д. и т.п.

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

Если да – надо просто обратиться за помощью к тем, кто это уже делал.

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

Если Ваша ситуация близка к описываемой, приходите на “пилот” – внедрим, настроим, обучим.

Кто это будет делать с нашей стороны

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

Так что с Вами будет работать Дмитрий и команда IRP Team (обычно до 5 человек – QA-инженер, DevOps-инженер, куратор, пара инженеров-разработчиков).

Все они несколько лет занимаются обучением и внедрением практик DevOps и всем, что с этим связано + активно контрибьютят в open source.

Очень общая схема

Все просто:

1. Кто-то понимает, что нужно внедрять взрослую разработку – и что в принципе в компании есть поддержка этой идеи
2. Компания собирает список проблем, которые им очевидны. Не обязательно детально, не обязательно в терминах будущей системы. Можно общими словами (“каждую неделю случается 3-4 инцидента, когда ошибка попадает к заказчику и там уже смотрят на нас с раздражением”)
3. Мы проводим созвон с командой клиента, где присутствуют руководители отдела, тим лиды, ведущие разработчики, и задаем уточняющие вопросы – как про проблемы, так и про общий уровень готовности.
4. Показываем на реальном проекте, что должно быть в конце, куда можно двигаться, как это все помогает в решении проблем, озвученных ранее
5. После этого или делаем предпроектный анализ, или сразу высылаем план обучения / внедрения / перехода
6. Заключаем договор и дожимаем до внедрения.

Как выглядит базовый план внедрения:

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

Спринт № 0 – Предварительный этап

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

• Знакомство с людьми
• Определение ролей (предварительное)
• Лицензии, сервера, выбор софта

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

Спринт № 1 – Знакомство с технологиями

Цель данного спринта – команда должна захотеть работать по новым методикам.

• Знакомим команды с новыми методиками
• Выполняем регистрации во всех необходимых сервисах
• Делаем первые шаги в GIT и EDT
• QA инженеры изучают Vanessa Automation

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

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

Cпринт № 1.5 – Обучение EDT + GIT

Если после первого спринта компания и команда решили перейти на EDT, то команда проходит курс по EDT + GIT, это займет около 20 часов.

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

Спринт № 2 – Применение практик

После применения практик на легких задачах – начинаем усложнение.

• Упор на настройку контура
• QA инженеры пишут простые тесты
• Разработчики работают от задач
• Выстраивается система git репозиториев и доступов

Целевой результат – разработчики должны перейти на разработку по GitHub flow, CI-контуры должны начать выполнять анализ первых запросов на слияние, QA инженеры должны следить за этим и проверять актуальность тестов после разработки.

Спринт № 3 – Устанавливаем правила игры

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

1. Подключение SonarQube
2. Усложнение сценарных тестов
3. Анализ покрытия кода
4. Вычитка нового кода

Задача этого спринта – зафиксировать правила игры, по которым будет работать компания. Например – не будет приниматься работа до тех пор, пока код не будет покрыт на 80% тестами. Или пока отключаем часть правил анализа кода, так как они не критичны, а времени на их исправление пока нет.

Спринт № 4 – DevOps is coming!

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

• Релиз инженер
• Автоматизация сборок и подготовка релизов
• Формирование карты движения полезностей

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

Спринт № 5 – Закрепляющий

Закрытие всех долгов по предыдущим спринтам.

Финальный спринт, в котором мы закрываем всё то, что не успели ранее.

Цель спринта – команда должна полностью на себя взять все технологии и начать самостоятельно решать возникающие проблемы.

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

Спринты № 6-8

Поддержка:

• Наша команда должна отойти в сторону
• Мы даем поддержку через выбранные каналы связи

Это в идеале.

На практике какое-то время все равно надо будет решать какие-то проблемы, но это те 3 спринта, когда команда должна целиком и полностью перенять все практики.

В итоге

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

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

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

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

Есть вопросы? – давайте обсудим.

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

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

Поехали?

Напишите нам на почту info@irpteam.com или заполните данные в форме ниже:

P.S.

Если Вы долистали аж сюда – не тяните, иначе Ваше место займет кто-то другой :)