В
Если в фиче А кто-то реализовал классный ValueObject, который использовали в фиче Б, а выбрали только фичу Б, черипик как-то разрулит это, или мы получим сломанную версию?
нет, не разрулит, это должны выявить тесты
Size: a a a
2021 February 12
В
Можно еще уйти от гита в фича флаги, тогда продукт сам сможет включать фичи когда ему удобно
KA
Можно еще уйти от гита в фича флаги, тогда продукт сам сможет включать фичи когда ему удобно
Я так понимаю, это концепт, обозначенный выше как "Feature toggle + branch by abstraction"?
DS
Можно еще уйти от гита в фича флаги, тогда продукт сам сможет включать фичи когда ему удобно
не надо уходить от гита
DS
Я так понимаю, это концепт, обозначенный выше как "Feature toggle + branch by abstraction"?
ага. ну и TBD как модель ветвления
KA
Видел такое давно и мельком, погуглю, спасибо
DS
только эти штуки суммарно требуют определенной сноровки и инженерной культуры
KA
Если следовать правилу один комит - одна фича, то можно черипикать их выборочно в релизную ветку из dev
Правильно я понимаю, что код фичи попадет в дев, только когда фича готова, протестирована и всё такое? То есть тут ожидаются солидные порции добавления кода и потенциально такие же солидные мердж конфликты у тех, кто заходит в ветку после тебя, но тоже пилил фичу не на полдня?
В
Правильно я понимаю, что код фичи попадет в дев, только когда фича готова, протестирована и всё такое? То есть тут ожидаются солидные порции добавления кода и потенциально такие же солидные мердж конфликты у тех, кто заходит в ветку после тебя, но тоже пилил фичу не на полдня?
да, фича в dev после тестов приходит, не очень понял про солидные порции добавления кода и конфликты, можете пояснить?
SB
Гайз, вопрос наверное в раздел "безысходность и дзен" 🤙
Существует ли способ изящно управлять тем, какие фичи запустить в релиз на основе git?
Делать feature ветки из development и потом мержить их обратно, это понятная база. Но что делать, если было такох фичей несколько на релиз, и было принято решение не релизить одну из них в этот раз, потому что требования изменились, или забаговано так, что нужно переосмысление.
А если в рамках фичи сделался какой-то "фундаментал", которых использовали люди в рамках других фичей, потому что мы быстро делимся кодом в development?
Есть ли хороший релизный флоу? Что-то типа "у меня три фичи смержены в дев, сегодня резилим 2 из них". Ничего толкового не нагуглилось, все варианты на простые кейсы, типа что запланировали на "спринт", то и релизим.
Личный опыт или статья может?
Существует ли способ изящно управлять тем, какие фичи запустить в релиз на основе git?
Делать feature ветки из development и потом мержить их обратно, это понятная база. Но что делать, если было такох фичей несколько на релиз, и было принято решение не релизить одну из них в этот раз, потому что требования изменились, или забаговано так, что нужно переосмысление.
А если в рамках фичи сделался какой-то "фундаментал", которых использовали люди в рамках других фичей, потому что мы быстро делимся кодом в development?
Есть ли хороший релизный флоу? Что-то типа "у меня три фичи смержены в дев, сегодня резилим 2 из них". Ничего толкового не нагуглилось, все варианты на простые кейсы, типа что запланировали на "спринт", то и релизим.
Личный опыт или статья может?
deployed != released. Используйте feature flags.
KA
да, фича в dev после тестов приходит, не очень понял про солидные порции добавления кода и конфликты, можете пояснить?
Ну ты делал фичу неделю, и товарищ свою столько же, и закончили с интервалом в час. Представил что может быть достаточно пересечений, но это конечно вопрос организации кода и декомпозиции фичей, пожалуй.
KA
deployed != released. Используйте feature flags.
Это хорошая мысль, че-то я зашорился, согласен )
SB
да, полный провал. Ну как... не полный но совершенно не то на что я расчитывал.
Мне кажется, event storming - длинный процесс, растягивающийся на несколько недель, как минимум. Во всяком случае по личному опыту. И процесс кстати весьма итеративный, к одному и тому же возвращаемся по нескольку раз
В
Ну ты делал фичу неделю, и товарищ свою столько же, и закончили с интервалом в час. Представил что может быть достаточно пересечений, но это конечно вопрос организации кода и декомпозиции фичей, пожалуй.
неделя это много для таска в jira, такие большие штуки нужно декомпозировать, если фича больше чем один таск в jira, то можно ее в epic ветке вести, но тогда придется черипикать все комиты касающиеся этой фичи
KA
неделя это много для таска в jira, такие большие штуки нужно декомпозировать, если фича больше чем один таск в jira, то можно ее в epic ветке вести, но тогда придется черипикать все комиты касающиеся этой фичи
Да, но в неделю по вашему флоу включено еще тестирование и какой-то багфикс допустим
SP
Гайз, вопрос наверное в раздел "безысходность и дзен" 🤙
Существует ли способ изящно управлять тем, какие фичи запустить в релиз на основе git?
Делать feature ветки из development и потом мержить их обратно, это понятная база. Но что делать, если было такох фичей несколько на релиз, и было принято решение не релизить одну из них в этот раз, потому что требования изменились, или забаговано так, что нужно переосмысление.
А если в рамках фичи сделался какой-то "фундаментал", которых использовали люди в рамках других фичей, потому что мы быстро делимся кодом в development?
Есть ли хороший релизный флоу? Что-то типа "у меня три фичи смержены в дев, сегодня резилим 2 из них". Ничего толкового не нагуглилось, все варианты на простые кейсы, типа что запланировали на "спринт", то и релизим.
Личный опыт или статья может?
Существует ли способ изящно управлять тем, какие фичи запустить в релиз на основе git?
Делать feature ветки из development и потом мержить их обратно, это понятная база. Но что делать, если было такох фичей несколько на релиз, и было принято решение не релизить одну из них в этот раз, потому что требования изменились, или забаговано так, что нужно переосмысление.
А если в рамках фичи сделался какой-то "фундаментал", которых использовали люди в рамках других фичей, потому что мы быстро делимся кодом в development?
Есть ли хороший релизный флоу? Что-то типа "у меня три фичи смержены в дев, сегодня резилим 2 из них". Ничего толкового не нагуглилось, все варианты на простые кейсы, типа что запланировали на "спринт", то и релизим.
Личный опыт или статья может?
trunk based development + feature flags + release branches
SP
KA
А кто-то использует на постоянке фиче флаги? Сколько флагов одновременно? Оверхед кодовый большой? Поддерживается нормально?
SP
А кто-то использует на постоянке фиче флаги? Сколько флагов одновременно? Оверхед кодовый большой? Поддерживается нормально?
у нас сейчас чет типа ~120 фичафлагов. Нагрузка на код базу не оч большая если у тебя хоть минимально практики тестирования развиты (если все оч хотят долгоживущие фича брэнчи - это симптом проблемы с тестированием)