Я сделал / создал множество презентаций, связанных с SCM, и теперь я пытаюсь «перейти на более раннюю версию».

То, что я всегда пытаюсь сделать в своих презентациях, - это подготовить слайд, который так или иначе включает в себя сообщение, которое я хочу доставить (и которое я затем уточнить в оставшейся части моей презентации). При этом я пытаюсь ответить на свой собственный вопрос, такой как «Что бы я сказал от 1 до 3 фраз, которые я хотел бы использовать, если бы у меня было от 10 до 20 секунд (только!), Чтобы объяснить это кому-то новичку? * ».

Я думал, что знаю, что на самом деле означает DevOps , и о чем он. Но я видел несколько странных случаев использования / контекста DevOps (даже в DevOps.SE ...). Это заставляет меня задуматься, может быть, то, что я считаю DevOps, совершенно неправильно.

Итак, что в целом принято считать определением DevOps?

DevOps в двух словах

Из Википедии :

DevOps ( обрезается соединение из « программного обеспечения DEV elopment » и « информационные технологии О.П. чество S ») это термин , используемый для обозначения набора практик , которые подчеркивают сотрудничество и взаимодействие обоих разработчиков программного обеспечения и информационных технологий (ИТ) специалистов автоматизируя процесс доставки программного обеспечения и изменения инфраструктуры.

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

Из обзора :

Диаграмма Венна, показывающая DevOps как пересечение разработки ( разработка программного обеспечения), операций и обеспечения качества (QA)

Хотя нет единого «инструмента» для DevOps, а есть набор инструментов, также известный как набор инструментов DevOps :

Иллюстрация, показывающая этапы в наборе инструментов DevOps

Иллюстрации DevOps

Ниже приведены несколько цитат из некоторых вопросов DevOps.SE , которые, кажется, как-то соответствуют / подтверждают часть описания DevOps выше:

• От «В чем разница между SRE и DevOps? «:

  ... DevOps - это поддержка кода ...

• От ( ответ на) « Как нанять хорошего DevOps, подходящего моей компании? «:

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

• От « Нужно ли моей организации применять Agile Soft. Девиация до принятия DevOps? «:

  ... все еще есть организации, которые не практикуют Agile в разработке программного обеспечения, и они могут быть заинтересованы во внедрении DevOps ...

DevOps это не роль

Ниже приведены несколько цитат из некоторых вопросов DevOps.SE , которые, похоже, иллюстрируют, что DevOps НЕ является ролью:

• От ( ответ на) «В чем разница между Sysadmin и DevOps Engineer? «:

  ... DevOps - это не роль (при использовании как таковое это скорее модное слово, чем реальная роль).

• От ( ответ на) « Как нанять хорошего DevOps, подходящего моей компании? «:

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

Я практиковал и консультировал DevOps в качестве консультанта с различными клиентами уже почти пять лет, до того, как занимать мою нынешнюю должность, я занимал должности в разработке программного обеспечения, веб-операциях и системном администрировании. По моему личному опыту DevOps поставляется во многих вкусах.

Организационные шаблоны

DevOps Antipatterns:

• NoOps и NoDevs - не строго DevOps в самом строгом смысле, однако, эти команды создают и эксплуатируют программное обеспечение без разделительной линии между разработкой и эксплуатацией. Проблемы с этими командами сводятся к зрелости, команды разработчиков могут быть опытными разработчиками программного обеспечения, но начинающими операторами и наоборот.

• Мост DevOps - здесь одна или несколько команд несут ответственность за то, чтобы брать работу от команд разработчиков и « производить » ее, чтобы сделать ее работоспособной. Задача сводится к тому, что теперь есть две передачи: Разработка → DevOps и DevOps → Операции.

• Команда DevOps - это, возможно, может сработать, если команда несет ответственность за создание инструментов, поддерживающих операционную модель с поддержкой DevOps, однако ее, вероятно, следует называть «Команда инструментов» или «Команда платформы».

Шаблоны DevOps:

• Внедренные DevOps - чаще называемые Platform Engineering, в рамках которых в команде есть кто-то, кто несет ответственность, но не несет ответственности за предоставление автоматизации, инструментов и инфраструктуры для предоставления и развертывания решения, иногда также включая управление программным обеспечением. Это последнее, что на самом деле является представителем DevOps.

