мы убираем спринты

типичный недоскрам

ждем завершенные таски

и выкладываем их

нет сейчас у нас agile типо

ясно понятно

https://www.youtube.com/watch?v=UQOmGiv7rUk

обязательно посмотри этот видос

тебе должно зайти

мы хотим оставить ценности agile (типо ебашим для пользователей)

но выкладка релизов без спринтов и как готов функционал

условно говоря так

типо сделал функционал, сделал дему людям

все посмотрели надо ли выкладывать если надо выкладываем

ну и всякие автотесты и тд

и автоматизации

вот в этом видосике объясняют что ценность аджайла не в "ебашим для пользователей" а в cash in my poket.

у нас значит не правильный agile

мы стараемся людям делать лучше чтобы cash in my poket

они заносили

потому что "ебашим для пользователей" должно быть вне зависимости аджайл у тебя или ватерфол. Вопрос больше сбора фидбэка и анализа вэлью. А все это влияет на прибыль.

мы стараемся людям делать лучше чтобы cash in my poket

посмотри видос короч, тебе будет полезно

ок

если что - это самый крутой видос на тему всех этих аджайлов

спс

у нас сейчас одна проблемка с выкладкой релизов)

сделали мы сине зеленый релиз

но беда с бд

как жить с ситуациями когда изменения обратно не совместимы

если что мы фигачим без шовные релизы

хотя лично я против их

поэтому вопросы выкладки довольно забавны)

и протестить их довольно сложно

как вы их решаете у себя?

вариант с плашкой типо идут тех работы и выкладка потом не рассмматривают

типо надо чтобы пользователь это не видел

как жить с ситуациями когда изменения обратно не совместимы

не допускать их?

варианты следующие - проанализируй почему случаются нарушения обратной совместимости

у нас много чего делалось на коленке

и при переделке перекрайваем куски

1. слишком большие релизы - тут могут помочь CD 2. слабый анализ проблемы и, как ты сказал, "делали на коленке"

у нас сейчас обе причины на самом деле

у нас специфика сервиса такова

что есть самописные очереди

и есть процессы долго играющие

p.s. для CD не надо отказываться от спринтов - спринты хороший способ организации задач. Главное не думать что конец спринта это какой-то дедлайн.

например пользователь что то заказывает

и создание заказа занимает в среднем 3 - 5 минут

ну у меня есть похожие штуки, типа операция вызывает три транзакции последовательные, и операция может длиться до трех часов

и таких заказаов в среднем оплаченных около 50 открытых на 2 серверах очередей

и таких заказаов в среднем оплаченных около 50 открытых на 2 серверах очередей

у меня 200 в день сейчас

да типо того только еще ошибки могут быть

у нас в секунду обычно по 50 штук стабильно работает

у меня тоже, транзакция на любом этапе может зафэйлиться и это надо хэндлить

почти всегда загружены ими

да причем есть ошибки типо все фатально упало

и есть ошибки упали не фатально а сторонее апи

ну есть, в такой ситуации я просто кикаю задачу в отдельную очередь и прилетает нотификашка

и потом процессится вручную уже

идея в том что как выкладывать релизы

если есть фоновые таски

так а что не так?

например если релиз касается этих очередей

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

например перенос колонки из одной таблицы в другую

а поддерживать обратную совместимость сутки, или даже неделю, не сложно

соответственно изменение в app и бд

если мы релизим в начале app потом бд то некоторое время в бд не будет колонки

и fail при write

если релизим бд а потом app переключаем с синего на зеленый

1. добавляем колонку в базу и пишем код который будет писать в обе колонки 2. деплоим и ждем 3. пишем миграцию которая перенесет старые данные 4. деплоим 5. когда все ок и данные в новой колонке всегда актуальны - дропаем колонку

то после выполнения миграции

данные могут быть обработаны

я тебе вот кейс реальный привел

1. добавляем колонку в базу и пишем код который будет писать в обе колонки 2. деплоим и ждем 3. пишем миграцию которая перенесет старые данные 4. деплоим 5. когда все ок и данные в новой колонке всегда актуальны - дропаем колонку

1.1 проверять существование колонки

ибо пункт 4 будет не скоро

ээээм в смысле?

ты ее добавляешь, ее полюбому небыло раньше

пишем код который будет писать в обе колонки

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

да можно и так

потом некоторое время пишем в места (В старое и новое

у меня просто в дженкинсе есть джоба которая все эти операции в строгой последовательности запускает

а как вы их разделяете?

ветки

кого разделяем?

ну миграции

на добавления колонки

на удаление колонки

мы laravel юзаем и их миграции

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

нет я о том что

ну мол миграция на удаление колонки появится только в новом билде

в начале выполнить только миграции по добавлению колонок

ну так в этой версии билда еще нет "другой" миграции

у нас предлагают извращенный вариант с отдельной веткой миграцией на удаление

типо выложились и потом удаляем

не, это херня полная

я знаю