Правильные игрушки DevOps
После посещения конференции DevOps Pro Moscow 2017 я решила, что построить DevOps в компании – это то же самое, что собрать конструктор, причем входные условия как в детстве: не хватает деталей, либо деталь не подходит по размеру.
Сегодня многие задаются вопросом: как же объединить все инструменты DevOps и построить в своей компании именно тот идеальный процесс быстрой доставки новых функциональностей до клиента, к которому все стремятся? И ответ есть!
На конференции DevOps Pro Moscow 2017 каждый участник преследовал определенную цель, ведь у разных специалистов разные вопросы, интересы и проблемы. И там нашлось место всем: программистам, тестировщикам, релиз инженерам, системным администраторам и мне – ИТ-журналисту, специализирующемуся на вопросах QA. На этой конференции я искала для себя те детали, которые помогут успешно собрать конструктор DevOps и, конечно, меня заботил вопрос о том, а что же с тестированием?
И теперь я хочу поделиться с вами моими находками:
- Ops...я тебя не слышу…
Все твердят, что необходимо использовать Agile в качестве методологии разработки, чтобы программный код и готовые решения поставлялись клиентам регулярно. Казалось бы, все верно, но где же в Agile место для специалистов поддержки? Ведь когда команда разработки планирует свой спринт, отдел IT Оperations ничего не знает об этом.
DevOps возможен только при командной работе, поэтому при строительстве данного процесса все сотрудники компании должны идти рука об руку. Вам не хватает технологий? Посетите конференции, спросите совета у коллег или у Google. А если вам не хватает людей, то создайте их! Так и сделали одни из докладчиков конференции в своей компании. Решая проблему разрозненности подразделений разработки, администрирования и поддержки, а также бизнеса, они ввели две должности для супергероев: Support Expert, который был призван часть своего времени участвовать в жизни команды Delivery, взаимодействовать с аналитиками команды и затем делиться полученной информацией внутри своего отдела поддержки продукта и DevSupport Expert – сотрудник со стороны команды Delivery, который участвует в жизни отдела Support и разборах инцидентов продукта.
- Даешь Jenkins в каждый дом!
При построении DevOps необходима не только вовлеченность всех участников, но и быстрая доставка изменений продукта внутри команды. Jenkins – многофункциональный инструмент, который помогает реализовывать подход непрерывной интеграции и непрерывной поставки ПО. CI ускоряет интеграцию разрозненных копий продукта, а также позволяет настраивать автоматическую сборку проекта и тестировать его. CD, в свою очередь, обеспечивает поставку и развертывание результатов сборки на серверах в автоматическом режиме.
Про Jenkins уже слышал каждый айтишник, а вот построить DevOps с его помощью могут не все. Поэтому тем, кто только входит в ИТ-сферу или уже гуру специалистам, которые встают на путь сборки DevOps конструктора, я советую изучить этот инструмент. Говорят, что дядя Jenkins умеет все, даже варить кофе! Видимо, к нему можно прикрутить плагин для кофемашины и создать расписание, но я пока не умею, поэтому пью чай)
- Первый блин COMам или слава компонентному тестированию
Вы покрыли автотестами 99,99% проекта и гордитесь собой? Но при этом у вас десять тысяч E2E тестов, а их прогон и анализ занимает несколько часов? Хватит это терпеть! С таким подходом у вас в компании никогда не будет DevOps. Запомните, что правильное обеспечение качества проекта – одна из главных деталей для успешной сборки DevOps конструктора. Начните использовать метод компонентного тестирования: запускайте свои E2E тесты автоматически вместе с unit-тестами и тестируйте отдельные функциональности проекта. Удалите избыточные тест-кейсы из регресса, старайтесь наращивать покрытие проекта unit-тестами, используйте moc-объекты при создании тестов, тем самым удаляя при тестировании конкретной функциональности зависимости. Воспользуйтесь методом AСC-анализа, чтобы разобраться в приоритете и количестве ошибок в том или ином компоненте.
Конференция получилась динамичной и живой, некоторые доклады были очень узкоспециальные, другие, наоборот, подходили сразу для нескольких категорий специалистов. Думаю, что каждый смог найти доклад на свой вкус. Такие конференции, как DevOps Pro Moscow 2017, необходимы, прежде всего, для обмена опытом и неформального общения. Не думайте, что после них, вы за три дня без проблем сможете построить свой DevOps в компании. Этот конструктор невозможно собрать в одиночку и за короткий промежуток времени! Все докладчики выполнили свою миссию: они рассказали участникам про инструменты и стратегии DevOps. Что из этого взять на вооружение, а что отбросить, решать только вам.
Хотелось бы поблагодарить организаторов и особенно Татьяну Шапиро, за возможность присутствовать на конференции и выделить тех докладчиков, которые произвели на меня впечатление и оказали влияние на данную статью: Карлос Леон, Вахтанг Баджадзе, Дмитрий Зарубин, Джузеппе д’Алессио, Дмитрий Красильников, Андрей Смирнов. А также не могу не отметить Ждуна – героя этой конференции, который собрал столько профессионалов под одной крышей и Игната Корчагина за отличную композицию на фото =)
Шишкина Яна
ИТ-журналист, обозреватель по вопросам QA
© Издание 12NEWS (ИП Маринин А.Л.), 2017
