Стратегии продвижения зависимости: разрозненные или организованные?

У нас есть много приложений и веб-сервисов (некоторые общедоступные продукты, некоторые внутренние и часть частного «бэкэнда»), которые взаимозависимы друг от друга. Каждый из этих компонентов имеет 4 среды (кластеры серверов / узлов, обслуживающих определенные цели):

• Непроизводственные
  • DEV- Интегрированная среда разработки, в которой CI создает push-изменения; полезно для инженеров для устранения трудно обнаруживаемых ошибок, которые не воспроизводятся локально
  • QA - Изолированная QA / Среда тестирования
  • DEMO - Стабильная среда UAT для заинтересованных сторон
• производство
  • LIVE - Наша живая / производственная среда

Продвижение кода идет: LOCAL(машина разработчика) => DEV=> QA=> DEMO=> LIVE.

Скажем, у нас есть приложение с myappподдержкой веб-службы RESTful myws, которое само поддерживается базой данных mydb.

В настоящее время у нас есть то, что я бы назвал « организованным » продвижением среди этих зависимостей: myapp-devточки, myws-devкоторые используются mydb-dev. Точно так же myapp-qaуказывает на то, myws-qaчто использует mydb-qa. То же самое для DEMOи LIVE.

Проблема с этим состоит в том , что в любое время я внести изменения, скажем, myappэто требует от меня , чтобы внести изменения в mywsи mydbа. Но поскольку каждая DEVсреда указывает на среды своих зависимостей DEV, это означает, что я должен планировать и развертывать эти изменения одновременно. Кроме того, если одна сборка становится нестабильной / сломанной, она часто приводит к отключению других вышестоящих компонентов; например , если перерывы разработчик что - то при изменении mydb-dev, то myws-devи myapp-devкластеры обычно также становятся нестабильными.

Чтобы решить эту проблему, я собираю предложения для того, что я бы назвал « разрозненной » стратегию продвижения: все межкомпонентными зависимости следовать этим рекомендациям:

• Восходящие зависимости зависят от DEMOсреды для своих последующих зависимостей, для всех их непроизводственных сред ( DEV, QAи DEMO); а также
• Восходящие зависимости зависят от LIVEсреды для их нижестоящих зависимостей для их производственной среды

Используя это соглашение, на myapp-devсамом деле будет указывать myws-demo, что будет использовать mydb-demo. Точно так же myapp-qaбудет также указывать myws-demoи mydb-demo.

Преимущество, которое я могу найти, заключается в стабилизации сборки : гораздо менее вероятно, что DEMOсреда для определенного компонента станет нестабильной, потому что код не сможет этого сделать DEMOбез тщательного тестирования как на, так DEVи на QA.

Единственный недостаток, который я могу найти в этом методе, заключается в том, что, если он DEMOне работает для определенного компонента, все непроизводственные среды для всех зависимых компонентов будут внезапно нарушены. Но я бы возразил, что это должно происходить крайне редко из-за проведенного тестирования DEVи QA.

Это меня проблема , что многие разработчики (гораздо умнее , и опытные , чем я сам) решили, и я не удивлюсь , если эта проблема и ее решение уже имеют название на них (кроме того , что я называю спланированным / разрозненным). Поэтому я спрашиваю: перевешивают ли преимущества стратегии продвинутого продвижения какие-либо недостатки, и какие недостатки я могу пропустить здесь?

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

каждый раз, когда я изменяю, скажем, myapp, это требует от меня внесения изменений также в myws и mydb. Но поскольку каждая среда DEV указывает на среды DEV своих зависимостей, это означает, что я должен планировать и развертывать эти изменения одновременно

Кажется, что «стратегия постепенного продвижения» только усугубит это. Если myapp v2, myws v2 и mydb v2 работают только на DEV, а myapp v2 полагается на mydb v2, чтобы не аварийно завершить работу, то при попытке запустить myapp v2 на DEV я получаю mydb v1 DEMO, и он вылетает. По сути, вам придется либо постоянно перезаписывать хранилища, либо развертывать mydb v2 вплоть до prod, прежде чем вы сможете начать работать над myapp v2. Что еще более важно, вы никогда не будете тестировать mydb v2 на DEV, поэтому, если он сломан, вы даже не узнаете, пока он не сломался на DEMO, и тогда вы вернетесь на круги своя.

В некоторой степени описанная вами проблема неизбежна независимо от того, как настроен ваш рабочий процесс, но ее можно минимизировать. Хитрость заключается в том, чтобы гарантировать, что интерфейс между mydb и myws (и интерфейс между myws и myapp) строго определен и требует , чтобы все обновления этого интерфейса были полностью обратно совместимы . На моей работе у нас есть XML-схема, определяющая интерфейс между нашими приложениями и сервисами, и многие из наших внутренних инструментов просто не позволят нам делать несовместимые обновления этих схем.

Кроме того, если одна сборка становится нестабильной / сломанной, она часто приводит к отключению других вышестоящих компонентов; например, если разработчик что-то ломает при изменении mydb-dev, кластеры myws-dev и myapp-dev обычно также становятся нестабильными.

Это звучит для меня как серьезная проблема, но не проблема развертывания. Разбитая база данных, безусловно, помешает нормальной работе службы и приложения, но они не должны становиться «нестабильными». Они должны возвращать сообщения об ошибках какого-то рода, чтобы любой, кто запускает myapp на dev, видел «Извините, у нашей базы данных сегодня проблемы», а не просто вылетал.

Если проблема заключается в том, что неисправная база данных вообще вызывает эти проблемы, тогда вы можете настроить некую «временную систему», которая позволит вам сказать: «mydb DEV сейчас не работает, пожалуйста, направьте все запросы myws DEV в mydb DEMO для время ". Но это должно быть способом выполнения временных исправлений, пока mydb DEV снова не заработает нормально. Если по умолчанию все «запутано», то вы вернулись к проблемам, которые я описал выше, потому что никто не работает с mydb DEV вообще.

Я чувствую, что, возможно, я каким-то образом неправильно понимаю ваше предложение, но, надеюсь, этот ответ, по крайней мере, прояснит, что было неправильно понято и как лучше перефразировать его.