Комментарии 3
Вы действительно серьезно считаете что ускорение деплоя на 3 минуты вляет на Time to market?
Спасибо за вопрос.
Вы абсолютно правы, если, например, релизный цикл происходит раз в месяц, то экономия в 3 минуты на этапе деплоя большой ценности не несёт. Однако рассматривать только этот факт неправильно и стоит взглянуть чуть шире.
Для команд, выполняющих десятки сборок в день (что характерно для продуктовых команд с микросервисной архитектурой), даже незначительная оптимизация на каждом этапе даёт накопительный эффект. 3 минуты * 300 сборок в сутки == ~15 часов сборки на раннерe gitlab в день. Их, как правило, выделяют не очень охотно и пытаются на них экономить, ведь когда команда спит, то ресурсы простаивают. Быстрее сборка == меньше очередь, даже если релиз через месяц, всё равно ощутимо.
Откуда возьмутся эти 300 сборок?
Стоит учесть, что речь не только про релизы, но и все промежуточные сборки: тестовые, feature, hotfix'ы и т.д. Чем активнее команда, тем чаще запускаются сборки, тем заметнее становится даже небольшая оптимизация.
В контексте статьи речь идёт о проекте со 100+ микросервисами и крупной распределённой командой. Она вполне создаёт такой объём (для понимания это ТОП 3 по объёму продукт из кластера). А если поговорить про компанию или хотя бы мой кластер, то незначительный эффект на одном сервисе вполне ощущается на общей картине. И тут речь не про сканирования, а именно часть разработки.
Ускорение сборки, снижение веса артефактов, унификация пайплайнов, шаблонизация конфигураций - каждый из этих шагов вносит вклад в сокращение TTM, и именно их совокупность формирует ощутимый эффект.
Давайте также не будем забывать контекст самой статьи: ИБ плохо и только мешает. Не всегда. Мы можем быть как драйвером более современных технологий, так и теми, кто привносит порядок в хаос. Ключевой момент истории в том, что и команда, и бизнес довольны результатом.
Кстати о сканированиях:
Наши DevOps’ы негодуют, когда проверка кода занимает больше времени, чем сама сборка (даже 3–5 минут на набор из 7+ инструментов). Есть те, кто жалуется, что БД Trivy выгружается каждый раз при сканировании, а это целых 15 секунд. Короче говоря, кому-то и лишняя минута уже как кость в голе.
То есть, да, 3 минуты это не так уж и «вау» для конкретного сервиса, но для большого продукта, кластера, компании в целом, даже такие мелочи могут иметь вес.
Тот неловкий момент, когда все мои знакомые используют .net 6 , а я с нуля такой сразу пишу на .net 8 , а потом когда пытаются зайти через мой лаунчер - при запуске лаунчера появляется плашка обновитесь на .net 8 установите , и им еще надо обновить vcredist...
И для большинства пользователей моих это выглядит как дополнительные действия - они не понимают почему у других все работает без танцев с бубном....
Но это мой прогрессивный танец под мой прогрессивный бубен и точка
4 мифа про DevSecOps, которые мешают безопасной разработке