Comments 39
UFO just landed and posted this here
Каждую ночь в случае успешного релиза от trunk отрезается branchСплошная терминологическая путаница.
Возможно, вот описание en.m.wikipedia.org/wiki/Feature_toggle такой техники.
UFO just landed and posted this here
Хотел ответить с сарказмом, но вот вам четыре крутые плюшки, которые несет фичеризм: 1) Возможность А/В тестов на части пользователей/инстансов, 2) Возможность на проде на 100% убедиться, что на полном окружении все ок, 3) возможность запустить функциональность точно в срок, при этом не дергать программистов и девопсов, 4) возможность выключить функцию без того, чтобы трогать код.
UFO just landed and posted this here
Сильно относится к разработке. Не вижу, откуда вы взяли одну ветку, но там описан механизм отпочкования от транка, который очень похож на git flow (develop->master) с отличиями под их проект. Все преимущества фичеринга к разработке как раз относятся, т.к. один раз сделанная и покрытая тестами задача уходит дальше и ответственность полностью снимается с разработчика и переходит к ответственному за проект.
Ну и могу отметить, что накатывание ветки на прод и откатывание после обнаружения бага — это не то же самое, что включение фичи для внутренних подсетей для ручного теста функциональности на полном окружении, как по количеству постарадавших клиентов, так и сил деплойеров.
В общем, недостатки у подхода есть, но гугл так разливает новую функциональность на часть пользователей, так работают с CI в гитхабе — и этот подход хорошо зарекомендовал себя на непрерывных релизах.
Ну и могу отметить, что накатывание ветки на прод и откатывание после обнаружения бага — это не то же самое, что включение фичи для внутренних подсетей для ручного теста функциональности на полном окружении, как по количеству постарадавших клиентов, так и сил деплойеров.
В общем, недостатки у подхода есть, но гугл так разливает новую функциональность на часть пользователей, так работают с CI в гитхабе — и этот подход хорошо зарекомендовал себя на непрерывных релизах.
1) Возможность А/В тестов на части пользователей/инстансов
4) возможность выключить функцию без того, чтобы трогать код.
var features = require('features');
if (features.has('my_feature')) {
...
}
features берется из конфигурационного слота
2) Возможность на проде на 100% убедиться, что на полном окружении все ок, 3)
Заведите себе несколько групп тестовых серверов — для разработки, тестирования задачи c различными видами окружений (верстка prod + бекенд dev, верстка dev + бекенд dev), тестирования итерации (верстка tested + бекенд prod, верстка tested + бекенд tested, верстка prod + бекенд tested), тестирования хотфиксов и пр.
3) возможность запустить функциональность точно в срок, при этом не дергать программистов и девопсовНет никакой связи
Вы на что отвечаете? Ваш код — это и есть фичер тоггл/свитчнры/еще миллион других баззвордов. Именно ради удобства процессов в больших командах и с хорошим континоус фичеризм как раз и используют. Не только для того чтобы иметь возможность откатить изменения, но и например включать / выключать функциональность периодического конкурса (третиц непринятый пункт).
Про полное окружение на проде. Именно тогда, когда у вас много девов, транк и рц- окружение из нескольких фронтов и десятка сеовисов за ним, именно тогда при запуске на прод случаются казусы, когда настройку забыли выставить или прогнать миграцию, тупо админски ее дела типа установки прав. В компаниях, которая не тестирует на пользователях может позволить себе процесс, при котором пользователи не видят косячного функционала без часовой выливки отката изменений.
В общем, не понял, с чего вы мне написали. Также, как и не понял, откуда автор предыдущего комментария высосал «одну ветку».
Мы, например, помимо фич, кучи сред, еще и версионность сервисов используем, и это тоже рождает какое-то количество недостатков вместе с тем профитом, что имеем.
Про полное окружение на проде. Именно тогда, когда у вас много девов, транк и рц- окружение из нескольких фронтов и десятка сеовисов за ним, именно тогда при запуске на прод случаются казусы, когда настройку забыли выставить или прогнать миграцию, тупо админски ее дела типа установки прав. В компаниях, которая не тестирует на пользователях может позволить себе процесс, при котором пользователи не видят косячного функционала без часовой выливки отката изменений.
В общем, не понял, с чего вы мне написали. Также, как и не понял, откуда автор предыдущего комментария высосал «одну ветку».
Мы, например, помимо фич, кучи сред, еще и версионность сервисов используем, и это тоже рождает какое-то количество недостатков вместе с тем профитом, что имеем.
UFO just landed and posted this here
Вы на что отвечаете?
В общем, не понял, с чего вы мне написали.
Вас нет в переписке выше. Это аргументы на конкретные тезизы msnre
Если сравнивать с ветками, то при таком подходе нет необходимости мерджить большие ветки с мастером, следовательно нет конфликтов. Что очень удобно когда над проектом работает очень большая команда.
Но как и любого подхода у него есть минуса, например увеличивается сложность кода.
Но как и любого подхода у него есть минуса, например увеличивается сложность кода.
Статья от Фаулера
Фичеринг.
Есть транковые окружения, на которых идет процесс разработки. Скажем, их версия — 0.200, тогда версия бранча — 0.199. Т. к. релиз каждый день, и каждую ночь от транка отрезается бранч, изменения, которые были в транке, будут в бранче, т. е. версия транка будет уже 0.201, а бранча — 0.200. Чтобы скрыть код для неготового функционала, нужен конфигурационный флаг. По сути, на момент релиза какой-либо фичи код уже находится в продакшн, просто он скрыт.
Сначала получаем требования, после чего QA-команда, проанализировав и выяснив требования, начинает писать тест-кейсы. В это же время идет процесс разработки. После того как разработчики, дав добро на тестирование, включают конфигурационный флаг на тестовом окружении, QA-инженеры начинается функциональное тестирование. Пока QA-инженеры тестируют и находят ошибки, которые разработчики исправляют, автоматизаторы или Selenium-команда (так мы их называем), начинают процесс автоматизации тест-кейсов. После функционально тестирования проводится регрессионное тестирование.Вы меня окончательно запутали.
UFO just landed and posted this here
Скорее всего под функциональным тестированием подразумевается тестирование конкретной задачи, а регрессионное тестирование проводится после того как все задачи были протестированы и собраны в итерацию.
PS: Кажется я начинаю понимать автора. В следующим раз, DataArt вам следует писать статью коллективно и хотя бы проверять на опечатки.
PS: Кажется я начинаю понимать автора. В следующим раз, DataArt вам следует писать статью коллективно и хотя бы проверять на опечатки.
Спасибо за статью, читал с интересом.
Планируете ли переход к continuous deployment, как к следующему шагу?
И да, в терминах путаница, в статье идет речь о QC, а не QA инженерах.
Планируете ли переход к continuous deployment, как к следующему шагу?
И да, в терминах путаница, в статье идет речь о QC, а не QA инженерах.
С ежедневными релизами у меня только такие ассоциации. Извините.
Не хотел бы я у вас работать. Как бы там ни было всё автоматизировано, ежедневный релиз — это ежедневный стресс. Что разработчики, что тестеры крутятся как белки в колесе, чтобы не дай бог что не отвалилось, не пролезли баги в релиз. Ни передохнуть, ни поэкспериментировать. Как роботы. После месяца такой работы надо давать неделю отпуска как минимум.
А я не уверен, что там стресс.
Просто разработчик что-то изменил/добавил несущественное и закачал измененный файл в репозиторий, а он автоматом собрался и зарелизился.
Только вот каково это для пользователя, получать каждый раз новые релизы? Не надоедает?
Просто разработчик что-то изменил/добавил несущественное и закачал измененный файл в репозиторий, а он автоматом собрался и зарелизился.
Только вот каково это для пользователя, получать каждый раз новые релизы? Не надоедает?
UFO just landed and posted this here
Мне кажется стресс — это когда выкатываешь огромный релиз и с тревогой ждешь, что вывалится такая же огромная куча багов. Проще релизить маленькими порциями каждый день.
На ум приходит аналогия между обновлением дистрибутивов Linux:
На ум приходит аналогия между обновлением дистрибутивов Linux:
- Ubuntu: как часто бывает — обновился до новой версии, сломал все.
- ArchLinux: rolling release, система постепенно обновляется маленькими порциями
У нас всяких проектов хватает, на любой вкус.
Давайте вещи называть своими именами. Не релизы ежедневные, а тесты. Сами же написали:
и
Так что — дань моде и модным словечкам это, конечно, хорошо но не стоит увлекаться. С точки зрения бизнеса частые релизы не нужны — никакой заказчик себе каждый день в бой новую версию заливать не станет. Исключением является ситуация профуканных дедлайнов, тогда да, возможность представить хоть что-то спасёт немало менеджерских задов.
Как быть, если утром обнаруживается существенный баг? В этом случае процесс релиза останавливается до исправления ошибки.
и
Хотя релизы происходят каждый день, это, конечно, не значит, что мы каждый день добавляем новый функционал.
Так что — дань моде и модным словечкам это, конечно, хорошо но не стоит увлекаться. С точки зрения бизнеса частые релизы не нужны — никакой заказчик себе каждый день в бой новую версию заливать не станет. Исключением является ситуация профуканных дедлайнов, тогда да, возможность представить хоть что-то спасёт немало менеджерских задов.
1) Когда пишутся тесты на новый функионал
2) Какого уровня эти тесты, приведите пример (Например после авторизации есть кнопка на форме или что-то более серьезное)
3) Как описываются функциональные тесты с бизнес-логикой?
2) Какого уровня эти тесты, приведите пример (Например после авторизации есть кнопка на форме или что-то более серьезное)
3) Как описываются функциональные тесты с бизнес-логикой?
Тестовые случае пишутся после того как были получены и проанализированы требования, т. е. параллельно процессу разработки. Сложность тест-кейсов зависит от того, какой функционал они покрывают.
Требования предоставляются заказчиком исходя из потребностей бизнеса, а тест-кейсы уже непосредственно покрывают эти требования. На одно требование может быть написано несколько тестовых случаев.
Требования предоставляются заказчиком исходя из потребностей бизнеса, а тест-кейсы уже непосредственно покрывают эти требования. На одно требование может быть написано несколько тестовых случаев.
Всем, кто считает, что ежедневные релизы — стресс, скажу уверенно «нет». Работа в таком проекте очень интересная, т. к. все развивается очень стремительно. К этой модели разработки мы пришли не сразу, переход был длительным и трудоемким, но успешным. Заказчик доволен, а это в нашем деле очень важно.
Sign up to leave a comment.
Ежедневные релизы — это не так уж страшно