Разработчики CICD-инструментов часто указывают в качестве клиентов крупные компании — Microsoft, Oculus, Red Hat, даже Ferrari и NASA. Казалось бы, что такие бренды работают только с дорогими системами, которые не сможет позволить себе условный стартап из пары разработчиков и дизайнера. Но значительная часть инструментов доступна и для небольших команд.
На что можно обратить внимание — расскажем далее.
В больших проектах, состоящих из десятков и сотен взаимодействующих сервисов, всё чаще становится обязательным подход к документации как к коду — docs as code.
Я покажу, как можно применять эту философию в реалиях classified-сервиса, а точнее, начну с первого этапа её внедрения: автоматизации обновления данных в документации.
Честно говоря, Иван часто посмеивался над тщетными усилиями коллег из отдела мониторинга. Они прилагали огромные усилия для реализации метрик, которые им заказывало руководство компании. Они были настолько заняты, что больше никому ничего не хотели делать.
А руководству всё было мало – оно постоянно заказывало всё новые и новые метрики, очень быстро переставая пользоваться тем, что были сделаны ранее.
Последнее время все только и говорили про LeadTime – время поставки бизнесовых фич. Метрика показала сумасшедшее число – 200 дней на поставку одной задачи. Как же все охали, ахали и воздевали руки к небу!
Через некоторое время шум постепенно затих и от руководства поступил заказ на создание еще одной метрики.
Ивану было совершенно понятно, что и новая метрика точно также тихонько помрёт в тёмном уголке.
Действительно, размышлял Иван, знание числа совершенно никому ни о чём не говорит. 200 дней или 2 дня – нет никакой разницы, потому что по числу невозможно определить причину и понять, хорошо это или плохо.
Это типичная ловушка метрик: кажется, что новая метрика расскажет суть бытия и объяснит какой-то тайный секрет. Все так на это надеются, но ничего почему-то не происходит. Да потому что секрет надо искать вовсе не в метриках!
Для Ивана это был пройденный этап. Он понимал, что метрики – это просто обычная деревянная линейка для измерений, а все секреты надо искать в объекте влияния, т.е. в том, что эту метрику формирует.
Для интернет-магазина объектом влияния будут его клиенты, приносящие деньги, а для DevOps – команды, создающие и раскатывающие дистрибутивы с использованием конвейера.
Однажды, устроившись в холле в удобном кресле Иван решил как следует продумать как бы он хотел видеть метрики DevOps с учётом того, что объектом влияния являются команды.
Понятно, что всем хочется уменьшить время поставки. 200 дней – это, конечно, никуда не годится.
Но как, вот в чем вопрос?Читать полностью »
В процессе управления большими объемами данных и их визуализацией мы все чаще сталкиваемся с необходимостью внедрения единого инструмента доступа к управлению функционалом в хранилище. Причем этот инструмент должен быть одинаково удобен и понятен всем сотрудникам подразделения по управлению данными: администраторам, аналитикам, разработчикам и тестировщикам.
Меня зовут Виталий, я отвечаю в Ростелекоме за направление автоматизации тестирования и внедрение DevOps процессов. В данной статье я расскажу об интересном решении данной проблемы в крупном хранилище данных компании Ростелеком.
И вот как мы пришли к такому набору инструментов для решения данной задачи.
Читать полностью »
IntelliJ IDEA на сегодня обладает наиболее продвинутым статическим анализатором кода Java, по своим возможностям оставившим далеко позади таких «ветеранов», как Checkstyle и Spotbugs. Её многочисленные «инспекции» проверяют код в различных аспектах, от стиля кодирования до характерных багов.
Однако пока результаты анализа отображаются лишь в локальном интерфейсе IDE разработчика, от них мало пользы для процесса разработки. Статический анализ необходимо выполнять в качестве первого шага конвейера сборки, его результаты должны определять quality gates, а сборка должна фейлиться, если quality gates не пройдены. Известно, что TeamCity CI интегрирован с IDEA. Но даже если вы не используете TeamCity, вы вполне можете попробовать запускать инспекции IDEA в любом другом CI-сервере. Предлагаю посмотреть, как это можно сделать, используя IDEA Community Edition, Jenkins и Warnings NG plugin.
На прошлой неделе организация The Linux Foundation во время своего мероприятия Open Source Leadership Summit объявила о создании нового фонда для Open Source-проектов. Очередной независимый институт по развитию открытых [и востребованных в индустрии] технологий призван объединить в себе инструменты для DevOps-инженеров, а если быть точнее — для организации и реализации процессов непрерывной доставки, пайплайнов CI/CD. Организацию так и назвали: The Continuous Delivery Foundation (CDF).Читать полностью »
Всем привет!
Я работаю андроид разработчиком, и не так давно мы столкнулись с некоторыми рутинными задачами на своем проекте, которые хотелось бы автоматизировать. Например у нас 5 разных flavor, для каждого из которых требуется загружать свой билд на fabric, иногда для разных тасок по несколько раз в день. Да эту задачу можно сделать и с помощью gradle таски, но хотелось бы не запускать этот процесс на машине разработчика, а делать это как-то централизовано. Или например автоматически заливать билд в google play в бету. Ну и просто хотелось поковырять CI систему. Что из этого получилось, и как мы это настраивали, зачем там Docker, далее в статье.
Пользуетесь ли вы Jenkins? Скорей всего да, потому что это самый популярный на сегодняшний день проект этого класса. Мне всегда интересно было пообщаться с кем-нибудь из разработчиков и задать пару жестких вопросов. Здесь же у нас не просто разработчик, а сам создатель Jenkins — Коске Кавагучи (Kohsuke Kawaguchi).
Как известно, Jenkins — это открытый проект с лицензией MIT. Совсем недавно прошла конференция FOSDEM — самая большая в мире конференция, посвященная свободному программному обеспечению. Бесплатная, открытая, с десятками спикеров со всех уголков мира. Это значит, что там можно встретить кого угодно — даже создателя Jenkins. Небольшим составом друзей и коллег по JUG.ru Group мы устроили туда внезапный десант и смогли записать с создателем Дженкинса хорошее интервью.
Итак, в нашей виртуальной студии Коске Кавагучи (который представится и всё подробно расскажет чуть ниже), Руслан Ахметзянов ARG89 из JUG.ru Group и Кирилл Толкачёв tolkkv из ЦИАН, наш неизменный докладчик, гуру Groovy, Gradle, Spring и стека технологий Netflix, которого вы можете знать по подкасту «Разбор Полётов».
Написать эту статью меня сподвигло большое количество материалов о статическом анализе, всё чаще попадающихся на глаза. Во-первых, это блог PVS-studio, который активно продвигает себя на Хабре при помощи обзоров ошибок, найденных их инструментом в проектах с открытым кодом. Недавно PVS-studio реализовали поддержку Java, и, конечно, разработчики IntelliJ IDEA, чей встроенный анализатор является на сегодня, наверное, самым продвинутым для Java, не могли остаться в стороне.
При чтении таких обзоров возникает ощущение, что речь идёт про волшебный эликсир: нажми на кнопку, и вот он — список дефектов перед глазами. Кажется, что по мере совершенствования анализаторов, багов автоматически будет находиться всё больше и больше, а продукты, просканированные этими роботами, будут становиться всё лучше и лучше, без каких-либо усилий с нашей стороны.
Но волшебных эликсиров не бывает. Я хотел бы поговорить о том, о чём обычно не говорят в постах вида «вот какие штуки может найти наш робот»: чего не могут анализаторы, в чём их реальная роль и место в процессе поставки софта, и как внедрять их правильно.
Храповик (источник: википедия).
Читать полностью »
Как запустить SQL profiler trace, когда проблему надо ловить с 3:00 до 3:30 утра? Делать это можно с помощью трейса на стороне сервера, но это крайне неудобно. Именно не сложно, а неудобно, и всегда лень. Наконец я решился автоматизировать это раз и навсегда. Вот так:
