Найти тему

Итоги вебинара в альпине. О чем молчат программисты


На днях я проводил вебинар для программистов, лидов и тех директоров для клиентов корпоративных библиотек альпины. Было около 100 человек и мы довольно плотно пообщались полтора часа. Говорили о всяких техниках, которые позволяют уменьшить time to market способами, которые либо не очевидны, либо идут в разрез с общепринятыми концепциями. Здесь я поделюсь теми концепциями, которые вызывали наибольший интерес и дискуссию.

Большая часть того, что описывалась в докладе, базируется на том как устроен инжиниринг в букинге https://apptractor.ru/develop/kak-ustroen-inzhiniring-v-booking-com.html Главная идея там, это то, что мы двигаемся быстро, но по пути можем что-то ломать. Остальное придется прочитать по ссылке выше 🙂

И так из важного. Если построить процесс разработки определенным образом, то мы можем значительно ускориться за счет частичного или полного отказа от тестировщиков, стейджинга, синхронных код ревью и деплоев по расписанию после демо дня.

Да из каждого пункта есть исключения, например в мобильной разработке тестировщики нужны из-за особенностей релизов, но, в целом, их можно применить почти везде получив значительное ускорение процесса. Например мы прошли этот путь на Хекслете, когда году в 2016 мы убрали стейджинг и не случилось ничего страшного, а стало сильно проще. Быстрее цикл релиза, меньше поддержки инфраструктуры, меньше завязки на то, что кто то проверит за меня, а значит я могу забить на проверку своего кода.

Если вам нужно больше доказательств, то пожалуйста https://news.ycombinator.com/item?id=30899362 в фейсбуке стейджинг не используется. https://refactoring.fm/p/do-you-need-staging большая и классная статья про это же. Вообще если погуглитть, окажется что подобных статей и примеров отказа от стейджинга очень много.

В следующих постах я буду продолжать развивать эту тему, до тех пор пока мы не пройдемся по всему, что было в докладе.

А у вас есть стейджинг?
1 минута