Наверняка частые релизы означают, что большинство этих действий уже сделаны. Да и не все 100% действий из шпаргалки нужны и применимы для всех решений.
Наш чеклист скорее предназначен для вывода нового решения в прод, когда ничего не было, и вот появилось, выведено в эксплуатацию. А это событие случается реже двух раз в месяц.
Фамилия нужна, чтобы идентифицировать пассажира. В одной брони бронировании может оказаться несколько человек. Например, семья или группа коллег, летящих вместе.
Так как опрос связан с конкретным путешествием, бронь и фамилия, как данные, идентифицирующие это путешествие, важны и передаются в авиакомпанию (впрочем, компания владеет этой информацией и без опроса).
Это не только ради бонусов. Диалог между компанией и клиентом сейчас — это вполне привычная практика. Главное предоставить действительно удобный инструмент, и люди готовы идти навстречу.
Иногда клиентам есть что сказать. Иногда хочется поблагодарить. А иногда и бонусы не лишние, но они только один из поводов.
Во-первых, Job’ы сложно тестировать, нет готового инструмента для того, чтобы протестировать ваш Job, кроме проверки синтаксиса файла .gitlab-ci.yml.
Во-вторых, не совсем очевидно работают секции only & except. При написании первого пайплайна ожидали, что условия в only будут “И”, а они оказались “ИЛИ”. Чтобы выйти из положения, нужно в except писать все исключения, например:
чтобы запускать сборку по расписанию в ветке develop нужно
only:
-web
-schedules
except:
-master
-/^feature/.$/
-/^bug/.$/
-/^bugfix/.$/
-/^cherry-pick-.$/
В-третьих, до недавнего времени не было возможности разделить конфигурацию на несколько файлов, и наш текущий файл .gitlab-ci.yml уже слишком большой.
Остальные сложности были связаны скорее с тем, что не понимали формат и учились в процессе.
Сейчас используем почти весь функционал Gitlab-CI кроме environment, если у вас есть какие-то вопросы, то можно поговорить более предметно.
Спасибо! Не можем сказать, что готовы расстаться с какой-то технологией. Но с каждой были сложности, которые мы осознали не сразу.
Например, Hazelcast довольно сложен, если вам нужно разобраться, почему он вдруг начинает работать медленно или почему он делает неожиданные вещи. Последнее, что мы пытались настроить в Hazelcast, но не очень успешно — это логирование медленных операций. И мы так и не добились от него вменяемой информации по этому вопросу.
По части Eureka: мы используем не самую актуальную версию, и в UI у Eureka есть проблемы, но мы с этим живем.
Gitlab CI только на первый взгляд имеет очевидный язык настройки Job’ов.
И если бы начинали сейчас, то сразу подумали бы о правильном тестировании микросервисов.
И ещё хотели добавить вот что. Наличие одной БД для нескольких микросервисов, которые используют liquibase, приводит к конкуренции за таблицы liquibase при старте приложения и может привести как к замедлению, так и к незапуску. Это в копилку знаний, почему нужно делать отдельные БД :)
Вы правы, все микросервисы должны иметь изолированную базу, и мы идем к этому. До сих пор не перешли, поскольку есть более приоритетные задачи. А также осложнения:
база данных используется как источник для других служб,
есть резервное копирование и восстановление данных, которое работает на основе базы, которая была на монолите.
По поводу “может случайно (или намеренно) создать сайдэффекты” – такого с БД не было. В этой плоскости у нас нет проблем.
При разделении монолитного приложения мы прошли несколько этапов. Изначально все Entity базы данных хранились в одном модуле Maven, и была настроена политика обновления схемы на основе изменений Entity классов hibernate.hbm2ddl.auto: update. Когда мы выделили первый микросервис, то сразу столкнулись с проблемой двойного апдейта базы, так как было два приложения, которые на старте пытались инициализировать новую схему БД. Авто-апдейт схемы выключили и перешли на написание скриптов и их запуск при деплое на окружении. Изначально это делалось руками, потом внедрили Liquibase.
Постепенно мы разносили Entity классы по микросервисам, которым они «принадлежат». В текущий момент мы все ещё имеем одну БД, но таблицы в этой БД принадлежат разным микросервисам.
Для записи в БД мы так же используем Hazelcast, то есть мы не пишем в БД напрямую, а бросаем Event на событие, и каждый микросервис (в том числе и тот, который бросил Event) записывает в БД. Это сделано не для всех случаев, но это необходимо, чтобы между микросервисами не было интеграции через БД.
Мы выбрали Hazelcast по нескольким причинам:
Действительно, был опыт работы с ним. Redis использовали только как кэш или для хранения сессий, но не было опыта работы как с event-bus. С Hazelcast, напротив, был опыт подобной работы, хоть и не большой.
Наличие необходимого функционала из коробки (ex. reliable topic).
По поводу писем со 100 ченджами, наверное вы имеете ввиду что-то типа Release Notes. Это немножко другое. Release Notes это все же техническая коммуникация для технически-подкованных пользователей. Мы же про то, как объяснить не сильно подвинутому в технологиях ключевому пользователю (кассир, бухгалтер, менеджер…), что в его работе поменялось.
(Плюс не писать про все и сразу нам помогают таргетированные рассылки для пользователей с разными ролями. Технологам — одни, системным администраторам — другие, пользователям — третьи. Ведь каждого из них касается только часть).
Главное помнить, что мы хотим рассказать о ключевых (а в идеале одном ключевом) изменениях, вошедших в релиз, а не обо всех фичах.
Маркетологи здесь могут вам помочь, так как они, во-первых, на это заточены (и тут дело не в рекламе, а в вычленении главного), а во-вторых, человеку, который глубоко включен в проект зачастую это сложно.
Но на наш взгляд идеальная схема выглядит следующим образом — менеджеры проекта готовят драфт, проверяют его на ключевом пользователе, и отдают маркетологам на финальное облагораживание. Понятно, что это требует времени, но ведь для этого релизы и планируются.
Пользователи в домене, но это внешние пользователи, поэтому к себе на винду и в почту они ходят под своими учетками, а доменные учетные записи они используют для того, чтобы ходить в рабочие приложения.
Переключалка не выглядит правильным способом решения проблемы. Скорее всего, HttpClient в связке с CurlHandler должен при неудачном Negotiate-запросе пробовать следующий вариант. Скоро закинем вопрос на github.
Проблема в том, что окружение на test/stage/production серверах может сильно отличаться, что ведет к непредсказуемым ошибкам. С контейнерами можно быть уверенным, что если это работает локально, то также будет и на продакшене.
А вообще Хансельман написал отдельную статью, отвечающую на этот вопрос.
В проекте используется минимальное количество функционала IIS, поэтому по поводу расставания с ним у нас не возникло сомнений. При появлении необходимости будем брать фронтенд-сервер в соответствии с условиями. Какую то часть на себя возьмет Kubernetes (например, балансировщик).
По поводу AD — аутентификация происходит во внешнем для нашего решения сервисе, настройкой аутентификации в данном проекте не занимаемся.
Контейнеров будет несколько — основной мобильный сервис, сервис push уведомлений, сервис управлениями баннерами. Как раз про контейнеры подробно напишем в следующих статьях.
Наверняка частые релизы означают, что большинство этих действий уже сделаны. Да и не все 100% действий из шпаргалки нужны и применимы для всех решений.
Наш чеклист скорее предназначен для вывода нового решения в прод, когда ничего не было, и вот появилось, выведено в эксплуатацию. А это событие случается реже двух раз в месяц.
В базе, мы используем Entity Framework, но можно и другие http://masstransit-project.com/MassTransit/advanced/sagas/persistence.html
Скорее всего, да, только надо использовать для корелляции ивента не CorrelateById, а CorrelateBy.
Спасибо, поправили!
Фамилия нужна, чтобы идентифицировать пассажира. В одной брони бронировании может оказаться несколько человек. Например, семья или группа коллег, летящих вместе.
Так как опрос связан с конкретным путешествием, бронь и фамилия, как данные, идентифицирующие это путешествие, важны и передаются в авиакомпанию (впрочем, компания владеет этой информацией и без опроса).
Это не только ради бонусов. Диалог между компанией и клиентом сейчас — это вполне привычная практика. Главное предоставить действительно удобный инструмент, и люди готовы идти навстречу.
Иногда клиентам есть что сказать. Иногда хочется поблагодарить. А иногда и бонусы не лишние, но они только один из поводов.
Во-первых, Job’ы сложно тестировать, нет готового инструмента для того, чтобы протестировать ваш Job, кроме проверки синтаксиса файла .gitlab-ci.yml.
Во-вторых, не совсем очевидно работают секции only & except. При написании первого пайплайна ожидали, что условия в only будут “И”, а они оказались “ИЛИ”. Чтобы выйти из положения, нужно в except писать все исключения, например:
чтобы запускать сборку по расписанию в ветке develop нужно
only:
-web
-schedules
except:
-master
-/^feature/.$/
-/^bug/.$/
-/^bugfix/.$/
-/^cherry-pick-.$/
В-третьих, до недавнего времени не было возможности разделить конфигурацию на несколько файлов, и наш текущий файл .gitlab-ci.yml уже слишком большой.
Остальные сложности были связаны скорее с тем, что не понимали формат и учились в процессе.
Сейчас используем почти весь функционал Gitlab-CI кроме environment, если у вас есть какие-то вопросы, то можно поговорить более предметно.
Спасибо! Не можем сказать, что готовы расстаться с какой-то технологией. Но с каждой были сложности, которые мы осознали не сразу.
Например, Hazelcast довольно сложен, если вам нужно разобраться, почему он вдруг начинает работать медленно или почему он делает неожиданные вещи. Последнее, что мы пытались настроить в Hazelcast, но не очень успешно — это логирование медленных операций. И мы так и не добились от него вменяемой информации по этому вопросу.
По части Eureka: мы используем не самую актуальную версию, и в UI у Eureka есть проблемы, но мы с этим живем.
Gitlab CI только на первый взгляд имеет очевидный язык настройки Job’ов.
И если бы начинали сейчас, то сразу подумали бы о правильном тестировании микросервисов.
И ещё хотели добавить вот что. Наличие одной БД для нескольких микросервисов, которые используют liquibase, приводит к конкуренции за таблицы liquibase при старте приложения и может привести как к замедлению, так и к незапуску. Это в копилку знаний, почему нужно делать отдельные БД :)
Вы правы, все микросервисы должны иметь изолированную базу, и мы идем к этому. До сих пор не перешли, поскольку есть более приоритетные задачи. А также осложнения:
По поводу “может случайно (или намеренно) создать сайдэффекты” – такого с БД не было. В этой плоскости у нас нет проблем.
При разделении монолитного приложения мы прошли несколько этапов. Изначально все Entity базы данных хранились в одном модуле Maven, и была настроена политика обновления схемы на основе изменений Entity классов hibernate.hbm2ddl.auto: update. Когда мы выделили первый микросервис, то сразу столкнулись с проблемой двойного апдейта базы, так как было два приложения, которые на старте пытались инициализировать новую схему БД. Авто-апдейт схемы выключили и перешли на написание скриптов и их запуск при деплое на окружении. Изначально это делалось руками, потом внедрили Liquibase.
Постепенно мы разносили Entity классы по микросервисам, которым они «принадлежат». В текущий момент мы все ещё имеем одну БД, но таблицы в этой БД принадлежат разным микросервисам.
Для записи в БД мы так же используем Hazelcast, то есть мы не пишем в БД напрямую, а бросаем Event на событие, и каждый микросервис (в том числе и тот, который бросил Event) записывает в БД. Это сделано не для всех случаев, но это необходимо, чтобы между микросервисами не было интеграции через БД.
Мы выбрали Hazelcast по нескольким причинам:
Фичи да — пишите актуальные в Release Notes. Кстати, как мы автоматизировали формирование Release Notes, рассказывали вот тут.
Коммуникация привязана не к фичам, а к ключевому функционалу. Поэтому
Поэтому если интересующее нас изменение не случился в этом релизе — значит коммуникация будет ждать того релиза, когда он выйдет.
Спасибо за конструктивный комментарий!
По поводу писем со 100 ченджами, наверное вы имеете ввиду что-то типа Release Notes. Это немножко другое. Release Notes это все же техническая коммуникация для технически-подкованных пользователей. Мы же про то, как объяснить не сильно подвинутому в технологиях ключевому пользователю (кассир, бухгалтер, менеджер…), что в его работе поменялось.
(Плюс не писать про все и сразу нам помогают таргетированные рассылки для пользователей с разными ролями. Технологам — одни, системным администраторам — другие, пользователям — третьи. Ведь каждого из них касается только часть).
Главное помнить, что мы хотим рассказать о ключевых (а в идеале одном ключевом) изменениях, вошедших в релиз, а не обо всех фичах.
Маркетологи здесь могут вам помочь, так как они, во-первых, на это заточены (и тут дело не в рекламе, а в вычленении главного), а во-вторых, человеку, который глубоко включен в проект зачастую это сложно.
Но на наш взгляд идеальная схема выглядит следующим образом — менеджеры проекта готовят драфт, проверяют его на ключевом пользователе, и отдают маркетологам на финальное облагораживание. Понятно, что это требует времени, но ведь для этого релизы и планируются.
Пользователи в домене, но это внешние пользователи, поэтому к себе на винду и в почту они ходят под своими учетками, а доменные учетные записи они используют для того, чтобы ходить в рабочие приложения.
Поскольку Kubernetes для Windows — все еще сомнительная перспектива, мы нацелены на использование Linux.
Ваша новость одновременно и печалит, и радует ;)
Как вы правильно заметили в другом комментарии, заказчик диктует условия, Kerberos не подключен.
Переключалка не выглядит правильным способом решения проблемы. Скорее всего, HttpClient в связке с CurlHandler должен при неудачном Negotiate-запросе пробовать следующий вариант. Скоро закинем вопрос на github.
Проблема в том, что окружение на test/stage/production серверах может сильно отличаться, что ведет к непредсказуемым ошибкам. С контейнерами можно быть уверенным, что если это работает локально, то также будет и на продакшене.
А вообще Хансельман написал отдельную статью, отвечающую на этот вопрос.
В проекте используется минимальное количество функционала IIS, поэтому по поводу расставания с ним у нас не возникло сомнений. При появлении необходимости будем брать фронтенд-сервер в соответствии с условиями. Какую то часть на себя возьмет Kubernetes (например, балансировщик).
По поводу AD — аутентификация происходит во внешнем для нашего решения сервисе, настройкой аутентификации в данном проекте не занимаемся.
Контейнеров будет несколько — основной мобильный сервис, сервис push уведомлений, сервис управлениями баннерами. Как раз про контейнеры подробно напишем в следующих статьях.