Есть огромное количество статей на тему Continuous Integration, Continuous Delivery и прочих мастхэв практик современной разработки, и почти везде рекомендуют начинать с CI. С этим нет проблем, когда система только начинает разрабатываться, но что если система уже существующая? План действий обычно выглядит так: Надо бы начать -> ??? -> Профит (все, что там пишут про Netflix, Amazon и Google). То есть внедрение CI начинается без предварительной подготовки системы, при таком подходе накладные расходы только увеличиваются, а не снижаются как ожидалось.
Но что это за предварительная подготовка?
Чтобы ответить на этот вопрос, необходимо составить список шагов, которые необходимо сделать, чтобы развернуть новый контур системы. Тут сразу станет понятно, какие зависимости есть у системы и какие из них сильные (tight coupling). Чтобы двигаться дальше, с сильными связями придется что-то сделать, либо превратить в слабые связи (предпочтительно), либо как-то обыграть сильную связь, чтобы она перестала мешать.
Предлагаю разобраться, что есть сильная и слабая связи. Давайте посмотрим на зарядное устройство телефона. Есть зарядники, где блок питания и провод это единое целое, такое устройство можно использовать только для зарядки устройств с подходящим к проводу разъемом - это пример сильной связи. В большинстве современных зарядников провод соединяется с блоком питания через USB-порт, что позволяет менять провода в зависимости от устройства, которое хотим зарядить, а еще можно отсоединить провод и заряжать телефон от компьютера или использовать его для передачи данных - это пример слабой связи.
Уход от сильной связи к слабой не только делает дизайн системы лучше, но и является важным условием для внедрения DevOps практик. Когда у системы много сильных связей, хорошо, если есть хотя бы один контур, в котором можно запускать тесты в процессе CI, но в этом же контуре работают пользователи, проверяющие функционал и ручные тестировщики. Получается, что мы либо будем мешать пользователям тестового контура, постоянно что-то устанавливая на стенд, либо НЕ можем запускать CI пайплайн когда это требует процесс разработки, что существенно увеличивает время получения обратной связи и снижает пользу от использования CI.
Что же делать?
Уменьшать количество сильных связей у системы. К сожалению, это легче сказать, чем сделать. Вероятнее всего придется писать код и возможно даже переделать часть системы. Именно поэтому простое добавление инженеров по автоматизации не решает поставленную задачу.
Нужно стремиться к тому, чтобы новый контур системы мог развертываться по требованию в течении минут (в крайнем случае десятков минут). Возьмите свою систему и создайте ей абсолютно пустую базу данных. Запустите ее на пустой базе. Запишите на бумажку все грабли, которые пришлось собрать в процессе запуска. А теперь заскриптуйте все это, начиная с создания чистой базы. Первый шаг к CI выполнен. Теперь вы знаете все сильные связи без которых ваша система даже не запускается "с нуля". А что делать дальше - поговорим в следующей серии. Оставайтесь на связи!