Порекомендуйте систему управления зависимостями для микросервисов



Порекомендуйте, пожалуйста, (если такое вообще существует) систему управления зависимостями для микросервисов.Задача следующая: есть продуктовые задачи, которые бьются на задачи в конкретных сервисах, разработка продуктовых задач ведется параллельно, в отдельных feature-бранчах (разные стеки технологий).К примеру, задача №1 требует веток (A1, B1, C1), назовём это "конфигурация №1", задача №2 - (A2, C2, X2) (конфигурация №2). Хочется уметь (к примеру) разложить конфигурации №1 в один клик на тест-окружении, а для конфигурации №2 указать, что она не может быть разложена раньше первой. В идеале для конфигураций хотелось бы видеть некий spec-файл, в котором можно было бы указывать pre-/post-условия, зависимости и т.д.Понятно, что единой silver bullet может не существовать, поэтому с радостью приму любые идеи (программные, т.к. процессные достаточно очевидны), которые помогут сократить количество велосипедов.
836   21  

Comments

  1. Виктор Комаров
    Виктор Комаров 5 лет назад
    &gt;&gt; К примеру, задача №1 требует веток (A1, B1, C1), назовём это "конфигурация №1", задача №2 - (A2, C2, X2) (конфигурация №2). - но это же ад <img height="16" width="16" alt="🙁" src="https://static.xx.fbcdn.net/images/emoji.php/v9/tcb/1/16/1f641.png">
    • Алексей Паршуков
      Алексей Паршуков 5 лет назад
      Согласен. Это ад. Так не надо делать. Тестировать и выкладывать по очереди. А вообще не должно быть таких трешовых зависимостей. Это убивает идею микросервисов. Проще уже монолит делать.
  2. Михаил Буйлов
    Михаил Буйлов 5 лет назад
    А какие програмные идеи вас конкретно интересуют? Мы за долгие годы пришли к тому, что задачи должны быть максимально независимы друг от друга. если есть ряд задач, которые зависят друг от друга - то это одна задача, которая выполняется итерациями. Как уже выше написали - очень просто схватить кольцевые зависимости. А при независимости задач, их можно деплоить тупо автомержем
  3. Мага Абдурахманов
    Мага Абдурахманов 5 лет назад
    Kubernet Resources, docker-compose
    • Andrey Shetukhin
      Andrey Shetukhin 5 лет назад
      Эээ, и что?
    • Андрей Синицын
      Андрей Синицын 5 лет назад
      Ну без композа мы обошлись, а вот на кубере сделали ровно то решение, которое хочет топикстартер. Но оно не в паблик и вообще(
  4. Алексей Никулин
    Алексей Никулин 5 лет назад
    &gt;задача №1 требует веток (A1, B1, C1)
  5. Evgeny Rozaliev
    Evgeny Rozaliev 5 лет назад
    Не юзать ветки вообще, подумать в сторону фича флагов. Разделить процесс деплоймента приложений и выкатки фич. https://trunkbaseddevelopment.com/feature-flags/
    • Пётр Прокунин
      Пётр Прокунин 5 лет назад
      Да, спасибо, я именно это и рассматривал как альтернативу.
  6. Alibek Amaev
    Alibek Amaev 5 лет назад
    Микросервис должен:* уметь анонсировать себя, свои функции и очереди, конфигурацию;* ждать изменений конфигураций, поступления данных, поступления запросов;* подписываться на требующиеся очереди;* запрашивать список требуемых ему внешних функций и адреса по которым можно вызывать внешние функции у брокера (очередей и/или конфигураций);
  7. Andrey Shetukhin
    Andrey Shetukhin 5 лет назад
    Это было мощно.
    • Макс Лапшин
      Макс Лапшин 5 лет назад
      мне вот тоже что-то такое кажется.
    • Пётр Прокунин
      Пётр Прокунин 5 лет назад
      Макс Лапшин спасибо, я просто пытался дешево и сердито решить проблему с legacy. Видимо, действительно лучше сразу замахиваться на фича-флаги и полную независимость.
    • Макс Лапшин
      Макс Лапшин 5 лет назад
      Пётр Прокунин возможно не фича флаги, а какие-то прокси, которые раздают немного разное.
  8. Юрий Насретдинов
    Юрий Насретдинов 5 лет назад
    Я лично из описания нихрена не понял, из чего делаю вывод, что проблема не техническая, а организационная. В маленькой команде надо не выпендриваться и пилить монолит и не слушать всяких крикунов. Если команда действительно большая (от 100 человек, я бы сказал), то уже можно делить, но обычно там деление уже итак понятно, хотя бы исходя из уже существующего деления команд. Но даже тогда сложности при координации между командами должно быть не очень много. Просто один человек/отдел должен быть, который отвечает за релизы, и не будет проблем с зависимостями.
    • Andrey Shetukhin
      Andrey Shetukhin 5 лет назад
      Можно и без специального отдела. Контракт на API, наличие mock-сервисов и график выкатки фич решают проблему.
    • Андрей Синицын
      Андрей Синицын 5 лет назад
      И еще объяснить всем, кто должен писать моки)
  9. Andrey Shetukhin
    Andrey Shetukhin 5 лет назад
    &gt;В идеале для конфигураций хотелось бы видеть некий spec-файл, в котором можно было бы указывать pre-/post-условия, зависимости и т.д.
  10. Станислав Осипов
    Станислав Осипов 5 лет назад
    Юрий Насретдинов, от вас слишком много эмоций и слишком мало дела в треде. Человек задал абсолютно нормальный вопрос, я сейчас работаю над тем же самым - пишу велосипед. Топикстартеру я бы посоветовал посмотреть на Concourse CI
    • Пётр Прокунин
      Пётр Прокунин 5 лет назад
      Спасибо! Посмотрю.
    • Андрей Синицын
      Андрей Синицын 5 лет назад
      Ну как по мне, то Юра все по теме сказал. Задача решается техническими средствами, но лучше ее решать на уровне процессов