Pull to refresh

Comments 9

У вас везде упоминается термин IDP, но при этом в качестве примеров вы рассматриваете Azure DevOps и Gitlab, что имхо не совсем верно. На мой взгляд, тут в качестве релевантных примеров правильнее было бы упомянуть про Backstage или Humanitec

Да, вы правы. Часто в качестве удачных реализаций IDP приводятся данные платформы, да и не только эти. Мы, например помимо Humanitec и Backstage изучали и анализировали Port, DevTron и Qovery. И да, все они в первую очередь предназначены для управления инфраструктурой и все что с этим связно. 

Мы сознательно для себя расширили понимание IDP включив туда, по сути, все этапы разработки. В этом плане нам действительно ближе подход Azure DevOps и смежные сервисы Azure (тот же Azure Deployment Environments). На наш взгляд если тот или иной этап разработки реализуется на одном или нескольких компонентах платформы и на базе её процессов, то это как раз и есть Internal Development Platform.

В общем вопрос дискуссионный =)

Если правильно вас поняла, в пассаже про “инструменты и процессы” вы рассматриваете платформу не как инструмент для облегчения разработки, а как средство контроля и ограничения. В компаниях сейчас и так много своих барьеров, а тут предлагается в дополнение навязать еще один?

Не совсем так. Мы проводили и продолжаем проводить исследования среди наших пользователей и уже отчётливо наблюдаем, что зрелость процессов разработки сильно разница от компании к компании. 

Если компания только на старте внедрения или перестройки процессов, то да, на наш взгляд предпочтительнее предложить “коробку”, которая просто не даст возможности ошибиться. По мере роста зрелости и внутренней экспертизы часть таких "искусственных барьеров" можно снять или как-то скорректировать под текущие задачи.

Звучит как попытка сделать из девопсов эникейщиков…

Тут наверно нужно разделить:

1 - Сложно заменить высококвалифицированного специалиста.

2 - Платформа — это больше попытка предоставить инструмент, который позволит специалисту автоматизации сможет поддерживать больше команд. 

3 – Такие механизмы Платформы, как шаблонизация и переиспользование существующих наработок, с одной стороны да, могут показаться попыткой “уменьшить” требования к специалистам, но всё-таки их основная задача – это снизить "нецелевую" нагрузку

Здравствуйте, спасибо за статью! Подскажите, пожалуйста, стоит ли игра свеч для небольшой команды (до 10-15 чел), где есть отдельные команды, представляющие по сути всё то что должно быть в платформе, по отдельности?

Хочется понять, насколько это вообще нужно в таких случаях. Вроде унификация и одна точка входа - это хорошо. Но когда оно уже всё есть где-то отдельно и рулится другими командам (гит и ci/cd, таск трекер, облако с мордой и т.п.), а ты как инженер всего лишь помогаешь разработке чтобы собиралось и деплоилось, кажется весьма избыточным и неприменимым решением маленького командного уровня.

Возможно, это даже риторический вопрос, т.к. в первой части статьи было написано, что idp сейчас внедряют крупные компании. Но может быть у вас уже есть опыт внедрения таких решений в маленьких масштабах)

Если у вас небольшая команда разработки, и используемый инструментарий уже был развернут кем-то и активно применяется, лучше продолжать работать в этой парадигме. Внедрение полноценной IDP (Internal Developer Platform) окупается только на больших масштабах или при использовании SaaS-решений.

Тем не менее, в статье упоминаются коммерческие продукты, которые могут служить основой для создания IDP. Эти решения позволяют начать с небольшой команды и постепенно, по мере роста, масштабировать процесс разработки до уровня полноценной платформы для нескольких команд.

Независимо от наличия IDP, важно стремиться к унифицированному стеку инструментов для управления задачами (таск-трекер), хранения кода (git-сервер), управления пайплайнами (CI/CD) и инфраструктурой (единое облачное решение).

Первые три компонента часто интегрированы в одном продукте - например, в таких как Azure DevOps, GitLab, Github или VK Dev Platform.

Мы рекомендуем строить процесс разработки вокруг одного из подобных комплексных продуктов, чтобы избавиться от фрагментации техстека и прийти к единому базовому решению.

Спасибо за быстрый и развернутый ответ.

Sign up to leave a comment.