А кто и как заливает фичи в продашен? насколько часто? как откатывает? Где и сколько тестит? вкратце если кто расскажет удачную модель - я был бы мегаблагодарен

условия - тима гдето девелоперов 5-6

тестим на майорке ;)

че? :)

Да просто "где тестим" прикололо ;)

ну понятное едло на staging надо выкатить

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

сложно это умещать и тестить грамотно

Я правильно понял, что QA нет?

одна тестировщица с 8 мобилками разных вендоров :)))

Руками? o.o

да

Бедняшка ;)

инеговори

она такая няшка. даже жалко ее :)

Ну поидее - фичаветка -> закрытие разрабочиком -> возможно, апорв темлида -> уходит тестировщице, которая смотрит, что делалось и тестирует -> мерд в прод...

но с ручным тестированием... хз, сложнее все, если бизнес позволяет, я бы делал цикл какой-то выкатки, что бы тестировка прошла по замороженным фичам и по всему продукту вообще.... но тут опыта мало

да так оно и есть. но баги.. она не может все найти. в итоге приходится ревертить продакшен

это непросто. если уже несколько фич новых добавлено

туда же

Ну вон видел беседу Павла о том, сколько должен отстояться продукт, что бы найти все баги ;)

В ру_девопсе, кажется ;)

Но это, имхо, бред... если цикл тестирования не нашел багов, то вероятность найти незамеченный баг своими силами быстро стремится к нулю....

кароч я тут уже предлагаю

Вам, думаю, нужно отталкиваться от того, сколько нужно тестировке времени пройти весь тесткейс на всех девайсах. Блин, но это реально ад же

а что, разве нельзя автоматизировать тесты на девайсках?

I suggest to use sprints. We decide which features will go to prod in this sprint. When all of them is implemented and merged to dev - merge dev to staging branch. And this staging branch is tested in dev01. all hotfixes for this branch go to dev and staging branches. only after full testing - merge staging to production. once a week, or maybe once a 2weeks.

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

скрам

точно

Я работаю на моем аутсорсе с мая прошлого года, и код который написан в июле-августе, еще не ушел на продакшен

Мои попытки пропихнуть его туда сталкиваются со стеной непонимания

Мы уже параллельно тянем 3 релиза. Но вообще все признают что это пипец. Всю прошлую неделю мы намерживали ветки друг на друга и боролись с километровыми конфликтами

3 релиза, из ни один не попал еще в прод?

Ну поидее - фичаветка -> закрытие разрабочиком -> возможно, апорв темлида -> уходит тестировщице, которая смотрит, что делалось и тестирует -> мерд в прод...

Вот это схема хорошая, но перед или после тестировщицы можно еще выкатывать на стейджинги, на которых тестят все подряд и кто хочет.

3 релиза, из ни один не попал еще в прод?

Да, ни один

вотвот

Причем средний релиз из этих трех - это гигантский рефакторинг database layer, где мы переливаем из dynamodb в mysql половину данных.

В общем у нас так-то проект несложный, но мы сами себе умело строим подножки и находим трудности чтобы героически их решать.

Ай, знаешь.... у меня много проектов с нулевым тестированием у нас и тестированием "кто хочет" у клиента. Не, баги находят конечно, но как правило, совсем не те, которые стоило бы. А реально дыры в итоге уходят в продакшн. Так что я не верю в "тестированием все подряд"...

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

попросил поделиться хорошим опытом, поделились двумя плохими :))))

А на текущей у нас отряд из 3 QA которые тщательно все прочесывают по кейсам, и довольно много находят. А остальное находит руководство на UA среде

Просто не ошибается тот кто ничего не делает :) Так что хороший опыт может говорить о том что проект простецкий и не нуждающийся в тестировании впринципе.

Ну в общем я верю в то что качественная плотная проработка тест-кейсов хорошо влияет на выявляемость багов

Часть из них потом можно автоматизировать в виде unit/functional/acceptance tests и снять нагрузку с QA

По мне, так QA должно как раз и заниматься тем, что читать новые фичи и писать на них приемочные тесты ;)

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

