https://wikisec.ru/index.php?action=history&feed=atom&title=DevOps 2026-04-14T15:05:07Z История изменений этой страницы в вики MediaWiki 1.34.0 https://wikisec.ru/index.php?title=DevOps&diff=14240&oldid=prev 2020-05-23T12:59:15Z

<p>Новая страница: «&#039;&#039;&#039;DevOps&#039;&#039;&#039; — методология активного взаимодействия специалистов по Разработка программно...»</p> <p><b>Новая страница</b></p><div>&#039;&#039;&#039;DevOps&#039;&#039;&#039; — методология активного взаимодействия специалистов по [[Разработка программного обеспечения|разработке]] со специалистами по [[Техническая поддержка|информационно-технологическому обслуживанию]] и взаимная интеграция их рабочих процессов друг в друга для [[Обеспечение качества|обеспечения качества продукта]]. Предназначена для эффективной организации создания и обновления программных продуктов и услуг. Основана на идее тесной взаимозависимости создания продукта и эксплуатации программного обеспечения, которая прививается команде как культура создания продукта.<br /> <br /> == Общее обозначение ==<br /> Организациям, которым необходимы частые выпуски программного обеспечения, может понадобиться DevOps. Дневной цикл релизов может быть гораздо более интенсивным у организаций, которые выпускают несколько разнонаправленных приложений.<br /> <br /> Методология фокусируется на стандартизации окружений разработки с целью быстрого переноса программного обеспечения через стадии, способствуя быстрому выпуску версий. В идеале, системы [[Автоматизация сборки|автоматизации сборки и выпуска]] должны быть доступны всем разработчикам в любом окружении, и у разработчиков должен быть контроль над окружением, а информационно-технологическая инфраструктура должна становиться более сфокусированной на приложении.<br /> <br /> Задача DevOps-инженеров — сделать процесс разработки и поставки программного обеспечения согласованным с эксплуатацией объединив их в единую команду, что позволяет организовать процессы, которые далее можно автоматизировать с помощью инструментов.<br /> <br /> DevOps-движение возникло в 2009 году и было призвано решить проблемы взаимодействия команд разработки и эксплуатации программных продуктов, в том же году в Бельгии была организована серия конференций «DevOps Days». Затем «DevOps-дни» проходили в различных городах и странах мира.<br /> <br /> == Набор инструментов ==<br /> Поскольку DevOps — это командная работа (между сотрудниками, занимающимися разработкой, операциями и тестированием), нет единого инструмента «DevOps»: это скорее набор (или «инструментальная цепочка DevOps»), состоящий из нескольких инструментов. Как правило, инструменты DevOps вписываются в одну или несколько из этих категорий, что отражает ключевые аспекты разработки и доставки программного обеспечения:<br /> # Code — разработка и анализ кода, инструменты контроля версий, слияние кода;<br /> # Build — инструменты непрерывной интеграции, статус сборки;<br /> # Test — инструменты непрерывного тестирования, которые обеспечивают обратную связь по бизнес-рискам;<br /> # Пакет — репозиторий артефактов, предварительная установка приложения;<br /> # Release — управление изменениями, официальное утверждение выпуска, автоматизация выпуска;<br /> # Конфигурация — Конфигурация и управление инфраструктурой, Инфраструктура как инструменты кода;<br /> # Мониторинг — мониторинг производительности приложений, опыт работы с конечным пользователем.<br /> <br /> Несмотря на то, что доступно множество инструментов, некоторые категории из них имеют особо важное значение в настройке инструментальных средств DevOps для использования в организации. Некоторые попытки идентифицировать эти основные инструменты можно найти в существующей литературе.<br /> <br /> Такие инструменты, как управление контейнеризацией ([[Docker]], [[Kubernetes]]), непрерывной интеграцией ([[Jenkins]], [[GitLab]]), развёртывания сред по шаблону ([[Puppet]], [[Ansible]], [[Terraform]]) и многие другие — часто используются и часто упоминаются в дискуссиях по инструментам DevOps<br /> <br /> == Сравнение с Agile и Continuous delivery ==<br /> [[Agile]] и DevOps похожи, но Agile представляет собой изменение мышления и практики (что должно привести к организационным изменениям), а DevOps уделяет больше внимания внедрению организационных изменений для достижения своих целей.<br /> <br /> Потребность в DevOps рождалась из-за растущей популярности программного обеспечения Agile, поскольку это приводит к увеличению количества выпускаемых версий.<br /> <br /> [[Непрерывная доставка|Continuous delivery]] и DevOps похожи по своим значениям (и часто сочетаются), но они представляют собой две разные концепции:<br /> <br /> DevOps применяется в более широких аспектах и сосредоточен вокруг:<br /> # Организационных изменений: в частности, для поддержки более тесного сотрудничества между различными типами работников, занимающихся поставкой программного обеспечения;<br /> # Разработчиков;<br /> # Операций;<br /> # Гарантии качества;<br /> # Управления;<br /> # Системного администрирования;<br /> # Администрирования базы данных;<br /> # Координаторов<br /> # Автоматизации процессов в поставке программного обеспечения.<br /> <br /> Continuous delivery — это подход к автоматизации аспекта поставки, который фокусируется на:<br /> # Объединении различных процессов;<br /> # Выполнении их быстрее и чаще.<br /> <br /> Они имеют общие конечные цели и часто используются вместе для их достижения. DevOps и Continuous delivery используют гибкие методы: небольшие и быстрые изменения с целенаправленным результатом для конечного клиента.<br /> <br /> == Цели ==<br /> Конкретные цели DevOps охватывают весь процесс поставки программного обеспечения. Они включают:<br /> # Сокращение времени для выхода на рынок;<br /> # Снижение частоты отказов новых релизов;<br /> # Сокращение времени выполнения исправлений;<br /> # Уменьшение количества времени на восстановления (в случае сбоя новой версии или иного отключения текущей системы).<br /> <br /> Методики DevOps делают простые процессы более программируемыми и динамическими. С помощью DevOps можно максимизировать предсказуемость, эффективность, безопасность и ремонтопригодность операционных процессов.<br /> <br /> Интеграция DevOps предназначена для доставки продукта, непрерывного тестирования, тестирования качества, разработки функций и обновлений обслуживания для повышения надежности и безопасности и обеспечения более быстрого цикла разработки и развертывания.<br /> <br /> DevOps дает преимущества в управлении выпуском программного обеспечения для организации путем стандартизации среды разработки. События можно более легко отслеживать, а также разрешать документированные процессы управления и подробные отчеты. Подход DevOps предоставляет разработчикам больше контроля над средой, предоставляя инфраструктуре более ориентированное на приложения понимание.<br /> <br /> == Преимущества DevOps ==<br /> Компании, которые используют DevOps, сообщили о значительных преимуществах, в том числе: значительно сокращении времени выхода на рынок, улучшении удовлетворенности клиентов, улучшении качества продукции, более надежных выпусках, повышении производительности и эффективности, а также увеличении способности создавать правильный продукт путем быстрого экспериментирования.&lt;ref name=&quot;ieeexplore.ieee.org&quot;/&gt;<br /> <br /> Однако, исследование, выпущенное в январе 2017 года компанией «F5 Labs», на основе опроса почти 2200 ИТ-руководителей и специалистов отрасли, показало, что только один из пяти опрошенных полагает, что DevOps оказывает стратегическое влияние на их организацию, несмотря на рост использования. В том же исследовании было установлено, что только 17 % определили DevOps как ключевой инструмент.<br /> <br /> == DevOps и архитектура ==<br /> Чтобы эффективно использовать DevOps, прикладные программы должны соответствовать набору архитектурно значимых требований (ASR), таких как: возможность развертывания, изменяемость, тестируемость и возможности мониторинга.<br /> <br /> Хотя в принципе можно использовать DevOps с любым архитектурным стилем, архитектурный стиль микросервисов становится стандартом для построения постоянно развернутых систем. Поскольку размер каждой услуги невелик, он позволяет создавать архитектуру отдельного сервиса посредством непрерывного рефакторинга, что уменьшает необходимость в большом предварительном дизайне и позволяет выпускать программное обеспечение на ранней стадии непрерывно.<br /> <br /> [[Категория:Определения]]</div>

Wikiadmin