Текущая организация кода и конфигурации, которую вы описываете, структурирована с помощью технических решений. Это плохой дизайн, который добавит много накладных расходов на нашу деятельность по обслуживанию и добавит много ловушек на нашем пути. Вместо этого эта организация должна быть построена вокруг артефактов, которые мы разворачиваем.
Причина этого заключается в том, что мы хотим рассматривать артефакты ( например, образ докера или программный пакет) как объекты следующих глаголов:
- строить
- тестовое задание
- развернуть
рассмотреть минимальный набор автоматизированных задач, которые мы хотим выполнить. Если мы хотим что-то изменить в том, как реализован тестовый глагол, легко посетить папку, соответствующую этому артефакту, в соответствующем репозитории, а затем обнаружить специфичные для jenkins элементы автоматизации, которые необходимо обновить. Вместо этого, если рецепты автоматизации структурированы вокруг технических решений, то нам нужно выяснить, что Дженкинс участвует в процедурах тестирования, и найти там элементы автоматизации, связанные с артефактами. В сложных ситуациях организация вокруг технических решений делает обновления очень трудными, потому что мы должны априори знать все технические решения, вовлеченные в некоторую услугу, чтобы обновить их соответственно.
Например, репозиторий, содержащий код для веб-сайта и микросервис «а», может иметь следующие подкаталоги, предназначенные для операций:
./ops/website
./ops/micro-service-a
каждый из которых имеет три сценария называется build, testи deploy. Теперь, когда организация элементов автоматизации как-то прояснена, давайте обратим наше внимание на конфигурацию.
Основные условия и требования к организации конфигурации устанавливаются deployглаголом при применении к сервисоподобному артефакту. deployГлагол должен иметь следующие параметры:
- версия артефакта для развертывания,
- цель развертывания артефакта, которая описывает конкретную среду, в которой будет развернут развернутый артефакт ( например, кластер и конечные точки, с которыми он должен взаимодействовать)
- учетные данные, которые он должен использовать для подключения к другим конечным точкам ( например, к базам данных)
- конфигурация времени выполнения (например, как долго должны жить записи в кэше и т. д.)
С оперативной точки зрения эта разбивка параметризации соответствует естественным степеням свободы проблемы развертывания - помимо учетных данных, которые могут быть связаны с конфигурацией времени выполнения, но лучше разделить их, чтобы избежать их небрежного распространения.