Автор: Баз Дейкстра (Bas Dijkstra) Оригинал статьи Перевод: Ольга Алифанова
В этой серии статей вы столкнетесь с выдуманным, но реалистичным сценарием использования контрактного тестирования с Pact и Pactflow.
За последние примерно десять лет архитектура программных систем перешла от монолитной к сервисно-ориентированной, а затем – к сильно распределенной и зачастую основанной на микросервисах. В прошлом команда или отдел отвечали за разработку и поставку системы целиком, а сейчас эта ответственность зачастую распределена между разными командами, работающими на разные отделы и зачастую – на разные компании.
Этот распределенный подход к разработке ПО имеет ряд существенных преимуществ, особенно в плане гибкости и масштабируемости:
Деплой новой версии компонента или его замена на более подходящий вариант не требует деплоя системы целиком.
Если над разными компонентами единой системы работают разные команды, разработку можно вести параллельно, что сильно ускоряет процесс.
Если компонент должен управляться с множеством запросов, его можно масштабировать, не масштабируя остальные компоненты.
Помимо этих, есть и другие плюсы. Однако этот подход к разработке несет и проблемы, особенно в интеграции и end-to-end тестировании. Чтобы пристальнее взглянуть на эти проблемы и пути их решения, возьмем для примера приложение, состоящие из нескольких неплотно связанных компонентов.
