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

42

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

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

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

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

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

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

Ответы:

38

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

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

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

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

7ochem
источник
4
Ну, это не просто цепочка CI, но она может буквально охватить весь конвейер производства, включая доставку и развертывание. Скелет этого , а также - вам не нужно иметь все ОК проверки для конечного продукта в месте на 1 день, вы можете постепенно добавить проверку «мясо» к этому скелету , как история «мясо» накапливается на ходячий скелет.
Дан
1
Мне нравится термин «мясо», он очень хорошо вписывается в используемую терминологию: P
7ochem
3
Отличный ответ. Я предполагаю, что это трубопроводный эквивалент минимального жизнеспособного продукта.
Адриан
4
Это звучит похоже на минимально жизнеспособный продукт, но на более детальном уровне - возможно, «минимально жизнеспособный компонент». Возвращение 200 из службы только для того, чтобы она «заработала», звучит для меня как заглушка.
Дейв Сверски,