Переход на микросервисные архитектуры — тренд современной разработки ПО. Этот метод подразумевает деление сложных приложений на более мелкие сервисы, делая решение быть более масштабируемым и гибким. Как обеспечить конвейер CI/CD в микросервисных архитектурах и в чем отличие этого процесса от монолитных систем?
Отличие монолитных приложений от микросервисных
В статье речь пойдет именно о продуктах. В отличие от проекта, продукт не имеет конечной даты завершения — он постоянно развивается и совершенствуется, чтобы сделать работу и жизнь определенных заинтересованных групп легче за счет автоматизации. Со временем потребности могут изменяться, поэтому важная техническая особенность продукта заключается в его гибкости для наращивания функциональных возможностей. Для этого мы устанавливаем и проверяем гипотезы, то есть предполагаем, как то или иное изменение продукта повлияет на заинтересованные группы, оцениваем это влияние и затем принимаем решение о его внедрении.
«Монолит» представляет собой приложение, где все компоненты находятся внутри одной кодовой базы. Основной плюс монолитов — простота разработки и тестирования. Микросервисные архитектуры имеют другую природу происхождения. Микросервисы необходимы для того, чтобы раздробить функционал на такие блоки, которые можно анализировать без учета сотен взаимосвязей, неизбежно возникающих в крупных информационных системах. И если в монолитных приложениях вся система обновляется разом, то для этих целейв микросервисных приложениях будет работать конвейер CI/CD.
Про конвейер интеграции и доставки (CI/CD) ПО
Напомним, что это такое и какой эффект процессы CI/CD оказывают на бизнес.
Непрерывная интеграция (Continuous Integration, CI) — практика разработки программного обеспечения, которая заключается в постоянном слиянии рабочих копий в общую основную ветвь и выполнении частых автоматизированных сборок проекта.
Непрерывная доставка (Continuous delivery, CD) — это подход к разработке программного обеспечения, при котором ПО производится короткими итерациями, гарантируя, что оно стабильно и может быть передано в эксплуатацию в любое время, а передача его не происходит вручную.
Обычно выделяют несколько показателей, отражающих, насколько эффективно продукт может отреагировать на меняющиеся обстоятельства.
Time to Market (TTM) — ключевой показатель, который отражает временной интервал с момента фиксации идеи до момента запуска продукта на рынок. Также важными показателями являются Lead Time — это TTM, из которого исключен этап исследования и проверки гипотез, а также Cycle Time, который представляет собой только разработку, тестирование и развертывание.
Процесс CI/CD влияет на все измеряемые показатели, в том числе на наиболее важный для бизнеса TTM. Условно говоря, TTM определяет, с какой скоростью те идеи и концепции, которые мы планируем реализовывать в продукте, будут выливаться в конкретные изменения. Например, мы разрабатываем информационную систему, в которой пользователь может оформлять авиауслуги. Чем быстрее возможность оформить новый вид услуги появится в нашем продукте, тем лучше для бизнеса.
Обновления монолитных приложений
Каким же образом мы производили изменения до эпохи микросервисных приложений? Конечно, при разработке любых (монолитных или микросервисных) приложений используется система управления версиями (source control). Это место, где хранится исходный код продукта. Все современные Source Control оперируют понятием «ветки» (branches) и имеют набор инструментов для того, чтобы перенести изменения исходного кода между этими ветками. Также для разработки и развертывания используется набор сред или окружений, где та или иная версия приложения может быть развернута.
Когда у нас были большие монолитные системы, мы тщательно отслеживали версии приложений. Более того, новая версия должна была пройти определенный цикл, в том числе с точки зрения CI/CD. В последнее время стандартом такого цикла являлся gitflow. Это значит, что исходный код версии приложения сначала попадал в dev-ветку, где находился самый низкокачественный код. Обычно проверялась техническая возможность его интеграции (тот самый процесс CI), после этого он мог быть развернут (вручную или автоматически) в dev-среде. Далее, пройдя несколько итераций тестирования/исправления ошибок, код попадал в тестовую (test) ветку, откуда разворачивался в test-среду. И в конце концов код попадал в продуктовую (prod) ветку и соответствующую...