сначала фичу обсуждают, делают задание на эту фичу, потом обсуждают тезнические варианты решения, сравнивают альтернативы, какие-то +/- каждой из них, потом пишут код, потом ревью кода другим человеком

это всё займёт несколько дней

а не пару часов

сначала фичу обсуждают, делают задание на эту фичу, потом обсуждают тезнические варианты решения, сравнивают альтернативы, какие-то +/- каждой из них, потом пишут код, потом ревью кода другим человеком

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

чего тут ждать несколько дней ?

у тебя разработчики неквалифицированные чтобы обсуждать их решения ?

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

Ты как-то намертво прибиваешь понятие кодирования фичи к понятию общей выкатки фичи. Пока фичу обсуждают и согласовывают, ее уже раз 5 могут задеплоить и протестировать в каком-то полусобранном виде.

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

Лол

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

Ты непутай пакетирование с жесткими стандартами в дистрибе, со своим сайтом

Ты как-то намертво прибиваешь понятие кодирования фичи к понятию общей выкатки фичи. Пока фичу обсуждают и согласовывают, ее уже раз 5 могут задеплоить и протестировать в каком-то полусобранном виде.

так какой смысл тратить силы на реализацию если ещё не утвердили оптимальный способ решения?

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

так какой смысл тратить силы на реализацию если ещё не утвердили оптимальный способ решения?

Разработчики сами должны найти оптимальный способ решения. А маркетологи там могут неделю согласовывать цвет кнопки какой-то. Который меняется 1 строчкой в css

так какой смысл тратить силы на реализацию если ещё не утвердили оптимальный способ решения?

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

А сама фича состоит из кучи кода, тестов, взаимодействует с другими сервисами и т.д.

так какой смысл тратить силы на реализацию если ещё не утвердили оптимальный способ решения?

Это можно понять тока по тестам и через десТок быстрых релизов

Разработчики сами должны найти оптимальный способ решения. А маркетологи там могут неделю согласовывать цвет кнопки какой-то. Который меняется 1 строчкой в css

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

действительно, какой ужас

люди обсуждают решение проблемы

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

Ага, и .... ?

это занимает время, в итоге время выполнения фичи от начала до конца будет уже не 2 часа

иии?

речь про деплой фичи идёт

и на фоне общего времени с момента открытия задачи до её появления на сервере пройдёт довольно много времени, где разница +- несколько дней не будет заметна

ежу понятно, что на свете есть фичи, которые не вписываются в 2 часа. Просто зачем ограничивать деплой уже готовых фич искуственным сроком релиза?

Ну не 2 часа, 4 часа на споры. Ничего принципиально не меняется.

ну, смотря какая фича, можно и неделю обсуждать там что-то вяло

Можно, а всю эту неделю будут идти деплои фич которые были разработаны неделю назад.

То есть тут сроки выполнения фичи никак не влияют. Она может уйти в сегодняшний деплой, в завтрашний, в послезавтрашний. Но 3 недели не надо ждать.

идеальный вариант мне кажется - каждую неделю релиз, 1 день тратить на ручные тесты (ну, как-то можно впихнуть)

и релизить те фичи, которые успели сделать

ну и по итогам недели какая-то рассылка с описанием новостей

Ручными тестами далеко не все удается покрыть.

Кто же будет несколько тысяч тестов прогонять вручную?

ну вот даже Бог сотворял наш мир за неделю ?

он не релизил мир каждые 2 часа

и релизить те фичи, которые успели сделать

Мы так живем и это не работает

Кто же будет несколько тысяч тестов прогонять вручную?

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

От ручных тоже не надо отказываться, но они более творческие и абстрактные

воот

он не релизил мир каждые 2 часа

именно так Он и дедал, если что

там по релизу в день

перечитай книгу Бытия, что ли :)

а там про релизы же не написано

как это не написано?

ну, каждый день по коммиту, да

учитывая, что заказчиком был Он сам, там фидбек на каждый релиз есть

от заказчика

значит был релиз, неизбежно

хмм)) вот у нас уже разные толкования))

так и получаются секты

>>> 3И сказал Бог: да будет свет. И стал свет. >>> 4И увидел Бог свет, что он хорош, и отделил Бог свет от тьмы.

Смотри, задеплоил, увидел что это хорошо, не стал откатывать.

this

Приступил к следующей фиче.

так про деплой тут нет, он мог просто коммит делать каждый день

дак как нет про деплой-тооо?

После комита нельзя сказать хорошо оно или нет.

он фичу сразу в прод деплоит

посмотри, тестовой среды нет

по крайней мере мы её не видим

ну, здесь лишь понятно, что задача была полностью решена за 7 дней

то есть как минимум раз в 7 дней был 1 релиз

а вот эти промежуточные дни - непонятно

инкрементальная разработка

а вот эти промежуточные дни - непонятно

В промежуточные дни были билды.

Он просто накатывал новый слой каждый раз.

ERROR: S client not available

ну, тут чёткого указания на это нет, это просто каждый трактует так, как ему нравится

Как должно выглядеть чёткое указание?))) "И провёл A/B тест в боевой вселенной, птицы сказали, что им понравилось"

ну, как-то так)))

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

Как должно выглядеть чёткое указание?))) "И провёл A/B тест в боевой вселенной, птицы сказали, что им понравилось"

мне это напомнило вот этот комикс http://joyreactor.cc/post/2222344

а когда у тебя веб, зачем себе эти костыли в виде релизов ставить?

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

надо синхронизировать фичи? да пожалуйста. только релиз тут причём?

ну, я согласен - релиз по требованию - это хорошо

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

тут мониторинг решает

и правильный деплой

ну даже если мониторинг - вот в пятницу выкатили

там выше b/g уже раз пять точно повторили

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

с докером так вообще можно переключать на всё что в регистри есть

не за миллисекунды конечно

ну да, я согласен, но самая большая проблема с субд

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

откатывать её

вот без этого хочется

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

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

всегда только добавляется

и всё

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

но не сводит их до 0

оно их сводит к тому что это работает 95% времени

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

А кто тут пытается свести до 0?

если мы выложили релиз и кто-то уже воспользовался фичей - что?

удалить таблицу уже нельзя