Здравствуйте и спасибо за вопросы! По поводу роллбэка - вы всё верно написали! Сломать хотфиксом и получить два стула - легко :) Возможность откатиться на более поздние релизы у нас имеется, причём тоже на 10 последних.
Про canary и дороговизну множества окружений. Чтобы ответить, надо рассказать немного про архитектуру, в том числе. Для нашего самого крупного сервиса (монолит) разворачивается отдельный инстанс пер клиента (мы B2B, у нас их под тысячу). В каждом инстансе крутятся десятки подов (в зависимости от нагруженности клиента) в разных деплоймент группах. Таким образом, canary становится достаточно дорогим удовольствием, надо всё это ещё и дублировать при выкладке. Более того, на порядок замедляется время деплоя. При таких вводных ни о каких двух-трёх релизах в рабочие сутки на stable речи быть не может.
Мы регулярно отщипляем микросервисы от монолита и так же движемся в сторону мультитенантного единого процесса монолита, в следующем году планируем некоторые деплоймент группы сделать едиными. Перевести весь монолит на единый процесс - долгий путь, который нам предстоит.
Второй причиной является необходимость наличия единой метрики, на которую будет смотреть canary во время деплоя. В ситуации, когда сервис большой и про несколько доменов сразу - обеспечить такую метрику сложно. Да и не всё поведение системы можно покрыть метриками.
Третьей причиной вижу то, что staging окружение не способно отловить проблемы больших нагруженных проектов и мы рискуем угодить в ситуацию, когда на стейдже всё ок, а при деплое на прод canary частенько будет откатываться, блокировать деплой - и все вытекающие последствия.
Что касается десятка других микросервисов, там действительно в критических сервисах применяем canary - например, публичный API Gate, сервис триггерных механик.
Прошло полтора года :) Рассказываю)
Такой подход помог мне за полгода переквалифицироваться из десктоп-разработчика в веб-разработчика, уехать в Москву и устроиться в компанию, в которую хотел. После трудоустройства было уже сложнее, поскольку в работе и так была куча всего нового, на дополнительное образование времени не было. Сейчас, спустя год, уже освоился и считаю, что снова могу начать заниматься самообразованием по данной схеме. В итоге обновил план обучения и с этой недели снова вернулся к процессу. Надеюсь, будет ещё один качественный рывок :)
Спасибо за статью и описанный способ! С недавних пор веду учёт различных задач, связанных с самообразованием (некий план обучения различным технологиям), даже сроки пытался ставить, но всё равно много времени прокрастинировал. Использую Ваш способ с того дня, как вышла статья, и, о чудо, я перестал прокрастинировать! Без сарказма. Конечно, рано говорить о результатах, но пока я очень доволен своей роботоспособностью :)
А как насчёт того, чтобы вынести метод ArrivedToRecipient в базовый абстрактный класс GenericParcel и сделать его виртуальным? Кто захочет — переиспользует логику (как в случае с UrgentParcel), кому нужно — переопределит (Parcel). Тогда и копипасты не будет, и open-closed principle не будет нарушен. То есть, если у наследников изначально есть общая логика, то очевидно, что она должна лежать в базовом абстрактном классе, а не быть скопированной повсюду.
Сорри за повтор, товарищ APXEOLOG уже выше написал об этом
А ещё может случиться так, что старый владелец выкинул симку, её оператор перевыпустил и продал другому человеку. Только вот РТ об этом никак узнать не может. Думаю, случай не реже, чем ошибка при заполнении номера телефона в договоре РТ.
Здравствуйте и спасибо за вопросы!
По поводу роллбэка - вы всё верно написали! Сломать хотфиксом и получить два стула - легко :) Возможность откатиться на более поздние релизы у нас имеется, причём тоже на 10 последних.
Про canary и дороговизну множества окружений. Чтобы ответить, надо рассказать немного про архитектуру, в том числе.
Для нашего самого крупного сервиса (монолит) разворачивается отдельный инстанс пер клиента (мы B2B, у нас их под тысячу). В каждом инстансе крутятся десятки подов (в зависимости от нагруженности клиента) в разных деплоймент группах.
Таким образом, canary становится достаточно дорогим удовольствием, надо всё это ещё и дублировать при выкладке. Более того, на порядок замедляется время деплоя. При таких вводных ни о каких двух-трёх релизах в рабочие сутки на stable речи быть не может.
Мы регулярно отщипляем микросервисы от монолита и так же движемся в сторону мультитенантного единого процесса монолита, в следующем году планируем некоторые деплоймент группы сделать едиными. Перевести весь монолит на единый процесс - долгий путь, который нам предстоит.
Второй причиной является необходимость наличия единой метрики, на которую будет смотреть canary во время деплоя. В ситуации, когда сервис большой и про несколько доменов сразу - обеспечить такую метрику сложно. Да и не всё поведение системы можно покрыть метриками.
Третьей причиной вижу то, что staging окружение не способно отловить проблемы больших нагруженных проектов и мы рискуем угодить в ситуацию, когда на стейдже всё ок, а при деплое на прод canary частенько будет откатываться, блокировать деплой - и все вытекающие последствия.
Что касается десятка других микросервисов, там действительно в критических сервисах применяем canary - например, публичный API Gate, сервис триггерных механик.
Спасибо за высокую оценку статьи! Про выступление подумаем обязательно :)
Екатерина, спасибо за статью. Подскажите, пожалуйста, каким инструментов вы пользуетесь для планирования? Что за сервис?
Такой подход помог мне за полгода переквалифицироваться из десктоп-разработчика в веб-разработчика, уехать в Москву и устроиться в компанию, в которую хотел. После трудоустройства было уже сложнее, поскольку в работе и так была куча всего нового, на дополнительное образование времени не было. Сейчас, спустя год, уже освоился и считаю, что снова могу начать заниматься самообразованием по данной схеме. В итоге обновил план обучения и с этой недели снова вернулся к процессу. Надеюсь, будет ещё один качественный рывок :)
Сорри за повтор, товарищ APXEOLOG уже выше написал об этом
Черт возьми, закончили на самом интересном месте! Это что, троллинг такой?) Конечно, пишите дальше! У вас хороший стиль изложения, легко читается.