• К чему можно оказаться не готовым, став тим-лидом
    +1
    это жуткое ощущение практической бесполезности всей этой работы: когда ты весь день занят тысячей мелких проблем а к вечеру кажется, что не успел фактически ничего.


    Самое тяжелое при этом потом распределять затраченное время если работаешь на почасовой оплате…
  • Каждой ветке по хосту c помощью capistrano
    0
    Почти год назад описывал работу по подобной схеме, только акцентировал внимание на самом подходе, а не на реализации.
  • Плюсы микросервисной архитектуры
    0
    Отлично! Тогда с нетерпением жду продолжения. Если надо будет материала подкинуть, обращайтесь. Могу еще своего опыта добавить. У нас проект специфичный: hiload, bigdata и все такое…
  • Плюсы микросервисной архитектуры
    0
    > 1. При дроблении приложения на много маленьких возрастает дублирование кода. Есть код, который должен быть в каждом проиложении (те же модели ORM) и описывать их придется везде отдельно.

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

    > 2. Усложняется деплой. При изменении схемы бд, мне скорее всего придется обновить не одно приложение, а все пять. Это, конечно, автоматизируется. Но сам факт.

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

    > 3. Накладные расходы на общение сервисов между собой. Если взять из примера сервисы, общающиеся между собой через rest. Получается вместо прямого вызова нужного кода, мне надо будет делать http запросы и терпеть сетевые задержки.

    Это один из наиболее ощутимых минусов который мы ощутили на своем проект. Но мы его решили разработкой своей серверной и клиентской либы с прямым сокетным соединением.
  • Плюсы микросервисной архитектуры
    0
    Очень много сказано о плюсах, но минусы же тоже имеются. Почему о них ни слова?
    Можете рассказать на какие грабли вы наткнулись и как решали?
  • Оптимизируем рабочий процесс
    0
    Для этого git должен уметь обращаться по api к CI. Не везде есть интеграция c api конкретного используемого CI. Придется писать дополнительный промежуточный скрипт. А вот мониторинг репозитория есть почти в каждом CI. Поэтому просто идем от того что проще.
  • Оптимизируем рабочий процесс
    0
    Git flow это только идеология ведения git'а. Не спорю что здесь он присутствует, но акцент на связке с другими инструментами.
  • Оптимизируем рабочий процесс
    0
    А представьте себе разработчика, которому надо помимо написания кода, написать о том что сделал в таске, запустить тесты, написать тестировщику что можно проверять, самому задеплоить, зайти еще на какой-нибудь сервис поставить там галочку, зайти еще в одно место чтобы указать время затраченное на задачу и т.д. В некоторых случаях список можно продолжать и продолжать. Чем больше используется инструментов, тем больше разработчику приходится отвлекаться от работы, тем чаще подстраиваться под разные интерфейсы, и как пример, тем дольше вводить в курс дела нового сотрудника.

    Не просто так большинство сервисов стремятся к принципу «все в одном».
  • Оптимизируем рабочий процесс
    –1
    Не спорю, нужен. Надеюсь в скорое время будет.
  • Оптимизируем рабочий процесс
    –1
    Суть в том что надо рассматривать staging именно как будущий master и вести его так что бы его в любой необходимый момент можно было выкатить. Если на master'е проводить тесты, то они будут полностью дублировать тесты со staging'а. Это может очень сильно увеличить время деплоя. В нашем случае master служит только как метка для понимания того что сейчас на продакшене. Таким образом важной веткой за которой действительно надо следить становится staging.
  • Оптимизируем рабочий процесс
    –1
    если с таском есть проблемы то он откатывается из staging и доделывается в своей ветке. при необходимости staging можно смержить в ветку таска для воспроизведения проблемы.
  • Оптимизируем рабочий процесс
    –1
    Критичными ситуациями я называю те в которых нет времени на долгие тесты. Быстрые тесты в любом случае пройдут, а долгие пойдут параллельно с деплоем при мерже ветки master в staging.

    Если проблема не критичная, но и до конца спринта ждать не может, то фикс проходит через staging и деплоится вместе с тем что уже накопилось за часть спринта.
  • Оптимизируем рабочий процесс
    0
    Можно и теги, но откатываем не так часто, поэтому нет смысла давать каждому релизу имя когда обычно нужно откатить не больше 1-2 мержей.
  • Оптимизируем рабочий процесс
    +1
    Если срочно, то через capistrano делается rollback. В остальных случаях откатывается мерж коммит. Все мержи мы делаем с ключом --no-ff, поэтому они в истории в виде отдельного коммита, который можно дотаточно быстро откатить.
  • Оптимизируем рабочий процесс
    –1
    Конечно любые правила не без исключений. Совсем в критичных ситуациях таск мержится в master минуя staging. После чего master сразу мержится в staging, про прогона тестов и для актуализации ветки. Такие случаи бывали, но в большинстве случаев мы все же решаем делать откат релиза и в течении спринта без аврала фиксим. Спринты у нас короткие всего 1 неделя, поэтому обновляем небольшими порциями и фиксы приходят быстро.

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