Нужно очень сильно отстать от жизни (примерно лет на 5-7, что по нынешним временам приравнивается к вечности), либо иметь крайне веские аргументы, чтобы не использовать для доставки готового кода до среды эксплуатации конвейер развёртывания (в народе часто именуемый конвейером CI/CD, что в данном случае непринципиально).
Техническая сторона вопроса – как построить конвейер – в большинстве случаев понятна, если не очевидна. Инструментов море, идеология ясна, собрать конвейер можно в простых случаях за час, в сложных – за пару недель.
Организационная же сторона вопроса не так проста, как кажется. Кто должен/может его создать? Кто обеспечит функционирование? Кто починит, когда сломается? Кто будет его постоянно улучшать, когда требуется? Кто очередной раз придумает, как сделать, чтобы он работал ещё быстрее? Кажется, что вопросов много, но, похоже, он один – кто отвечает за конвейер развёртывания?
Жизнь (иногда ещё говорят – опыт) подсказывает следующие возможные варианты ответов для средних и крупных предприятий:
- Никто
- Специальный отдел создания и обеспечения работоспособности конвейеров
- Отдел администрирования ИТ-систем
- Один из центров компетенции по технологиям (пригодно для матричной структуры)
- Специальный человек внутри продуктовой команды
- Вся продуктовая команда
Рассмотрим эти варианты.
Первый отметаем сразу: при том, что встречается он с завидной регулярностью (то есть – может показывать текущий уровень зрелости разработки ПО), вряд ли можно его считать целевым состоянием.
Второй вариант (спец.отдел) вполне возможен для случаев, когда, к примеру, над изменением ИТ-ландшафта трудятся несколько десятков очень схожих между собой команд, как по применяемым технологиям, так и по структуре собственно команд. Преимущество варианта – экономия ресурсов и стремительный рост компетенции именно в деле построения конвейеров. Недостаток – организационное разграничение ответственности в вопросе, который сильно влияет на качество и скорость работы команд; такое разграничение создаёт очередной административный барьер, а значит – замедляет и снижает качество.
Третий вариант (отдел администрирования), казалось бы, не отличается от предыдущего – речь всё ещё про отдельное структурное подразделение. Ан нет, существенное отличие есть. В предыдущем варианте мы имеем отдельное разделяемое между командами подразделение, в этом варианте таким подразделением является блок эксплуатации. Недостаток, связанный с построением административного барьера, становится слишком негативным, ведь мы таким образом разрушаем всю идею DevOps: Ops не должен быть отдельно от Dev.
Четвёртый вариант (один из центров компетенций) может быть вполне рабочим для случаев, когда применяемых технологий не очень много. В матричной структуре центр компетенций обеспечивает количество и качество ресурса (простите за цинизм), а также технологическую поддержку. Построение конвейера – один из технологических вопросов, который может находиться в зоне ответственности центра компетенций. Например, для web-технологий конвейеры строятся одним образом, а для, простите, 1С – другим.
Пятый вариант (один из участников продуктовой команды) похож на первый в том смысле, что он вполне может быть текущим состоянием, но вряд ли – целевым. Нам не интересно, чтобы один мегаэксперт в команде знал, как устроен наш конвейер. Нам нужно, чтобы это знание было общим, и ответственность за работу в целом, и за скорость работы в частности, была общей.
Наконец, за последний вариант (вся команда) будут агитировать все международные эксперты вместе со всемирным разумом: команда, скажут они, должна сама отвечать за свои инструменты. И быть самоорганизующейся. И все внутри – взаимозаменяемыми, T-shaped, вот это вот всё. Спору нет, красивая картинка, плюсов в ней много.
Мне же представляется, что всё чуть-чуть интереснее. Помните, в самом начале при постановке вопроса, я сделал оговорку – для средних и крупных предприятий? Это важный момент. Представим, что у нас трудится под сотню продуктовых команд. Предположим, что текущее состояние, как у многих, плачевно – где-то что-то есть, но на скоростные конвейеры похоже не очень, словосочетание Continouos Integration всеми произносится, но мало кем понимается, а за слова Trunk based development разработчики готовы вступать в драку. В таком случае тратить время на отдельное построение конвейеров в каждой команде нерационально. Хуже того, эта дорога никогда не будет пройдена. Можно год заниматься агитацией и пропагандой здорового образа жизни, но вот вести этот самый здоровый образ через год будет лишь десяток команд, но не все, и даже не большинство (что любопытно – заявлять “у нас всё уже давно есть” будут, наверное, почти все; см. эффект Даннинга-Крюгера).
Более перспективным вариантом является комбинация 4 и 6: центр компетенций отвечает за идеологию, обучение, устранение технических ограничений и создание шаблонов конвейеров, а продуктовые команды отвечают за “экземпляры” конвейеров, которые они применяют. Центры компетенций смогут и объяснить что такое хорошо, и помочь это хорошо получить (и даже – проконтролировать), а команды берут на себя полную ответственность с помощью привнесённой компетенции теперь делать дело, и делать его правильным образом.
При таком раскладе счастье в вопросе конвейеров развёртывания может быть достигнуто в разумной временной перспективе.
Но это, разумеется, не конец истории. Всё становится ещё интереснее, когда и если структура изменится от component based teams в сторону feature based teams. Почему интереснее и как с этим быть мы рассмотрим как-нибудь в следующий раз. А пока приглашаю всех, дочитавших до этого места, на наш учебный курс “Основы DevOps“, на котором мы обсуждаем ровно такие управленческие вопросы.
