Что такое «ходячий скелет»?

Одна из моих гибких команд выбрала интересный подход на ранних этапах своего проекта. Вместо того, чтобы начинать проект со Sprint 0, где они настраивают инфраструктуру кода и выбирают архитектуру решения, они начали создавать «Ходячий скелет», который они описывают как практику DevOps.

Кажется, что это сводится к созданию чего-то очень маленького (в случае API с единственной конечной точкой, которая только что возвращается 200-OK), получению этой работы в непрерывной интеграции и построению конвейера непрерывной доставки для развертывания этого в каждой из сред:

Разработка ► Испытания ► UAT ► Подготовка производства ► Производство

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

У меня такой вопрос: что такое «Ходячий скелет» и какую выгоду он дает гибкой команде, следуя практикам DevOps?

terminology patterns practices

— Ричард Слейтер
источник

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

— Tensibai

«Ходячий скелет» - это форма «доказательства концепции» вашей основной архитектурной концепции. Там, где подтверждение концепции обычно фокусируется больше на одной функциональности, «Прогулочный скелет» - это минималистичная сквозная реализация. «Ходячий скелет» - это не набросок вашей концепции (только «скелет»), а действительно исполняемый и переносимый (он может «ходить»: O) и должен сопровождаться тестами.

Алистер Кокберн описал это (и его часто цитируют):

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

Преимущество DevOps заключается в том, что «Walking Skeleton» должен быть разработан в самом начале проекта, и в результате получается работающий, отправляемый и тестируемый код . Таким образом, DevOps может создать полную непрерывную цепочку интеграции в начале проекта, вместо того, чтобы быть включенным в финальную фазу проектов. Это означает, что любые проблемы, которые могут возникнуть, также решаются на ранней стадии, а не в спешном режиме в конце.

— 7ochem
источник

Ну, это не просто цепочка CI, но она может буквально охватить весь конвейер производства, включая доставку и развертывание. Скелет этого , а также - вам не нужно иметь все ОК проверки для конечного продукта в месте на 1 день, вы можете постепенно добавить проверку «мясо» к этому скелету , как история «мясо» накапливается на ходячий скелет.

— Дан

Мне нравится термин «мясо», он очень хорошо вписывается в используемую терминологию: P

— 7ochem

Отличный ответ. Я предполагаю, что это трубопроводный эквивалент минимального жизнеспособного продукта.

— Адриан

Это звучит похоже на минимально жизнеспособный продукт, но на более детальном уровне - возможно, «минимально жизнеспособный компонент». Возвращение 200 из службы только для того, чтобы она «заработала», звучит для меня как заглушка.

— Дейв Сверски,