Только если баланс искать. Не удовлетворяет качество итогового сервиса - пусть QA лучше трудятся. Если слишком долго - пусть хуже трудятся. Приоретизировать тест-кейсы, смоки тесты и вот это все.

Я вот слышун а конфах как некоторые крупные игроки выкатывают в день по 100 фич

интересно стало как все организовали они

попросил поделиться хорошим опытом, поделились двумя плохими :))))

У нас кстати все сначала было хорошо. Но как в законе "любой человек в карьерной лестнице поднимается до уровня некомпетентности", у нас также вышло. Фаундер увидел как мы резво и быстро сапортим один проект и все покрываем тестами, и через полтора года у нас на шее уже висело 6 проектов на 10 человек и мы еле кряхтели.

А кто и как заливает фичи в продашен? насколько часто? как откатывает? Где и сколько тестит? вкратце если кто расскажет удачную модель - я был бы мегаблагодарен

по разному, от херак херак, до CI + QA + smoke тесты и выкладка ночью через заранее собранные пакеты

нет у нас ночи...

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

выкатывать по 100 фич вполне возможно, но для этого нужен: * мониторинг * feature flags * культура миграций данных у меня не выходило более 10 фич за день вылить еще ни где...

вот про фичафлаги я как раз и думаю

похоже придется к ним прийти. хотя.. дорого по времени. и местами слишком много if :)

вот про фичафлаги я как раз и думаю

https://www.youtube.com/watch?v=kdB-9zFqKvI

спасибо

Я тоже буду скоро жестко насаждать фича флаги

Потому что это невыносимо по 10 веток иметь и мержить их черт знает как

Кстати я читал как-то статью что в booking .com очень развита культура ревертов. Там весь код пишется так что его легко откатить с прода, и они это часто делают.

Кстати я читал как-то статью что в booking .com очень развита культура ревертов. Там весь код пишется так что его легко откатить с прода, и они это часто делают.

код легко откатывается, а вот испорченные данные - не очень

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

миграции захватывают в большинстве случаев только структуру данных, а у меня уже были ситуации когда "платеж удавивался" и "рассходился по системе". структуры чётенькие, поля в СУБД не менялись, но гемороя прилетело на ровном месте вагон и тележка

О ну да конечно это все надо моделировать и предусматривать.

ERROR: S client not available

ну от повреждения данных и фичефлаги не помогают

Непрерывное развертывание по, джез хамбл. Его почитайте

Там не что делать, а как делать. Т.е. в основном теория, на практике сами её применяете, но все равно интересно и полезно

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

Основная мысль - каждый коммит это релиз-кандидат, который может стать новой версией. Т.е. код всегда должен быть рабочим

Каждый _коммит_? ;)

Да, почитайте книжку, много полезного увидите ))

А что ты применял на практике?

.... Хм... 55к gross в германии и правда "среднее" по сенорам?

Я здесь уже жаловался на пм, могу ещё раз )))

Я б сказал что 55к это на грани нищеты

Если еще квартиру снимать...

У нас даже тестов нет, т.к. "заказчик за это не платит"

Вот и мне кажется... 55к... это 2.5к в месяц чистыми... где-то

А, не, около 3-х

У нас даже тестов нет, т.к. "заказчик за это не платит"

В таких случаях могу только посоветовать вытеснять ПМа из своих компетенций и заниматься тем что считаешь нужным. Делать дольше, говорить "подожди я еще не докодил", а самому писать тесты

Не, плохой совет

Я так делаю и это работает

codeception я впилил в рабочее время, по часу в день кодил. Потом просто по факту сказал "вот нате я сделяль"

У тебя производительность раза в 2 ниже, чем у того, кто этого не делает - это заметно.

На самом деле не особо :) Другие работают и так не быстро

work-life balance, все дела

Ну не в два раза... а хорошие тесты могут и больше жрать

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

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

Не, опять же, бизнесу насрать на галочки и пуши ;)

Зато мне так работать стало проще и приятнее

И даже время экономится

Вот если бы ты показал бы график уменьшения багов в два раза.... это бизнес понял бы ;)

Такой график тяжело строить, в каких метриках это делать?

Если процент багов на количество строк кода - тогда понятно

Число открытых багов в неделю, например