Comments 36
Примечание. Я здесь немного недоговариваю
Так Вы самое интересное недоговаривать изволите.
Во-первых, мне непонятна Ваша позиция на проекте, т.е. были это изменения «снизу» или сверху».
Во-вторых, у Вас эти открытые и способные люди были ли, и если да, то в каких местах команды? Если не было - откуда брали?
Изменения скорее сверху, тк моя позиция - рук. разработки
У нас, конечно, есть много оч крутых и опытных людей, которые поработали на многих сложных проектах. Поэтому задел был.
Но все равно в плане найма , конечно, надо учитывать специфику - предпочтение отдаем людям, которые готовы учится, data-driven, стремятся к улучшением и тд и тп.
Всё это хорошо, но таки требует совсем немаленьких инвестиций и компетенций, на которые относительно небольшие проекты просто не способны и им проще работать по старинке до определённого порога. В любом случае - хорошее саммари того подхода, к которому командам надо стремиться.
Как " К сожалению, мы не умеем выпускать в продуктив наживую без остановки системы " магически превращается в "и сборка автоматически наживую без даунтайма разворачивается на продуктиве." ?
Вопрос в точку. Мы прямо долго над этим думали. Вообще в общем этот вопрос решается через rolling upgrade через кубр/докер + ExpandAndContract , либо никогда не ломать обратную совместимость ни схемы БД, ни API.
Мы поэкспериментировали с Expand & Contract получается очень медленно и дорого. Обратную совместимость тоже невозможно прямо никогда не ломать и постоянно отслеживать. Поэтому мы решили рискнуть и оставить только rolling upgrade ;-)) . По нашей статистике за полгода у нас возникла только одна проблема причем не на уровне БД, а на уровне UI (пользователь загрузил предыдущую версию UI , мы выпустили обновление, которое сломало обратную совместимость backend API и пользователь получил системную ошибку. Однако после рефреша у него все заработало опять). Итого - все оказалось гораздо проще, чем мы думали.
Ну, конечно, в некоторых сложных случаях мы делаем ExpandAndContract по полной программе, например, если нужно внести несовместимые изменения в поисковые индексы и пересобрать их с нуля и тп.
Я думаю, что нам помогает как раз то, что у нас мелкие и частые релизы. Если изменений мало, то тогда меньше шанс что что-то сломается и разработчик может лучше увидеть какие-то риски и что-то предпринять.
Так же нам помогает то, что у нас система разбита на относительно маленькие микросервисы, которые обновляются очень быстро.
Странно, что не увидел тут отсылки к книге Accelerate (Forsgren, Humble, Kim).
Кстати кому тема интересна, и нормально с английским могу порекомендовать канал "Continuous Delivery" Дейва Фарли
Дейв Фарли - соавтор небезызвестной книги по непрерывному развертыванию
Надо сказать я когда первый раз познакомился с подходом Continuous Delivery, меня тут же прошибло: "Вот оно! Вот к чему нужно идти". Тут же на место встают все практики разработки, ведения команд, тестирования, бережливого производства и пр.
Однако, есть нюансы. Например деплой происходит "через штакетник". Есть шлюз безопасности на стороне заказчика и сперва твой релиз болтается в "предбаннике", пока его не ощупают и не заберут в запретную зону на прод. Но! Ничего не мешает разогнать свою частоту поставок до "предбанника", а потом сказать: "Мы можем быстрее,бутылочное горлышко на вашей стороне".
В 2007 году (15 лет назад) я попал на внутренний семинар в EPAM по CI/CD. Нам тогда рассказывали про CruiseControl.NET и как круто он собирает, тестирует и разворачивает. Если честно, гениальность идеи дошла до меня лишь спустя пару месяцев. Мы это внедрили у себя и получили быстрые релизы, уже к концу 2007 года. Удивительно читать, что в 2019 году это было откровением, с другой стороны, я тоже приложил руку к ГИСЖКХ (со стороны нормализации адресов по ФИАС) и понимаю, что сам подход к проекту (да и заказчик) не предполагает нормальную разработку.
С ростом размера релиза затраты на разработку функции растут экспоненциальноПодозреваю, что так только в некоторых областях разработки.
У меня на работе затраты на разработку растут линейно или даже чуть медленнее (за счет того, что разработчик погружен в задачу и добавление новой фичи может быть почти бесплатным).
Но у нас довольно высокие и слабо зависимые от размера релиза инфраструктурные затраты.
В результате чего нам выгоднее увеличивать релизы с точки зрения временного КПД.
Впрочем, под флагом того же Agile нас вынуждают снижать размер релиза и, соответственно, снижать наш КПД на длительных интервалах.
а что у вас за специфика, что у вас высокие инфраструктурные затраты?
Вот хотел написать похожий комментарий.
Есть "порталы" типа рассматриваемого в статье. Куча слабо связанных мелких фич, типа добавить сортировку в таком-то списке. Ну да, таких задач команда из 50 туловищ может фигачить по 40 в неделю.
А есть задачи типа "прикрутить нейросетку для машинного зрения", "добавить поддержку IPv6" или там "радикально обновить дизайн портала, включая структуру страниц". У всех из них есть огромное "минимальное ядро", на которое уйдут месяцы.
У вас слабое представление о функциональности "порталов". Она на два порядка сложнее, чем вы думаете. Вы себе представить не можете каким количеством НПА и ФЗ регулируется работа подобных порталов, что закупок, что торгов. Зайдите почитайте на досуге.
>> Ну да, таких задач команда из 50 туловищ может фигачить по 40 в неделю.
И почему вы считаете возможным говорить о нашей команде в таким выражениях?
Извините, коллега, за сленг, не хотел вас обидеть.
Я немного знаю за окологосударственные порталы. Да, через язык, которым написаны ФЗ и ПП, сложно продраться, да, там бывает замороченная бизнес-логика. Но всё же было бы интересно узнать, что там за задачи "на два порядка сложнее" типичных CRUD (пусть и под бизнес-логикой)
Автоматически запускается пайплайн развертывания, в рамках которого в специальной песочнице прогоняются модульные тесты ...
И сколько таких песочниц может быть запущено одновременно? Вопрос не праздный; выше по тексту Вы дали понять, что тестовых площадок изначально было две.
это где было две тестовые площадки? в страшной истории? ну там да
сейчас у нас одновременно могу запускаться десятки пайплайнов,
плюс у нас есть основные стенды DEV -> QA -> DEMO1-2 -> KPAK -> PROD
и также есть много (порядка 20) т.н. review стендов - это полнофункциональный стенд, который поднимается из какой-то ветки. Review стенд поднимается минут за 15 для каждого микросервиса и там можно погонять какую-то новую фичу, показать ее аналитику или потестировать изолировано.
В целом мы стремимся минимизировать использования таких review-стендов и по возможности быстрее мержить в мастер, прятать за фича-флагами и уже тестировать на наших основных стендах. Это быстрее и удобнее.
Интересно читать как в первом предложении говорится что Agile мертв, а дальше идёт пперечисление всех Best Practices в Agile.
Agile - мировоззрение и набор практик, а не конкретная методология. Ваш пример Bring Customers First - это отличный пример того как желание помочь клиентам быстрее привело к изменению в подходе к разработки с целью сократить цикл релиза и упростить этот процесс.
Внедрить CI/CD - крутое достижение. Молодцы. По моему скромному опыту, имеет смысл автоматизировать свою release pipeline даже если нет необходимости/желания пушить в прод после каждого commit - это в целом удешевляет процесс разработки, выпуска релизов и хотфиксов, превращая их в рутину.
На мой взгляд CI/CD сегодня - это тоже самое что git. Когда он есть это обычное дело. А вот когда его в проекте нет - это повод сильно задуматься над своим профессионализмом.
Каюсь, до конца не дочитал, потому что в голове засел вопрос, который всегда там возникает при разговорах о CD.
А как определить, что фича в достаточной степени покрыта тестами и готова к тому, чтобы её автоматически без участия человека можно было зарелизить? Если QA Lead даёт добро на релиз, то я спокоен, потому что он человек опытный. А как я могу доверять джунам или мидлам, которые пилят и фичи, и тесты для них?
Хороший вопрос. Подобная уверенность у вас может возникнуть только на основе статистики и ее анализа.
Как мы делаем? Мы собираем разные метрики и анализируем их каждую неделю. Например, одна из метрик - кол-во ошибок с прода.
Далее любые изменения в процессах мы анализируем с прицелом влияния на эти метрики.
Мы шли постепенно. Сначала у нас был большущий и подробный регресс. Мы подумали, что он избыточен и решили его сократить. Сделали - посмотрели, что у нас ситуация не ухудшилась. Потом мы решили что нас регресс даже такой тормозит, подумали давайте мы будем релизить даже без регресса. Попробовали - оказалось, что негативно не повлияло. и тд и тп.
Мы регулярно анализируем регрессионные ошибки и смотрим а почему они возникли и стараемся устранить причину и сделать выводы.
Короче, рецепта готового нет, скорее вы в вашем случае должны методом проб и ошибок найти свой подход.
А по тестам лично я где-то примерно с Бобом Мартином согласен ;-))
Я подумал, что может не совсем понял ваш вопрос. У нас тестирование фич делается руками тестировщиков или аналитиков. Мы пока автотестами в большей мере пытаемся сокращать затраты на регрессионное тестирование.
Кстати, есть достаточно продвинутые компании, которые отказались даже от ручного тестирования фич - даже тестирование делает разработчик. Мне кажется это интересная идея для дальнейшей апробации.
Спасибо за ваши ответы.
Если я правильно помню, метрика, которая меня интересует называется "Time to Production" или может быть "Time to Deliver". Ради уменьшения её до считанных минут требуется автоматизация всего и вся. И вот я не могу понять, как определить, что автоматизированные тесты, особенно, если они написаны разработчиком, достаточны для полностью автоматического деплоя.
статистикой и анализом своих неудач
вы договариваетесь сначала с разработчиками, что все важные и существенные моменты реализации должны быть покрыты автотестами
они начинают их писать (вы можете еще и смотреть на процент покрытия)
вы делаете предположение, что квалификации/компетенции/инструментария/покрытия достаточно чтобы релизить на основе результатов тестов
мы первое время релизы делали всегда после мини-регресса, смотрели сколько у нас регрессионых дефектов и разбирались в их причинах
потом мы увидели, что у нас таких дефектов очень мало и даже те которые есть - с ними вполне можно делать релиз, ну и мы решили попробовать релизится сразу по готовности задачи без регресса
увидели, что ошибок на пролде больше не стало - значит профит!
вот так через постоянный анализ ошибок/ретроспеутивы постепенно вы поймете как писать тесты, чтобы верить им
Спасибо за статью. А как удалось убедить госзаказчика перейти на новый процесс? У них же обычно "водопад" или что-то близкое. Типа релиз раз в полгода, с предварительной приемкой комиссией и т. п.
Спасибо за статью, как синхронизируетесь, когда выкатываете фичу, которая имплементирована в нескольких микросервисах? Если через флаги, то как управляете конфигурацией микросервисов?
Правильно я понял, что ручные тестировщики в вашей схеме отсутствуют? Или все таки кто то смотрит в прод и оценивает насколько покрыт код тестами и мб смотрит в прод на опережение
Нет, присутствуют. Собственно тестирование каждой задачи функциональной делают тестировщики или аналитики (реже). Надо сказать, что тестировщиков у нас сейчас гораздо меньше, чем на предыдущих проектах без схемы DevOps. Раньше у нас было примерно соотношение 8 разработчиков к 10-12 тестировщикам. Сейчас же 8 разработчиков к 2-3 тестировщикам.
Интересная история. Сделано так, как должно быть.
Пара вопросов. ГИС ЖКХ в сфере поставщиков услуг лет пять назад репутацию скорее неработающего сервиса, чем работающего - к примеру, смотрите комментарии к https://habr.com/ru/company/lanit/blog/321476/ Ваш переход на CI/CD и частые релизы когда случился? ГИС ЖКХ не хочет перенять ваш опыт из ГИС Торги?
Второй - Ланит за свои услуги, особенно за проекты ДКС, берет немаленькие деньги. Насколько, по вашему, применим ваш опыт для проектов с ограниченным бюджетом?
Большое спасибо за статью. Расскажите как у вас внутри пайплана умещается проведение НТ. Для показательных тестов надо развернуть , иногда, толстую базу - она проливается каким-то данными? Сами тесты на чем реализованы и кто их поддерживает?
Мы делаем нечто подобное в формате load as a service для команд разработки, хотел бы узнать о вашем опыте :)
У нас есть отдельный стенд для НТ (там близкая к боевой конфигурация и больше реплик). На нем мы гоняем тесты двух типов - "быстрый" НТ и обычный НТ.
Скрипты у быстрого и обычного одинаковые и пишутся на https://k6.io/.
Быстрый прогоняется за 2 минуты - мы его специально сократили по времени чтобы вставить в пайплайн. Обычный - порядка 10-15 минут.
Наш подход - мы делаем стресс тест по самым основным функциям. Мы не заморачиваемся со специфичными сценариями и не пытаемся угадать профиль нагрузки реальный. Считаем, что в этом нет смысла , тк все равно не сможем и овчинка не стоит выделки. До сих пор наш подход позволял минимальными силами отлавливать основные нагрузочные косяки - не сделали индекс или еще чн в этом роде.
Данные мы генерируем этими же скриптами k6 в рамках самого запуска.
Супер толстые базы редко нужны. Этот вопрос решается в индивидуальном порядке.
DevOps инженеры нам настроили всю инфраструктуру, а сами скрипты уже пишутся и поддерживаются самой командой разработки. У нас правило, что задача должна быть сделана под ключ. Если разработчик сделал фичу, но из-за этого у нас падает НТ - это косяк этого разработчика.
В целом НТ - это сложная штука и мы пытаемся держать баланс - с одной стороны чтобы наши накладнгые расходы были минимальные, с другой стороны, чтобы мы находили основные косяки. С другой стороны мы не пытаемся найти все косяки вообще, тк мы можем в случае чего ошибку исправить очень быстро.
Хорошо, когда можно работать с Заказчиком вопреки 44-ФЗ, где в ТЗ заранее должен быть описан итоговый результат и никаких шагов влево-вправо )
Кстати, под "ночным временем" вы понимаете ночь в Москве? не во Владивостоке?
40 релизов в неделю при разработке государственного Amazon или почему Agile is dead