Блог

Дмитрий Денисов
Заместитель директора по информационным технологиям

Специфика интеграционных задач

В холдинге «Актион-МЦФЭР» существует несколько крупных линеек интернет-продуктов. Это так называемые профильные сайты (самый яркий пример: ­ www.glavbukh.ru), электронные журналы (например, e.glavbukh.ru) и справочные системы (например, www.1gl.ru).

Так исторически сложилось, что каждая из этих линеек разрабатывается на своих технологиях, разными командами, по разным процессам. Одна из команд даже в отдельном от остальных офисе сидит.

Но в последнее время все чаще возникают задачи по интеграции систем из разных линеек.

В простейшем случае – для обмена контентом. В чуть более сложном – на одних сайтах использовать функционал других. Или в совсем сложном – интегрировать самостоятельные системы аутентификации и авторизации, чтобы на любом сайте холдинга Пользователь мог находиться со своей родной учеткой, независимо от того, где он ее получил. Но при этом все равно оставить системы аутентификации и авторизации раздельными, так как за многие годы самобытного развития они обросли гигантским объемом функционала, интегрировать который, во-первых, видится слишком дорогим, а во-вторых, не очень-то и нужно.

Работая над такими задачами, команды разработки постоянно сталкиваются с новыми для себя вызовами.

Одно, когда продукт делается одним разработчиком или очень маленькой (2–3 человека) командой. Легко ездить на автомобиле по пустому аэродрому.

Совсем другое, когда в интеграционную задачу вовлечено сразу 2–3 команды, и количество непосредственно занятых на задаче участников (разработчиков, тестировщиков, менеджеров) возрастает до 5–8. Вместо пустого аэродрома мы оказываемся в оживленном трафике крупного города, и для вождения автомобиля нужно уже гораздо больше навыков.

Чему мы учимся, работая на интеграционных проектах:

  1. Работа над задачей должна планироваться совместно участниками всех команд. Ну или хотя бы менеджерами от каждой команды. Минимум, о чем нужно договориться на старте, – это ключевые вехи совместного проекта.
  2. Если команды не набрали достаточного опыта совместной работы, для мало-мальски сложной задачи нужно обязательно выделять фазу проектирования. Во время нее команды должны решить как инфраструктурные вопросы (адреса сервисов, интерфейсы, протоколы и т. д.), так и договориться о водоразделах: изолировать модули, разграничить зоны ответственности. Рисовать ли при этом диаграммы или ограничиться словесными описаниями – зависит от традиций и привычек каждой команды. 
  3. Отдельно проговаривается предсказуемая работа (или предсказуемая неработа) функционала в случае, если отвалилась любая из точек интеграции.
  4. Команды могут жить по своим расписаниям, в разные сроки внедрять системы в продакшен. Необходимо явно определить, кто, кого и где ждет. Ждущая сторона должна озаботиться необходимым набором заглушек на время ожидания.
  5. Тестирование. Неправильно, когда каждая команда тестирует только свой кусок. Обязательно должны быть тесты на полный сценарий, задействующий всех участников.
  6. Совместный разбор проблем. Команды должны заранее договориться, к кому первому идет заказчик, когда у него что-то не работает, и по какой цепочке выполняются дальнейшие проверки. Заявить «проблема не на моей стороне» в этой ситуации мало. Это нужно еще и доказать.

Ну и наконец, иногда случается, что для какого-то суперкритичного сценария использования правильнее разработать функционал самостоятельно. Даже если у соседа уже есть почти такой же.