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

Напишу короткую преамбулу и сразу к делу. В общем, я в последнее время заметил, что у меня в голове сформировался список крутых технологий, которые говорят о том, что компания по уровню технического развития находится в пантеоне богов. Ну то есть, работать в такой компании, это все равно что лететь в бескрайний косомос на корабле Энтерпрайз – все время открываешь новые фронтиры. Решил его озвучить тут, чтобы вам было понятно, работаете ли вы на Энтерпрайзе или на Эвергивене)

Быстрые релизы. Это не совсем технология, а скорее подход, но тем не менее, без него нет смысла задумываться вообще ни о чем. Суть подхода в том, что все действия по увеличению эффективности вашей работы со стороны руководства должны быть направлены на уменьшение времени выкатки кода на прод. Для такой компании не существует приемлемого времени релиза, кроме нулевого. Если в вашей компании считается нормой срок релиза в 2 недели, это тревожный звоночек. Если же компания понимает, что уменьшение времени релиза ведет к времени сокращения обратной связи и понимает, какие профиты это дает, то все ок и в такой компании вы неизбежно обнаружите следующую крутую технологию

Load Testing. Тут все просто, если в компании есть нагрузочное тестирование, значит у комапнии есть хайлоад. Где есть хайлоад, там есть новые вызовы. Раньше нагрузочное тестирование было уделом спецаильно обученных людей. Сегодня с помощью k6 к нему сожет приобщиться в рамках самообучения любой разработчик

Feature Toggles. Это также скорее подход, но за нима порой стоят вполне конкретные технологии. Самый топовый уровень здесь, это когда вы можете протестировать фичу прямо на своей дебажной сборке. Ну или раскатить фичу на 10% пользователей, чтобы провести A/B тест. Наверное вас триггернуло про дебаг на проде. Наверное вы подумали, что это же "Хуяк хуяк и в продакшен!" ОЙ как плохо и все такое. Но следующая технология позволяет так делать

Chaos Testing. Пантеон богов. Если у вас в работе применяется такой подход, то вы уже должны писать статьи о том, как делали, как применяли, где вам помогло, а где нет. Зачастую, присутствие  Chaos Testing в стеке технологий приводит к тому, что ваш прод становится неуязвим не то что к дебажным сборкам, а вообще к падениям датацентров из-за отключения электричества.

Contract Testing. Если дебажные сборки вам не страшны, то каскадные отказы из-за релиза несовместимых апи все еще могут быть проблемой. Но и для нее есть решение в виде контрактного тестирования. Просто представьте как круто, когда вы удаляете поле и вам не нужно думать о том, что в каком-то далеком проекте, о котором вы даже не знали, словмается совместимость. Вам просто придет уведомление об этом еще до катастрофы и вы сможете избежать подобных проблем. К сожалению контрактное тестирование жутко сложная в поддержке технология, поэтому доступна единицам, ка кв принципе и Chaos Testing