24 июля 2020
Что такое DevOps и какие проблемы он решает?
7 основополагающих концепций
DevOps стал перегруженным модным словом, которое многие люди толкуют по-разному. Вместо того, чтобы пытаться дать определение DevOps, мы собираемся описать основные концепции, которые разные люди связывают с DevOps, и историю развития движения DevOps, чтобы помочь вам получить целостное представление.
Хотите понять, что такое DevOps? Вот семь основополагающих концепций, которые вы должны знать!
DevOps стал перегруженным модным словом, которое многие люди толкуют по-разному. Вместо того, чтобы пытаться дать определение DevOps, мы собираемся описать основные концепции, которые разные люди связывают с DevOps, и историю развития движения DevOps, чтобы помочь вам получить целостное представление:
1. Откуда пришел DevOps?
DevOps – это потомок гибкой разработки программного обеспечения, рожденный необходимостью идти в ногу с возросшей скоростью программного обеспечения и достигаемыми гибкими методами . Достижения в гибкой культуре и методах за последнее десятилетие выявили необходимость более целостного подхода к сквозному жизненному циклу доставки программного обеспечения.
Что такое гибкая разработка программного обеспечения?
Agile Development - это общий термин для нескольких итеративных и дополнительных методологий разработки программного обеспечения. Наиболее популярные гибкие методологии включают Scrum, Kanban, Scaled Agile Framework® (SAFe®), Lean Development и Extreme Programming (XP).
Хотя каждая из гибких методологий уникальна в своем конкретном подходе, все они имеют общее видение и основные ценности (см. Agile Manifesto). Все они в основном включают в себя итерацию и непрерывную обратную связь, которую он обеспечивает для последовательной доработки и предоставления программной системы. Все они включают непрерывное планирование, непрерывное тестирование, непрерывную интеграцию и другие формы непрерывного развития как проекта, так и непосредственно программного обеспечения. Все они легкие, особенно по сравнению с традиционными процессами в стиле водопада, и по своей природе легко адаптируются. И что самое важное в гибких методах, так это то, что все они нацелены на то, чтобы дать людям возможность сотрудничать и быстро и эффективно принимать совместные решения.
В начале гибкие команды состояли в основном из разработчиков. Поскольку эти гибкие команды являлись более эффективными в производстве программного обеспечения, стало ясно, что обеспечение качества (QA) и разработка в качестве раздельных команд было неэффективным. В результате команды Agile стали включать в себя QA, чтобы увеличить скорость доставки программного обеспечения, и теперь Agile снова растет, чтобы охватить участников доставки и поддержки и расширить гибкость разработки ПО от идеи до доставки.
Идеология DevOps расширяет возможности гибкой разработки за счет дальнейшей оптимизации процесса изменения программного обеспечения на этапах сборки, проверки, развертывания и доставки, одновременно расширяя возможности многофункциональных групп до полного владения процессом разработки программных приложений – от проектирования до поддержки производства.
DevOps – это мышление в сфере ИТ, которое поощряет коммуникацию, сотрудничество, интеграцию и автоматизацию между разработчиками программного обеспечения и ИТ-операциями, чтобы повысить скорость и качество поставки программного обеспечения.
Команды DevOps сосредоточены на стандартизации сред разработки и автоматизации процессов доставки для повышения предсказуемости, эффективности, безопасности и удобства обслуживания. Идеология DevOps предоставляет разработчикам больший контроль над производственной средой и лучшее понимание производственной инфраструктуры. DevOps поощряет группы, обладающие самостоятельностью, создавать, проверять, доставлять и поддерживать свои собственные приложения.
2. Какие проблемы решает DevOps?
До разработки приложений DevOps команды отвечали за сбор бизнес-требований к программному обеспечению и написание кода. Затем отдельная команда QA тестирует программу в изолированной среде разработки, если код соответствует требованиям качества, передает его в следующую команду для дальнейшего развертывания. Группы развертывания далее разделяются на отдельные группы: которые работаю с сетями и которые работают с базами данных. Каждый раз, когда программу сваливают на новый отдел, образуются узкие места. Проблема этой парадигмы заключается в том, что когда команды работают отдельно:
Общий сценарий перед DevOps
Команда разработчиков, которая ставит перед собой задачу доставить как можно больше моделей программы, выпускает новую версию и «кидает ее через стену» в отдел QA. Цель тестера – найти как можно больше ошибок. Когда тестеры доводят свои результаты до команды разработки, разработчики начинают защищаться и обвиняют тестеров, которые тестируют среду, на наличие ошибок. Тестировщики отвечают, что проблема заключается не в их среде тестирования, а в коде разработчика.
Со временем проблемы решаются, и QA запускает отлаженную новую версию отправляют команде администрирования (Ops). Цель команды Ops состоит в том, чтобы ограничить изменения в своей системе, но они неудачно релизят код, и происходит сбой системы. Снова все тычут друг в друга пальцами.
Ops говорит, что Dev предоставил им дефектные артефакты. Dev говорит, что все отлично работало в тестовой среде. В режиме пожарных учений начинают отлаживать систему и обеспечивают стабильность производства. Производственная среда не является прерогативой Dev и QA, поэтому они держатся подальше, пока Ops проводит всю ночь, решая производственные проблемы.
3. Какова цель DevOps?
Улучшение сотрудничества между всеми заинтересованными сторонами от планирования до доставки и автоматизации процесса доставки с целью:
Общий сценарий: перед разработкой программного обеспечения Команда разработчиков собирается перед началом нового проекта. В команду входят разработчики, тестировщики, специалисты по эксплуатации и поддержке. Эта команда планирует, как создать работающее программное обеспечение, готовое к развертыванию.
Каждый день новый код развертывается по мере его завершения разработчиками. Автоматическое тестирование гарантирует, что код готов к развертыванию. После того, как код пройдет все автоматизированное тестирование, он будет развернут для небольшого числа пользователей. Новый код отслеживается в течение короткого периода времени, чтобы гарантировать стабильность и отсутствие непредвиденных проблем. Как только мониторинг показывает, что он стабилен, новый код распространяется на остальных пользователей. В идеале, многие, если не все, шаги после планирования и разработки выполняются без вмешательства человека.
4. Где вы находитесь на континууме DevOps?
Континуум DevOps – это полезный способ взглянуть на различные аспекты DevOps. Нижняя горизонтальная ось представляет то, как в основном люди воспринимают DevOps. Некоторые люди непреклонно считают, что DevOps должен сосредоточиться на культуре больше, чем на инструментах, в то время как другие люди склонны ценить инструменты над культурой.
DevOps стал перегруженным модным словом, которое многие люди толкуют по-разному. Вместо того, чтобы пытаться дать определение DevOps, мы собираемся описать основные концепции, которые разные люди связывают с DevOps, и историю развития движения DevOps, чтобы помочь вам получить целостное представление:
1. Откуда пришел DevOps?
DevOps – это потомок гибкой разработки программного обеспечения, рожденный необходимостью идти в ногу с возросшей скоростью программного обеспечения и достигаемыми гибкими методами . Достижения в гибкой культуре и методах за последнее десятилетие выявили необходимость более целостного подхода к сквозному жизненному циклу доставки программного обеспечения.
Что такое гибкая разработка программного обеспечения?
Agile Development - это общий термин для нескольких итеративных и дополнительных методологий разработки программного обеспечения. Наиболее популярные гибкие методологии включают Scrum, Kanban, Scaled Agile Framework® (SAFe®), Lean Development и Extreme Programming (XP).
Хотя каждая из гибких методологий уникальна в своем конкретном подходе, все они имеют общее видение и основные ценности (см. Agile Manifesto). Все они в основном включают в себя итерацию и непрерывную обратную связь, которую он обеспечивает для последовательной доработки и предоставления программной системы. Все они включают непрерывное планирование, непрерывное тестирование, непрерывную интеграцию и другие формы непрерывного развития как проекта, так и непосредственно программного обеспечения. Все они легкие, особенно по сравнению с традиционными процессами в стиле водопада, и по своей природе легко адаптируются. И что самое важное в гибких методах, так это то, что все они нацелены на то, чтобы дать людям возможность сотрудничать и быстро и эффективно принимать совместные решения.
В начале гибкие команды состояли в основном из разработчиков. Поскольку эти гибкие команды являлись более эффективными в производстве программного обеспечения, стало ясно, что обеспечение качества (QA) и разработка в качестве раздельных команд было неэффективным. В результате команды Agile стали включать в себя QA, чтобы увеличить скорость доставки программного обеспечения, и теперь Agile снова растет, чтобы охватить участников доставки и поддержки и расширить гибкость разработки ПО от идеи до доставки.
Идеология DevOps расширяет возможности гибкой разработки за счет дальнейшей оптимизации процесса изменения программного обеспечения на этапах сборки, проверки, развертывания и доставки, одновременно расширяя возможности многофункциональных групп до полного владения процессом разработки программных приложений – от проектирования до поддержки производства.
DevOps – это мышление в сфере ИТ, которое поощряет коммуникацию, сотрудничество, интеграцию и автоматизацию между разработчиками программного обеспечения и ИТ-операциями, чтобы повысить скорость и качество поставки программного обеспечения.
Команды DevOps сосредоточены на стандартизации сред разработки и автоматизации процессов доставки для повышения предсказуемости, эффективности, безопасности и удобства обслуживания. Идеология DevOps предоставляет разработчикам больший контроль над производственной средой и лучшее понимание производственной инфраструктуры. DevOps поощряет группы, обладающие самостоятельностью, создавать, проверять, доставлять и поддерживать свои собственные приложения.
2. Какие проблемы решает DevOps?
До разработки приложений DevOps команды отвечали за сбор бизнес-требований к программному обеспечению и написание кода. Затем отдельная команда QA тестирует программу в изолированной среде разработки, если код соответствует требованиям качества, передает его в следующую команду для дальнейшего развертывания. Группы развертывания далее разделяются на отдельные группы: которые работаю с сетями и которые работают с базами данных. Каждый раз, когда программу сваливают на новый отдел, образуются узкие места. Проблема этой парадигмы заключается в том, что когда команды работают отдельно:
- Dev часто не знает о контрольно-пропускных пунктах QA и Ops, которые мешают программе работать должным образом.
- QA и Ops, как правило, работают со множеством функций и не имеют большого представления о бизнес-целях и ценности программного обеспечения.
- Каждая команда может иметь цели, противоречащие целям других команд, которые могут привести к неэффективности и дать возможность указывать пальцем на коллег из другого отдела, когда что-то идет не так.
Общий сценарий перед DevOps
Команда разработчиков, которая ставит перед собой задачу доставить как можно больше моделей программы, выпускает новую версию и «кидает ее через стену» в отдел QA. Цель тестера – найти как можно больше ошибок. Когда тестеры доводят свои результаты до команды разработки, разработчики начинают защищаться и обвиняют тестеров, которые тестируют среду, на наличие ошибок. Тестировщики отвечают, что проблема заключается не в их среде тестирования, а в коде разработчика.
Со временем проблемы решаются, и QA запускает отлаженную новую версию отправляют команде администрирования (Ops). Цель команды Ops состоит в том, чтобы ограничить изменения в своей системе, но они неудачно релизят код, и происходит сбой системы. Снова все тычут друг в друга пальцами.
Ops говорит, что Dev предоставил им дефектные артефакты. Dev говорит, что все отлично работало в тестовой среде. В режиме пожарных учений начинают отлаживать систему и обеспечивают стабильность производства. Производственная среда не является прерогативой Dev и QA, поэтому они держатся подальше, пока Ops проводит всю ночь, решая производственные проблемы.
3. Какова цель DevOps?
Улучшение сотрудничества между всеми заинтересованными сторонами от планирования до доставки и автоматизации процесса доставки с целью:
- Улучшить частоту развертывания
- Добиться более быстрого выхода на рынок
- Понизить частоту отказов новых выпусков
- Сократить время выполнения между исправлениями
- Улучшить среднее время восстановления
Общий сценарий: перед разработкой программного обеспечения Команда разработчиков собирается перед началом нового проекта. В команду входят разработчики, тестировщики, специалисты по эксплуатации и поддержке. Эта команда планирует, как создать работающее программное обеспечение, готовое к развертыванию.
Каждый день новый код развертывается по мере его завершения разработчиками. Автоматическое тестирование гарантирует, что код готов к развертыванию. После того, как код пройдет все автоматизированное тестирование, он будет развернут для небольшого числа пользователей. Новый код отслеживается в течение короткого периода времени, чтобы гарантировать стабильность и отсутствие непредвиденных проблем. Как только мониторинг показывает, что он стабилен, новый код распространяется на остальных пользователей. В идеале, многие, если не все, шаги после планирования и разработки выполняются без вмешательства человека.
4. Где вы находитесь на континууме DevOps?
Континуум DevOps – это полезный способ взглянуть на различные аспекты DevOps. Нижняя горизонтальная ось представляет то, как в основном люди воспринимают DevOps. Некоторые люди непреклонно считают, что DevOps должен сосредоточиться на культуре больше, чем на инструментах, в то время как другие люди склонны ценить инструменты над культурой.
На вертикальной оси изображены три уровня цепочки поставок DevOps: непрерывная интеграция, непрерывная доставка и непрерывное развертывание. Сообщество DevOps относится к организациям в правом верхнем углу континуума DevOps, как к розовым единорогам, потому что в настоящее время их так мало, что вы не видите их в дикой природе, как правило. Популярными примерами этих единорогов являются такие компании, как Netflix, Etsy, Amazon, Pinterest, Flicker, IMVU и Google. В недавнем опросе участники указали, где их организации вписываются в континуум
DevOps:
Другим важным моментом является то, что перемещение вверх и вправо требует времени, и первым шагом многих организаций будет сочетание культуры, инструментов и непрерывной интеграции, поэтому не расстраивайтесь, когда читаете статью о том, что вы «не DevOps », если вы не внедрили в производство автоматизацию без какого-либо вмешательства человека (на этапах после планирования и разработки кода).
DevOps может быть смесью культуры, инструментов и зрелости, которые будут полезны вашей организации. А, как мы знаем, то, что имеет смысл, скорее всего, со временем будет развиваться. Важно постоянно стремиться сломать стены и узкие места между фазами доставки программного обеспечения, улучшая совместную работу и автоматизацию. В следующих разделах мы углубимся в каждый аспект континуума DevOps, чтобы помочь вам лучше понять, на какой стадии внедрения DevOps вы находитесь.
5. Каковы фазы зрелости DevOps?
Есть несколько фаз для зрелости DevOps. Вот несколько ключевых этапов, которые вам необходимо знать:
Водопад / развитие
До непрерывной интеграции команды разработчиков писали кучу кода в течение трех-четырех месяцев. Затем эти команды объединят свой код, чтобы выпустить его. Разные версии кода могли очень сильно различаться и иметь столько изменений, что фактический этап интеграции может занимать месяцы. Этот процесс был очень непродуктивным.
Непрерывная интеграция
Непрерывная интеграция – это практика быстрой интеграции недавно разработанного кода с основной частью кода, который должен быть выпущен. Непрерывная интеграция экономит много времени, когда команда готова выпустить код и часто является первым шагом на пути к организации DevOps в вашей компании.
Процесс непрерывной интеграции с точки зрения DevOps включает в себя проверку вашего кода, компиляцию его в пригодный для использования (часто исполняемый двоичный код) и выполнение некоторого базового проверочного тестирования.
Непрерывная доставка
Непрерывная доставка является продолжением непрерывной интеграции [этап DevOps 2] и находится на ее вершине. Выполняя непрерывную доставку, вы добавляете дополнительную автоматизацию и тестирование, чтобы не просто часто компилировать дописанный код с основным, но и получить код, практически готовый для развертывания, практически без вмешательства человека. Это практика подразумевает, что кодовая база постоянно готова к развертыванию.
Непрерывное развертывание
Непрерывное развертывание, которое не следует путать с непрерывной доставкой [DevOps nirvana], является, своего рода, продвинутой непрерывной доставкой. Это практика развертывания без какого-либо вмешательства человека.
Команды, использующие непрерывную доставку, не развертывают непроверенный код; вместо этого вновь созданный код проходит автоматическое тестирование, прежде чем его отправляют в производство. Релиз кода, как правило, предоставляется только небольшому проценту пользователей, и существует автоматический цикл обратной связи, который контролирует качество и использование, прежде чем код будет распространяться дальше.
Есть очень небольшое количество компаний, которые реализовали непрерывное развертывание почти на 100%: Netflix, Etsy, Amazon, Pinterest, Flicker, IMVU и Google.
В то время как DevOps нирвана часто не является конечной целью для большинства предприятий, они часто сосредоточены на продвижении к непрерывным поставкам.
6. Каковы ценности DevOps?
DevOps уделяет большое внимание созданию культуры сотрудничества и повышению эффективности за счет автоматизации с помощью инструментов DevOps. В то время как некоторые организации и люди склонны ценить одну больше, чем другую, реальность такова, что для достижения успеха требуется сочетание культуры и инструментов. Вот что вам нужно знать об этих двух значениях DevOps.
DevOps Культура
Культура DevOps характеризуется расширением сотрудничества, уменьшением разрозненности, совместной ответственностью, независимой командой, улучшением качества, оценкой обратной связи и ростом автоматизации. Многие из значений DevOps являются гибкими значениями, поскольку DevOps является расширением гибких методологий разработки программного обеспечения.
Гибкие методы – более целостный способ доставки программного обеспечения. Agile команды разработчиков измеряют прогресс с точки зрения рабочего программного обеспечения. Владельцы продуктов, разработчики, тестировщики и сотрудники UX работают в тесной коллаборации с общими целями.
DevOps добавляет бизнес-логику непосредственно в команду разработки и, возможно, члена команды с который за этой логикой следит. Принимая во внимание, что до того, как прогресс DevOps будет оценен с точки зрения рабочего программного обеспечения, прогресс DevOps должен быть измерен с точки зрения конечного пользователя (клиента) программного продукта.
Чтобы достичь этого, Dev и Ops должны выйти из своих бункеров и сотрудничать друг с другом, разделить ответственность за обслуживание системы, на которой работает программное обеспечение, и подготовить программное обеспечение для работы в системе с повышенным качеством обратной связи и автоматизацией доставки.
Инструменты DevOps
Инструменты DevOps состоят из систем управления конфигурациями, тестирования и сборки, развертывания приложений, инструментов контроля версий и мониторинга. Непрерывная интеграция, непрерывная доставка и непрерывное развертывание требуют различных инструментов. Хотя все три практики могут использовать одни и те же инструменты, вам понадобится больше инструментов по мере продвижения по цепочке поставок.
[/ spb_text_block] [/ spb_column] [spb_column width = "1/1" el_position = "first last"] [spb_text_block animation = "none" animation_delay = "0" padding_vertical = "0" padding_hor horizontal = "0" width = "1 / 1 "el_position =" first last "]
7. Какие инструменты используются в DevOps?
Ранее мы кратко обсудили некоторые инструменты, используемые в DevOps. Вот некоторые из ключевых инструментов и методов, которые вам нужно знать.
Репозиторий исходного кода
Хранилище исходного кода – это место, где разработчики регистрируют и изменяют код. Хранилище исходного кода управляет различными версиями кода, которые зарегистрированы, поэтому разработчики не переписывают работу друг друга.
Контроль над источниками, вероятно, существует уже около сорока лет, но он является основным компонентом непрерывной интеграции. Популярными инструментами для хранения исходного кода являются Git, Subversion, Cloudforce, Bitbucket и TFS.
Сервер сборки
Сервер сборки – это инструмент автоматизации, который компилирует код из репозитория исходного кода в базу исполняемого кода. Популярными инструментами являются Jenkins, SonarQube и Artifactory.
Управление конфигурацией
Управление конфигурацией определяет конфигурацию сервера или среды. Популярными инструментами управления конфигурациями являются Puppet и Chef.
Виртуальная инфраструктура
Amazon Web Services и Microsoft Azure являются примерами виртуальных инфраструктур. Виртуальные инфраструктуры предоставляются поставщиками облачных услуг, которые продают инфраструктуру или платформу как услугу (PaaS). Эти инфраструктуры имеют API-интерфейсы, позволяющие программно создавать новые машины с помощью инструментов управления конфигурацией, таких как Puppet и Chef.
Есть также частные облака. Например, у VMware есть vCloud. Частные виртуальные инфраструктуры позволяют вам запускать облако на оборудовании вашего центра обработки данных.
Виртуальные инфраструктуры в сочетании с инструментами автоматизации позволяют организациям, практикующим DevOps, настраивать сервер без каких-либо действий на клавиатуре. Если вы хотите протестировать свой совершенно новый код, вы можете автоматически отправить его в облачную инфраструктуру, создать среду и затем выполнить все тесты без участия человека.
Автоматизация испытаний
Автоматизация тестирования существует уже давно. Тестирование DevOps фокусируется на автоматическом тестировании в вашем конвейере сборки, чтобы гарантировать, что к моменту развертывания сборки вы будете уверены, что она готова к этому. Популярными инструментами являются Selenium и Whater.
Трубопроводная оркестровка
Конвейер подобен производственной сборочной линии, которая происходит с того момента, когда разработчик говорит «я думаю, что я закончил», вплоть до того момента, когда код будет развернут в производственной или поздней стадии подготовки к работе.
Есть вопросы по организации DevOps в компании? Заполните форму ниже, и мы вас проконсультируем.
DevOps:
- 55% слева внизу
- 26% справа внизу
- 14% вверху слева
- 5% сверху справа
Другим важным моментом является то, что перемещение вверх и вправо требует времени, и первым шагом многих организаций будет сочетание культуры, инструментов и непрерывной интеграции, поэтому не расстраивайтесь, когда читаете статью о том, что вы «не DevOps », если вы не внедрили в производство автоматизацию без какого-либо вмешательства человека (на этапах после планирования и разработки кода).
DevOps может быть смесью культуры, инструментов и зрелости, которые будут полезны вашей организации. А, как мы знаем, то, что имеет смысл, скорее всего, со временем будет развиваться. Важно постоянно стремиться сломать стены и узкие места между фазами доставки программного обеспечения, улучшая совместную работу и автоматизацию. В следующих разделах мы углубимся в каждый аспект континуума DevOps, чтобы помочь вам лучше понять, на какой стадии внедрения DevOps вы находитесь.
5. Каковы фазы зрелости DevOps?
Есть несколько фаз для зрелости DevOps. Вот несколько ключевых этапов, которые вам необходимо знать:
Водопад / развитие
До непрерывной интеграции команды разработчиков писали кучу кода в течение трех-четырех месяцев. Затем эти команды объединят свой код, чтобы выпустить его. Разные версии кода могли очень сильно различаться и иметь столько изменений, что фактический этап интеграции может занимать месяцы. Этот процесс был очень непродуктивным.
Непрерывная интеграция
Непрерывная интеграция – это практика быстрой интеграции недавно разработанного кода с основной частью кода, который должен быть выпущен. Непрерывная интеграция экономит много времени, когда команда готова выпустить код и часто является первым шагом на пути к организации DevOps в вашей компании.
Процесс непрерывной интеграции с точки зрения DevOps включает в себя проверку вашего кода, компиляцию его в пригодный для использования (часто исполняемый двоичный код) и выполнение некоторого базового проверочного тестирования.
Непрерывная доставка
Непрерывная доставка является продолжением непрерывной интеграции [этап DevOps 2] и находится на ее вершине. Выполняя непрерывную доставку, вы добавляете дополнительную автоматизацию и тестирование, чтобы не просто часто компилировать дописанный код с основным, но и получить код, практически готовый для развертывания, практически без вмешательства человека. Это практика подразумевает, что кодовая база постоянно готова к развертыванию.
Непрерывное развертывание
Непрерывное развертывание, которое не следует путать с непрерывной доставкой [DevOps nirvana], является, своего рода, продвинутой непрерывной доставкой. Это практика развертывания без какого-либо вмешательства человека.
Команды, использующие непрерывную доставку, не развертывают непроверенный код; вместо этого вновь созданный код проходит автоматическое тестирование, прежде чем его отправляют в производство. Релиз кода, как правило, предоставляется только небольшому проценту пользователей, и существует автоматический цикл обратной связи, который контролирует качество и использование, прежде чем код будет распространяться дальше.
Есть очень небольшое количество компаний, которые реализовали непрерывное развертывание почти на 100%: Netflix, Etsy, Amazon, Pinterest, Flicker, IMVU и Google.
В то время как DevOps нирвана часто не является конечной целью для большинства предприятий, они часто сосредоточены на продвижении к непрерывным поставкам.
6. Каковы ценности DevOps?
DevOps уделяет большое внимание созданию культуры сотрудничества и повышению эффективности за счет автоматизации с помощью инструментов DevOps. В то время как некоторые организации и люди склонны ценить одну больше, чем другую, реальность такова, что для достижения успеха требуется сочетание культуры и инструментов. Вот что вам нужно знать об этих двух значениях DevOps.
DevOps Культура
Культура DevOps характеризуется расширением сотрудничества, уменьшением разрозненности, совместной ответственностью, независимой командой, улучшением качества, оценкой обратной связи и ростом автоматизации. Многие из значений DevOps являются гибкими значениями, поскольку DevOps является расширением гибких методологий разработки программного обеспечения.
Гибкие методы – более целостный способ доставки программного обеспечения. Agile команды разработчиков измеряют прогресс с точки зрения рабочего программного обеспечения. Владельцы продуктов, разработчики, тестировщики и сотрудники UX работают в тесной коллаборации с общими целями.
DevOps добавляет бизнес-логику непосредственно в команду разработки и, возможно, члена команды с который за этой логикой следит. Принимая во внимание, что до того, как прогресс DevOps будет оценен с точки зрения рабочего программного обеспечения, прогресс DevOps должен быть измерен с точки зрения конечного пользователя (клиента) программного продукта.
Чтобы достичь этого, Dev и Ops должны выйти из своих бункеров и сотрудничать друг с другом, разделить ответственность за обслуживание системы, на которой работает программное обеспечение, и подготовить программное обеспечение для работы в системе с повышенным качеством обратной связи и автоматизацией доставки.
Инструменты DevOps
Инструменты DevOps состоят из систем управления конфигурациями, тестирования и сборки, развертывания приложений, инструментов контроля версий и мониторинга. Непрерывная интеграция, непрерывная доставка и непрерывное развертывание требуют различных инструментов. Хотя все три практики могут использовать одни и те же инструменты, вам понадобится больше инструментов по мере продвижения по цепочке поставок.
[/ spb_text_block] [/ spb_column] [spb_column width = "1/1" el_position = "first last"] [spb_text_block animation = "none" animation_delay = "0" padding_vertical = "0" padding_hor horizontal = "0" width = "1 / 1 "el_position =" first last "]
7. Какие инструменты используются в DevOps?
Ранее мы кратко обсудили некоторые инструменты, используемые в DevOps. Вот некоторые из ключевых инструментов и методов, которые вам нужно знать.
Репозиторий исходного кода
Хранилище исходного кода – это место, где разработчики регистрируют и изменяют код. Хранилище исходного кода управляет различными версиями кода, которые зарегистрированы, поэтому разработчики не переписывают работу друг друга.
Контроль над источниками, вероятно, существует уже около сорока лет, но он является основным компонентом непрерывной интеграции. Популярными инструментами для хранения исходного кода являются Git, Subversion, Cloudforce, Bitbucket и TFS.
Сервер сборки
Сервер сборки – это инструмент автоматизации, который компилирует код из репозитория исходного кода в базу исполняемого кода. Популярными инструментами являются Jenkins, SonarQube и Artifactory.
Управление конфигурацией
Управление конфигурацией определяет конфигурацию сервера или среды. Популярными инструментами управления конфигурациями являются Puppet и Chef.
Виртуальная инфраструктура
Amazon Web Services и Microsoft Azure являются примерами виртуальных инфраструктур. Виртуальные инфраструктуры предоставляются поставщиками облачных услуг, которые продают инфраструктуру или платформу как услугу (PaaS). Эти инфраструктуры имеют API-интерфейсы, позволяющие программно создавать новые машины с помощью инструментов управления конфигурацией, таких как Puppet и Chef.
Есть также частные облака. Например, у VMware есть vCloud. Частные виртуальные инфраструктуры позволяют вам запускать облако на оборудовании вашего центра обработки данных.
Виртуальные инфраструктуры в сочетании с инструментами автоматизации позволяют организациям, практикующим DevOps, настраивать сервер без каких-либо действий на клавиатуре. Если вы хотите протестировать свой совершенно новый код, вы можете автоматически отправить его в облачную инфраструктуру, создать среду и затем выполнить все тесты без участия человека.
Автоматизация испытаний
Автоматизация тестирования существует уже давно. Тестирование DevOps фокусируется на автоматическом тестировании в вашем конвейере сборки, чтобы гарантировать, что к моменту развертывания сборки вы будете уверены, что она готова к этому. Популярными инструментами являются Selenium и Whater.
Трубопроводная оркестровка
Конвейер подобен производственной сборочной линии, которая происходит с того момента, когда разработчик говорит «я думаю, что я закончил», вплоть до того момента, когда код будет развернут в производственной или поздней стадии подготовки к работе.
Есть вопросы по организации DevOps в компании? Заполните форму ниже, и мы вас проконсультируем.
Вам также может быть интересно