• Институционализированные DevOps - когда проектная команда совместно отвечает как за разработку, так и за эксплуатацию программного пакета, создающего общую собственность и циклы положительной обратной связи.

практика

Фактическая практика DevOps основана на нескольких других практиках, а именно:

• Проворная Доставка
• Непрерывная интеграция
• Непрерывная доставка
• Непрерывное развертывание

Каждая из перечисленных выше практик основывается на другой, однако можно не следовать этой практике, однако это означает, что отсутствует важный цикл обратной связи, который может указывать на «упущенную возможность». Ключевым отличием между выполнением любой другой практики и DevOps является работа программного обеспечения в производстве .

Три Пути

В проекте «Феникс» Джин Ким и его соавторы описывают три способа DevOps :

Системное мышление

Первый способ подчеркивает производительность всей системы, а не производительность отдельного бункера работы или отдела - это может быть как большое подразделение (например, разработка или ИТ-операции) или так же мало, как отдельный участник (например, , разработчик, системный администратор).

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

Усиление петель обратной связи

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

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

Культура непрерывных экспериментов и обучения

Третий путь заключается в создании культуры, которая поощряет две вещи: постоянные эксперименты, риск и обучение на неудачах; и понимание того, что повторение и практика являются предпосылкой для овладения.

Это очень вписывается в культурное пространство, хотя в значительной степени зависит от инструментов и процессов, позволяющих культуре расти.

Я слышал много разных определений DevOps. Они включают:

• Разработчики, занимающиеся операционными задачами
• Один человек выполняет вдвое больше работы (за то же время)
• Разработчики и рабочие команды работают друг с другом
• Операции работы для разработчика инструментов (в духе "Web Ops")
• Название работы для тех, кто создает и поддерживает инструментарий разработчика
• Использование автоматизации в операциях
• Использование публичных облаков в операциях
• Работа, которая сочетает в себе аспекты операций, развития и обеспечения качества
• Работа, которая влечет за собой необходимость совместной работы команд разработчиков и разработчиков.
• Философия разрушения барьеров между командами
• Обработка инфраструктуры как кода
• Что вы получите, когда бывшие инженеры-программисты начнут работу
• Абсолютно бессмысленное модное слово

Там нет общественного консенсуса относительно того, что DevOps на самом деле является . Несколько лет назад у нас были похожие проблемы с «Agile», и это имеет письменное определение .

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

Определение, которое я всегда использую в этой ситуации, следующее:

«Культура создания программного обеспечения, которая подчеркивает связь и сотрудничество между разработчиками программного обеспечения и рабочими группами, одновременно автоматизируя процесс доставки программного обеспечения и изменения инфраструктуры. Цель DevOps - сделать процесс создания, тестирования и развертывания программного обеспечения максимально частым, быстрым и максимально возможным ».

Однако, наряду с определением, также важно, чтобы они понимали ПОЧЕМУ нам нужны DevOps. Обязательно сообщите им, что DevOps быстрее устраняет дефекты программного обеспечения, обеспечивает лучшее управление ресурсами, меньше человеческих ошибок, лучший контроль версий, стабильную операционную среду и т. Д.

В следующем научном исследовании, посвященном именно этому вопросу «Что такое DevOps», предлагается следующее производное определение DevOps:

DevOps - это методология разработки, нацеленная на преодоление разрыва между разработкой (Dev) и эксплуатацией (Ops), с акцентом на коммуникацию и сотрудничество, постоянную интеграцию, обеспечение качества и доставку с автоматическим развертыванием с использованием набора методов разработки.

[Джаббари и др.] «Что такое DevOps ?: Систематическое картографическое исследование определений и практик» (2016)

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

Главной целью всегда должно быть предоставление возможности лицам, принимающим решения, стать лицами, принимающими решения . Представьте себе мобильное приложение вашего банка. Когда вы запрашиваете перевод, это происходит, когда вы нажимаете кнопку. Вы приняли решение, а затем приняли решение. То же самое с вашими операциями. Когда соответствующий человек решит, что какая-то работа готова к развертыванию в производстве, он должен нажать кнопку и произойдет «Правильное дело». Точно так же они должны иметь всю необходимую информацию, необходимую для принятия правильных деловых решений.

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