Devops что это: DevOps — что это, зачем, и насколько востребовано? / Блог компании Хабр Карьера / Хабр

что это и зачем нужно — статьи на Skillbox

Термин DevOps — это общее название development и operations, то есть разработки и эксплуатации. Общий термин появился в 2009 году, когда Патрик Дюбуа вдохновился презентацией Джона Оллспоу и Пола Хаммонда на конференции Velocity и организовал DevOpsDays в Бельгии.

Есть разные версии о том, что такое DevOps. Одни считают, что это набор инструментов. Другие, что это продолжение методологии Agile. Кто-то думает, что это просто должность. Будем считать, что DevOps — это концепция, в которую входят все лучшие практики Agile и бережливого производства, теории ограничений и принципов Toyota.

DevOps — это философия, концепция, методология, но не набор инструментов.

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

Чтобы работать по DevOps, команда должна соблюдать эти правила.

• Иметь общие и четко сформулированные цели.
• Быть уверенными в одинаковом понимании целей.
• Работать вместе: сообщать друг другу о намерениях и проблемах.
• Относиться к ошибкам как фактору роста и возможности для обучения.
• Непрерывно общаться и обмениваться информацией.

В основе концепции DevOps — три принципа, они же — три пути. Без них ничего не работает.

Продукт быстро попадает от разработчика к клиенту.

Например, как в Scrum: команда делает ПО, добавляет функции одну за другой. Заказчик начинает пользоваться продуктом до того, как тот будет полностью готов.

Чтобы это работало, нужно добиться прозрачности процесса, когда каждый в команде знает: на каком этапе проект, кто и чем занят, сколько времени осталось.

Визуализировать процесс помогают kanban- или scrum-доски со стикерами или карточками с задачами. В статье «Все, что нужно знать о Kanban: теория, принципы и возможности» мы рассказали, как это работает.

Чтобы процесс не превратился в хаос, старайтесь ограничивать количество
карточек-задач, одновременно стоящих в одной колонке.

Три совета, чтобы все получилось:

1. Делите задачи на части.
2. Используйте короткие итерации, чтобы избежать дефектов в конце проекта.
3. Старайтесь постоянно улучшать процесс.

Обратная связь быстро попадает от клиента к разработчику.

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

Три совета, чтобы все получилось:

1. Работайте короткими спринтами.
2. Тестируйте каждую новую функцию.
3. Сверяйте: чего хочет клиент, чего хочет команда, что получается в результате.

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

Три совета, чтобы все получилось:

1. Сокращайте петлю обратной связи.
2. Экспериментируйте и используйте новый опыт для улучшений.
3. Используйте накопленные компанией знания и опыт.

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

Разработка в DevOps — единый процесс, разделенный на части. В этом основное отличие концепции от Scrum, где проводят тестирование и получают обратную связь после выполнения группы задач, а не каждой отдельной функции.

DevOps — сложная концепция, которая помогает крупным компаниям. Когда много разных отделов и специалистов, и их нужно объединить, чтобы что-то получилось. Например, ее используют Google, Netflix и Etsy.

Если у вас маленькая студия, возможно, то не нужно углубляться в DevOps, а улучшить процессы помогут Kanban или Scrum. Что использовать — решать вам.

Вот о чем нужно помнить обязательно, выбирая DevOps.

Найдите проблему или процесс, которые нужно улучшить.

Спросите себя: что изменится, если решить эту проблему; что будет, если ничего не менять.

Определите цель: что и когда нужно сделать.

Распишите действия шаг за шагом.

Используйте короткие итерации.

Проверяйте результат и ставьте новые цели после каждой итерации.

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

Курс «Управление Digital-проектами»

Курс поможет вам оценить себя как менеджера: разобраться и понять, почему у вас что-то не получается. Определить, какие навыки и знания нужно подтянуть. И сделать это, выполняя практические задания.

• Живая обратная связь с преподавателями
• Неограниченный доступ к материалам курса
• Стажировка в компаниях-партнёрах
• Дипломный проект от реального заказчика
• Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

Что такое DevOps? Описание DevOps | Microsoft Azure

• 
  
  
  Продажи:
  
  
  :
  Найти местный номер
  
• 
  Моя учетная запись
  
• 
  Портал
• 
  
  
  Вход
  
  






• 
  
  Бесплатная учетная запись
  





• 
  Обзор
  




• 
  
  Решения
  




• 
  
  Продукты
  
  
  • • 
      
      
      Избранные
      
      
      Избранные
      
      Ознакомьтесь с наиболее популярными продуктами Azure
    • 
      
      ИИ + машинное обучение
      
      
      ИИ + машинное обучение
      
      
      Создавайте приложения нового поколения, используя возможности искусственного интеллекта для любых разработчиков и любых сценариев.
    • 
      
      Аналитика
      
      
      Аналитика
      
      
      Получите такие преимущества, как сбор, хранение, обработка, анализ и визуализация данных любого типа и объема и с любой скоростью.
    • 
      
      Блокчейн
      
      
      Блокчейн
      
      Создавайте приложения на базе блокчейна и управляйте ими с помощью набора интегрированных средств
    • 
      
      Среда выполнения приложений
      
      
      Среда выполнения приложений
      
      
      Воспользуйтесь возможностями облачных вычислений и масштабирования по требованию. При этом вы платите только за те ресурсы, которые используете.
    • 
      
      Контейнеры
      
      
      Контейнеры
      
      
      Разрабатывайте и администрируйте контейнерные приложения быстрее благодаря встроенным средствам
    • 
      
      Базы данных
      
      
      Базы данных
      
      
      Продолжайте быстро развиваться и оперативно внедряйте инновации благодаря безопасным полностью управляемым службам баз данных корпоративного уровня.

Кто такой DevOps и когда он не нужен / Блог компании Playgendary / Хабр

Тема DevOps за последние несколько лет стала очень популярной. Многие мечтают в нее влиться, но, как показывает практика, часто только из-за уровня зарплат.

Некоторые указывают в своем резюме DevOps, хотя не всегда знают и понимают суть термина. Кто-то считает, что изучив Ansible, GitLab, Jenkins, Terraform и им подобные (список можно продолжать на свой вкус), то сразу станет «девопсом». Это, конечно, не так.

Несколько последних лет я занимаюсь в основном внедрением DevOps в различных компаниях. До этого более 20 лет работал на позициях от системного администратора до IT-директора. Сейчас — DevOps Lead Engineer в Playgendary.

Кто такой DevOps

Идея написать статью возникла после очередного вопроса: «кто такой DevOps?». До сих пор нет устоявшегося термина, что или кто это. Часть ответов уже есть в этом видео. Сначала выделю главные тезисы из него, а затем поделюсь своими наблюдениями и мыслями.

DevOps — не специалист, которого можно нанять, не набор утилит, и не отдел разработчиков с инженерами.

DevOps — это философия и методология.

Другими словами, это набор практик, который помогает активно взаимодействовать разработчикам с системными администраторами. То есть связывать и интегрировать рабочие процессы друг в друга.

С появлением DevOps структура и роли специалистов остались такими же (есть девелоперы, есть инженеры), но изменились правила взаимодействия. Размылись границы между отделами.

Цели DevOps можно описать тремя пунктами:

• Софт должен обновляться регулярно.
• Софт должен делаться быстро.
• Софт должен развертываться удобно и в короткие сроки.

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

И это только часть инструментов DevOps

Уже больше 2-х лет собеседую людей на позицию DevOps-инженера и ко мне пришло осознание, насколько важно четко понимать суть термина. Накопился специфический опыт, наблюдения и мысли, которыми хочу поделиться.

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

Был яркий пример. На собеседование пришел молодой человек с кучей умных слов в резюме. На последних трех местах работы у него был стаж 5-6 месяцев. Из двух стартапов ушел, потому что «не взлетели». А вот насчет третьей компании сказал, что там его никто не понимает: разработчики пишут код по Windows, а директор заставляет этот код «заворачивать» в обычный Docker и встраивать в CI/CD-пайплайн. Парень много чего негативного рассказал по поводу его текущего места работы и его коллегах — так и хотелось ответить: «Так ты слона не продашь».

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

— Что лично для тебя означает DevOps?

— Вообще или как я это воспринимаю?

Меня интересовало его личное мнение. Он знал теорию и происхождение термина, но был категорически с ними не согласен. Он считал, что DevOps — должность. Здесь и кроется корень его проблем. Как и других специалистов с таким же мнением.

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

Методология и философия DevOps

Методология бывает теоретической и практической. В нашем случае — второе. Как я упоминал выше, DevOps — это набор практик и стратегий, применяемых для достижения заявленных целей. И в каждом случае, в зависимости от бизнес-процессов компании, он может существенно отличаться. Что не делает его лучше или хуже.

Методология DevOps — лишь средство достижения поставленных целей.

Теперь о том, что такое философия DevOps. И это, наверное, самый трудный вопрос.

Сформулировать краткий и емкий ответ достаточно сложно, потому что он еще не формализован. И так как адепты философии DevOps больше занимаются практикой — на философствования просто нет времени. Тем не менее, это очень важный процесс. Причём напрямую относящийся к инженерной деятельности. Есть даже специализированная область познания — философия техники.

В моём ВУЗе такого предмета не было, пришлось изучать все самостоятельно по тем материалам, которые смог найти в 90-е. Тема необязательная для инженерного образования, отсюда и отсутствие формализации ответа. Но те люди, которые серьёзно погрузились в DevOps, начинают ощущать некий «дух» или «неосознанную всеобъемлющность» всех процессов компании.

Я на своем опыте постарался формализовать некоторые «постулаты» этой философии. Получилось следующее:

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

Думаю, что мои «постулаты» это отдельная тема для обсуждения. Но теперь есть от чего отталкиваться.

Что делает DevOps

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

Про западный рынок труда говорить со 100% уверенностью не могу. Но вот о рынке DevOps в России знаю довольно много. Кроме сотен собеседований, за последние полтора года я участвовал в сотне технических пресейлов по услуге «Внедрение DevOps» для крупных российский компаний и банков.

В России DevOps ещё очень молодая, но уже трендовая тема. Насколько я знаю, только по Москве дефицит таких специалистов за 2019 год составил более 1000 человек. А слово Kubernetes для работодателей почти как красная тряпка для быка. Адепты этого инструмента готовы использовать его даже там, где это не нужно и экономически не выгодно. Работодатель не всегда понимает в каких случаях, что уместнее использовать, а при должном развертывании содержание кластера Kubernetes стоит в 2-3 раза дороже, чем развертывание приложения по обычной кластерной схеме. Используйте его там, где он действительно нужен.

Внедрение DevOps с точки зрения денег — дорого. И оправдано только там, где приносит экономическую выгоду в других областях, а не само по себе.

DevOps-инженеры, фактически, первопроходцы — именно они первыми должны внедрять в компании эту методологию и выстраивать процессы. Чтобы это было успешно, специалист должен постоянно взаимодействовать с сотрудниками и коллегами на всех уровнях. Как я обычно говорю, в процесс внедрения DevOps должны быть вовлечены все сотрудники компании: от уборщицы до CEO. И это обязательное условие. Если самый младший член команды не будет знать и понимать, что такое DevOps и зачем выполняются те или иные организационные действия, то успешного внедрения не получится.

Также DevOps-инженеру нужно время от времени использовать административный ресурс. Например, для преодоления «сопротивления среды» — когда команда не готова принять инструменты и методологию DevOps.

Разработчик должен писать только код и тесты. Для этого ему не нужен супермощный ноутбук, на котором он будет разворачивать и поддерживать локально всю инфраструктуру проекта. Например, фронтендер держит у себя на ноутбуке все элементы приложения, включая базу данных, эмулятор S3 (minio) и прочее. То есть тратит много времени на поддержание этой локальной инфраструктуры и в одиночку борется со всеми проблемами такого решения. Вместо того, чтобы разрабатывать код для фронта. Такие люди могут сильно сопротивляться любым изменениям.

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

Когда DevOps не нужен

Бывают ситуации, когда DevOps не нужен. Это факт — его нужно понять и принять.

В первую очередь, это касается любых компаний (особенно малого бизнеса), когда их прибыль не зависит напрямую от наличия или отсутствия IT-продуктов, предоставляющих информационные сервисы клиентам. И здесь речь не о сайте компании, будь он статической «визиткой» или с динамическими новостными блоками и т.п.

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

Ярким примером является один известный банк. У компании нет привычных клиентских офисов, документооборот осуществляется через почту или курьеров, а множество сотрудников работает из дома. Компания перестала быть просто банком и, на мой взгляд, превратилась в IT-компанию с развитыми DevOps-технологиями.

Много других примеров и лекций можно найти в записях тематических митапов и конференций. Часть из них я посетил лично — это очень полезный опыт для тех, кто хочет развиваться в этом направлении. Вот ссылки на YouTube-каналы с хорошими лекциями и материалами по DevOps:

Теперь посмотрите на свой бизнес и подумайте вот о чём: как сильно ваша компания и её прибыль зависят от IT-продуктов, обеспечивающих взаимодействие с клиентом?

Если ваша компания торгует рыбой в небольшом магазинчике и единственным IT-продуктом являются две конфигурации 1С: Предприятие (Бухгалтерия и УНФ), то вряд ли есть смысл говорить о DevOps.

Если же вы работаете на крупном торговом и производственном предприятии (например, производите охотничьи ружья), то стоит задуматься. Вы можете проявить инициативу и донести своему руководству перспективы внедрения DevOps. Ну, и заодно, возглавить этот процесс. Проактивная позиция — один из важных постулатов философии DevOps.

Размер и объем годового финансового оборота не является основным критерием для определения, нужен ли вашей компании DevOps.

Представим себе крупное промышленное предприятие, которое не взаимодействует напрямую с клиентами. Например, некоторые автоконцерны и автомобилестроительные компании. Сейчас не уверен, но, из моего прошлого опыта, много лет всё взаимодействие с клиентами осуществлялось по электронной почте и телефону.

Их клиенты — это ограниченный список автомобильных дилеров. И к каждому прикреплен специалист от производителя. Весь внутренний документооборот происходит через ERP SAP. Внутренние сотрудники, по сути, являются клиентами информационной системы. Но управление этой ИС осуществляется классическими средствами управления кластерными системами. Что исключает возможность использования практик DevOps.

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

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

Основной критерий для понимания нужен ли DevOps: какое значение ваши IT-продукты имеют для компании и клиентов.

Если основной продукт компании, приносящий прибыль, это ПО — вам нужен DevOps. И не так важно, если зарабатываете реальные деньги вы с помощью других товаров. Сюда также можно отнести интернет-магазины или мобильные приложения с играми.

Любые игры существуют благодаря финансированию: прямому или косвенному со стороны игроков. В Playgendary мы разрабатываем бесплатные мобильные игры, в непосредственном создании которых участвуют более 200 человек. Как мы используем DevOps?

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

Сейчас у нас активно используется Jenkins как инструмент CI/CD pipelines для выполнения всех сборочных конвейеров с Unity и последующего деплоя в App Store и Play Market. Еще из классического набора инструментов:

• Asana — для управления проектами. Настроена интеграция с Jenkins.
• Google Meet — для проведения видеовстреч.
• Slack — для коммуникаций и различных оповещений, включая нотификации из Jenkins.
• Atlassian Confluence — для документирования и групповой работы.

В ближайших планах внедрить статический анализ кода с помощью SonarQube и провести автоматизированное UI-тестирование средствами Selenium на этапе Continuous Integration.

Вместо заключения

Хочу закончить следующей мыслью: чтобы стать DevOps-инженером высокой квалификации, жизненно необходимо научиться живому общению с людьми.

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

И да, внедрение любого решения потребует множества обсуждений, а к концу может вообще измениться. Самостоятельно развиваясь, предлагая и осуществляя свои задумки — такой человек представляет все большую ценность как для команды, так и для работодателя. Что, в конечном счёте, отражается и на размере его ежемесячного вознаграждения или в виде дополнительных премий.

11 важных вещей, которые нужно знать про DevOps — часть первая

От переводчика

В 2009 года за рубежом возникло движение, которое назвало себя DevOps. На первый взгляд это разработчики с навыками сисадминов и сисадмины с навыками разработчиков. Но на самом деле это отнюдь не так. Данное подход имеет четкие цели, философию, инструменты и методы, которые только некоторые русскоязычные компании начинают использовать. Мне кажется, что данный подход у нас незаслуженно игнорируется и мне хотелось бы рассказать об 11 вещах, которые нужно знать о DevOps, в частности:

• что такое DevOps
• каковы его ценности
• как он внедряется
• кому он приносит пользу

Надеюсь, этот текст вам понравится.

1. Что такое DevOps и откуда оно взялось?

Термином «DevOps» обычно называют возникшее профессиональное движение, которое выступает за совместные рабочие отношения между разработчиками и ИТ-подразделением, в результате получая более быстрое выполнение планируемых работ (например, высокие темпы развертывания), одновременно увеличивая надежность, стабильность, устойчивость и безопасность production-среды. Почему разработчики и ИТ-подразделения (далее для краткости админы)? Потому что, как правило, поток ценностей (value stream) находится между бизнесом (где определяются требования) и заказчиком (куда поставляется результат).

Считается, что движение DevOps зародилось в 2009 году, как объединение многочисленных смежных и взаимодополняющих сообществ: Velocity Conference, на которой особенно яркими было выступление «10 Deploys A Day» John Allspaw и Paul Hammond, подход «инфраструктура как код»(Mark Burgess и Luke Kanies),» Agile infrastructure «(Andrew Shafer) и системное администрирование в Agile (Patrick DeBois), подход Lean Startup Эрика Райса с его непрерывной интеграции, а так же широкая доступность облачных и PaaS технологий.

Один из соавторов DevOps Cookbook, Джон Уиллис, написал фантастический пост об этом событии.

2. Чем DevOps отличаются от Agile?

Одним из принципов Agile является предоставление рабочего программного обеспечения меньшими и более частыми релизами, в отличие от подхода «большого взрыва», который присущ водопадной методологии. Так что Agile стремятся иметь потенциально готовый продукт в конце каждого спринта (как правило, раз в две недели).

Высокие темпы развертывания приводят к тому, что перед админами накапливается большая гора задач. Clyde Logue, основатель StreamStep, говорит об этом так: «Agile сыграл важную роль в разработке для восстановлению доверия у бизнеса, но он нечаянно оставил IT Operations позади. DevOps это способ восстановления доверия ко всей ИТ-организации в целом ».

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

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

DevOps, в том числе, изменяет культуру, так же как изменяет процессы и метрике разработчиков и админов. Джон Уиллис и Дэймон Эдвардс (соавторы Cookbook DevOps) подробно написали об этом здесь.

3. Чем DevOps отличается от ITIL и ITSM?

Хотя многие люди считают, что DevOps это реакция на ITIL (IT Infrastructure Library) и ITSM (IT Service Management), у меня другая точка зрения. ITIL и ITSM по-прежнему являются лучшей кодификацией бизнес-процессов, лежащих в основе ИТ подразделения, так как на самом деле описыват многие вещи, необходимые для того, чтобы ИТ команда могда работать в формате DevOps.

Непрерывная интеграция и релизы являются результатом работы разработчиков, что в свою очередь является материалом для работы админов. Для того чтобы уложится в более быстрый ритм релизов, существующий в DevOps, многие процессы ITIL требуют автоматизации, в частности, связанные с изменением конфигурации и релизов в целом.

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

4. Чем DevOps похоже на VisibleOps?

В соавторстве с Kevin Behr и George Spafford я написал „Visible Ops Handbook“ в 2004 году. Visible Ops является руководством по достижению трансформации к высокопроизводительным ИТ подразделениями по пути „от хорошего к великому“, и одним из ключевых понятий является понятие по ограничению и сокращению незапланированных работ.

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

5. Каковы принципы DevOps?

В DevOps Cookbook и The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, мы описываем лежащие в основе принципы, с помощью которых все DevOps паттерны могут быть получены с помощью подхода «Три пути». Они описывают ценности и философию, которые являются основой процессов, процедур, практик, а также обязательных шагов.

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

В центре внимания находится все бизнес-потоки по созданию ценности, которые включены в IT. Другими словами, он начинается тогда, когда определяются основные требования (например, для бизнес или ИТ), они закончены в разработке, а затем перешли в ИТ-отдел, в которых ценность сервиса затем и доставляется заказчику в виде сервиса.

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

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

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

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

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

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

6. Области внедрения DevOps

В книге „DevOps Cookbook“, мы выделили 4 моделей внедрения DevOps:

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

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

Модель 3: Объединение разработки и администрирования: состоит во включении команды разработки в цепочку разрешения проблем, назначение разработчиков на разрешение проблем на проде, а так же взаимные тренинги между разработчиками и администраторами, чтобы уменьшить количество эскалаций.

Модель 4: Включение ИТ команды в разработку: состоит во включении или тесной связью между IT и разработкой, создание многоэтапных пользовательских историй (включая развертывание, управление кодом в производстве и т.д.), и определение нефункциональных требования, которые могут быть использованы во всех проектах.

7. В чем ценность DevOps?

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

Быстрое время выхода на рынок

В 2007 году в IT Process Institute, мы тестировали более 1500 ИТ организаций и пришли к выводу, что высокопроизводительные ИТ организации были в среднем на 5-7x порядков более производительными, чем их невысокопроизводительные сверстники. Они делали в 14 раз больше изменений, получая проблемы только половине случаев, при этом имея скорость исправления проблем с первого раза в 4 раза выше, а также имели в 10 раз более короткие периоды простоя. У них было в 4 раза меньше результатов повторного аудита, они в 5 раз чаще находили нарушения за счет автоматизированной системы внутреннего контроля, и в 8 раз лучше укладывались в сроки проекта.

Одной из характеристик высокопроизводительных команд состоит в том, что они уходят далеко вперед от толпы. Другими словами, лучшее становится еще лучше. Это происходит в области темпов развертывания приложения. Accenture недавно провели исследование о том, что делают интернет-компании, и Amazon пошла на рекорд, заявив, что они делают более 1000 развертываний в день, поддерживая скорость успешных изменения 99,999%!

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

Без сомнения, если я работаю в организации, где я могу сделать только одно развертывание каждые девять месяцев, и мой конкурент может сделать 10 установок в день, у меня есть значительные, структурные конкурентные недостатки.

Высокие темпы развертывания позволяют проводить эксперимент быстро и практически непрерывно. Скотт Кук, основатель Intuit, был одним из самых ярых сторонников „безудержной инновационной культуры“ на всех уровнях организации. Один из моих любимых примеров приводится ниже:

»Каждый сотрудник [должен быть в состоянии] проводить быстрые, высоко-скоростные эксперименты… Дэн Маурер руководит нашим потребительским подразделением, в том числе запуск веб-сайта TurboTax. Когда он начинал работу над этим проектом, мы сделали около семи экспериментов за год. За счет внедрения инновационной культуры, они сейчас делают 165 экспериментов в течение трех месяцев налогового сезона. Бизнес результат? Коэффициент конверсии веб-сайта составляет до 50 процентов. Результат для сотрудников? Люди просто любят его, потому что теперь их идеи могут попасть рынок «.

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

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

Уменьшение количества потерь IT-отдела

Mike Orzen и я как-то говорили об огромных потерях в IT стриме, вызванными длительными сроками простоя, медлительной передачей работ, незапланированными работами и переделками. Для статью Michael Krigsman мы оценили, сколько полезной деятельности мы могли бы вернуть путем применения принципов DevOps.

Мы подсчитали, что если бы мы могли просто сократить вдвое количество IT потерь, а также перераспределять эти деньни таким образом, что сможем вернуться в пять раз больше чем было вложено, мы бы производили $ 3 триллионов долларов полезной деятельности в год. Это ошеломляющее количество денег и возможностей, которым мы позволяем ускользнуть из наших рук. Это 4,7 процента от ежегодного мирового ВВП, или больше, чем весь объем производства Германии.

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

Однако, существует еще другой тип потерь. Люди в большинстве ИТ-организаций часто чувствуют себя обойденными вниманием и полными разочарования. Люди чувствуют, как будто они в ловушке вечно повторяющегося фильма ужасов и беспомощны, чтобы изменить финал. Менеджмент отрекается от своей ответственности за IT, что часто приводит к бесконечным войнам между разработкой, ИТ и отделами информационной безопасности. И все становится только хуже, когда аудиторы вскрывают все это. Жизнь ИТ-специалистов часто деморализована и полна разочарований, что, как правило, приводит к чувству бессилия и наполняет стрессами, которые проникают в каждый аспект жизни.

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

DevOps — автоматизируй всё / Хабр

Целью статьи является дать основные представления о DevOps и практиках, используемых при этой методологии. Тут не будет сложных терминов, конкретных продуктов и road map внедрения DevOps, но, надеюсь, будет интересно ознакомиться.

Как такового, определения DevOps нет, и все понимают эту методологию по-разному. Декларируемая цель – убрать барьеры между DEVelopment и OPerations. Поэтому часто DevOps понимают как то, что operations, QA и development находятся в одной команде, сидят в одном помещении, проводят общие митинги, общаются. Само по себе сближение и неформальное общение членов команды всегда полезно и уже это может привести к улучшению результатов. Но есть и формальные практики, следование которым позволяет улучшить поставку релизов, а значит и удовлетворение бизнеса.

Здесь описаны следующие:

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

Структура статьи построена следующим образом: перечислены практики, дано их описание, приведено Бизнес-Значение практики (то, как внедрение этого подхода улучшит жизнь бизнеса) и Измеримость (как можно измерить улучшение). И Бизнес-значение, и Измеримость также взяты из презентаций «DevOps-Fundamentals».

Ну что же, приступим. Процесс разработки и поставки ПО состоит из следующих шагов:

Начинается все с планирования. Планирование релиза, разработки, тестирования, развертывания. Пропустим этот шаг, так как development и operations в этом шаге не задействованы. После того, как разработчик закончил реализацию некоторого участка кода, он сохраняет (commit’ит) его в систему контроля версий. После этого вступает в дело первая практика:

Непрерывная интеграция (Continuous Integration) — это практика разработки программного обеспечения, которая заключается в слиянии рабочих копий в общую основную ветвь разработки несколько раз в день и выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. Wiki

Собственно, что такое Continuous Integration? Процесс происходит примерно так: разработчик, после того, как завершил свою задачу и отладился, сохраняет свои изменения в рабочюю копию (TFS, SVN, Git). Дальше в действие вступает некий робот (TFS, TeamCity, что-либо еще), отслеживающий изменение рабочей версии. Он видит, что рабочая копия изменилась и запускает сборку проекта. По результатам сборки, оповещается разработчик (и другие заинтересованные лица) о том, прошло все успешно или нет. Оповещение может быть через письмо, сообщение в трее, или отобразиться на web-странице. Таким образом, если сборка прошла с ошибкой, то разработчик сразу же узнает об этом.

Бизнес значение

• Ускорение поставки (Accelerate Delivery) – достигается тем, что мы сразу же узнаем об ошибке сборки и, соответственно, можем быстрее начать её исправлять.
• Повторяемость (Repeatability) — весь процесс повторяем, то есть если никаких изменений не произошло, то и сборка будет так же успешна (или не успешна). Нет такой проблемы как то, что у одного разработчика все собирается, а у другого – нет.
• Оптимизация ресурсов (Optimized Resources) — нет необходимости вручную запускать сборку, на компьютере человека или билд сервере, нет необходимости готовить сборку – выкачивать исходники из source control и т.п.

Измеримость

• Время развертывания (Deployment Lead Time) – время, необходимое на сборку проекта.
• MTTR (Mean Time To Repair — среднее время восстановления работоспособности). Можно измерить время, прошедшее от сообщения об ошибочной сборке, до исправления, убирающего ошибку.
• MTTD (Mean Time To Detect – среднее время обнаружения неисправности). измеряется время, которое прошло от внесения ошибки, до определения, что возникла проблема и в чем она заключается.

Автоматизированное тестирование – это процесс верификации программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, выполняются автоматически при помощи инструментов для автоматизированного тестирования ©.

После того, как сборка собрана, её нужно проверить. Наиболее быстро это можно сделать с помощью автоматических тестов. Для этого используются различные инструменты: это могут быть Unit тесты, UX тесты, интеграционные тесты. Главное условие – они не должны требовать участия человека. С помощью авто-тестов мы сразу получаем информацию о том, есть ли ошибки в нашей сборке. И сразу же можем начать их исправлять, не дожидаясь результатов ручного тестирования.

Бизнес значение

• Ускорение поставки (Accelerate Delivery). Мы быстрее получаем информацию о том, валидна ли сборка и можно ли её выпускать.
• Повторяемость (Repeatability) – тест всегда запускается в одной и той же последовательности, по одному и тому же сценарию, поэтому и результат будет одинаков.
• Оптимизация ресурсов (Optimized Resources). Автоматические тесты дешевле ручного за счет того, что их выполнение гораздо дешевле, чем проверка с помощью ручного тестирования.

Измеримость

• Время развертывания (Deployment Lead Time) – время, необходимое на развертывание (сборку, проверку).
• MTTR – В данном случае, измеряется время от диагностирования ошибки до её исправления (успешного прохождения теста).
• MTTD – так как тесты автоматические, то можно измерить время от сборки проекта до получения отчета об ошибке по результатам тестирования.

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

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

Для переменных, специфичных для различных сред (Dev, Stage, Production) используются синонимы, подменяемые при развертывании на реальные значения. Примером такой подмены может служить технология transform, используемая для изменения конфигурационных файлов .NET приложений.

Привычки (Habits)

• Production first mindset — в первую очередь — производство (производственное мышление). Производство является сердцем любой организации, поставщика программного обеспечения, и лучшие из них признают, что производство должно быть главным приоритетом каждого члена команды, каждой роли, а не только IT. Промежуточные артефакты, такие как документация и pre-Prod окружение недостаточно. Высоко мотивированные исполнители всегда отслеживают жизненный статус, устраняют жизненные проблемы и первопричины, а также активно выявляют проблемы в производительности и работе ПО.
• Инфраструктура как гибкий ресурс — Infrastructure as flexible resource.

Бизнес значение

• Оптимизация ресурсов (Optimized Resources) — оптимизация ресурсов за счет более быстрого развертывания: нет необходимости вручную править конфигурации, особенно если серверов много.
• Ускорение поставки (Accelerate Delivery). Компьютер быстрее изменит и настроит конфигурацию.

Измеримость

• Скорость развертывания (Deployment Rate). Измеряется время развертывания приложения.
• MTTR – (Mean Time To Repair). Время на восстановление.

Непрерывная развертывание – объединение Continuous Integration (непрерывной интеграции) и Continuous Delivery (непрерывной поставки). Это следующий шаг после успешной сборки и успешного прохождения автоматических тестов (и, возможно, установки галочки «сборка готова к развертыванию» ответственным человеком). Если вы уверены в ваших тестах, их наборе и покрытии, при их успешном выполнении запускается автоматическая установка на соответствующую среду, тестовую или продуктовую. Разница между Continuous Integration, Delivery, Deployment хорошо описана тут: http://blogs.atlassian.com/2014/04/practical-continuous-deployment/

Бизнес значение

• Оптимизация ресурсов (Optimized Resources ). Участие человека сведено к минимуму.
• Ускорение поставки (Accelerate Delivery). Машина быстрее все установит, чем человек.

Измеримость

• Частота поставки (Deployment Frequency). Измеряется количество установок в единицу времени (день, неделя, месяц, год).
• MTTR
• Доступность (Availability).

Управление релизами (Release Management)

Управление релизом заключается в том, что мы определяем формальные критерии, готова ли сборка к установке на соответствующую среду. Примером критериев, по которым сборка готова, и, если они выполняются, автоматически запускается поставка (Continuous Deployment) могут быть:

• DEV среда – сборка прошла без ошибок.
• STAGE среда – сборка была установлена на DEV среде и unit тесты прошли успешно.
• PROD среда – сборка прошла тестирование на STAGE среде, есть не более 5% minor багов, major багов нет, QA Lead и Dev Lead поставили Confirm билду о готовности к PROD среде.

Полезная ссылка: Управление релизами в Visual Studio 2013.

Бизнес значение

• Оптимизация ресурсов (Optimized Resources). Ресурсы, требуемые для определения готовности сборки (и её установки) всегда известны и их можно оптимизировать.
• Ускорение поставки (Accelerate Delivery). Мы быстрее и штатно (по строго определенным правилам) можем определить, готова ли сборка к поставке.

Измеримость

• Частота поставки (Deployment Frequency).
• MTTR
• Доступность (Avaibility).

Управление конфигурациями (Configuration Management) — это детальная запись и обновление информации, описывающей ПО и оборудование предприятия. Такая информация обычно включает версии и апдейты, которые были применены к установленному ПО, а также местоположение и сетевые адреса оборудования. ©

Здесь к формальному определению добавить особо и нечего. Все должно быть записано и подсчитано.

Бизнес значение

• Faster Detection & Remediation – более быстрое определение проблемы и восстановление.
• Оптимизация ресурсов (Optimized Resources).
• Большая гибкость.

Измеримость

• MTTD
• MTTR
• Доступность

Нагрузочное тестирование (load testing) — подвид тестирования производительности, сбор показателей и определение производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству) Wiki

Часто происходит так, что, например, для web приложений, когда пользователь один (разработчик или тестировщик) страница быстро открывается у и хорошо реагирует на работу с ней. Но как только изменения попадают на продуктовый сервер, и эту же страницу начинают смотреть сотни, тысячи человек одновременно, страница долго грузится и перестаёт реагировать.

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

Бизнес значение

• Увеличение качества поставки (Improve deployment quality). Мы всегда можем быть уверены, что устанавливаемая сборка отвечает критериям производительности и не ухудшает их.
• Поиск «бутылочного горлышка» производительности (Find performance bottlenecks). Диагностирование, какое место является проблемным с точки зрения производительности и как её можно решить на ранней стадии, до жалоб клиентов.
• Cater for demand – удовлетворение заказчика от постоянного качества продукта.
• Поддержание качества приложения (Maintain application quality).

Измеримость

• Availability – доступность приложения.
• MTTD
• MTTR

Мониторинг быстродействия приложения (application performance management) – это мониторинг и управление быстродействием и доступностью ПО. APM стремится выявлять и диагностировать проблемы быстродействия комплексно, для поддержания ожидаемого уровня обслуживания Wiki

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

Бизнес значение

• Faster Detection & Remediation- более быстрое определение проблемы и восстановление. Мы быстрее узнаем об узких местах, возникший в продуктовой системе.
• Optimized Resources – оптимизация ресурсов. Можем перераспределить вычислительные ресурсы со служб, где они мало задействованы, на загруженные службы.
• More Resilience – большая гибкость. То же самое, что и в предыдущем пункте: балансировка нагрузки.

Измеримость

Надеюсь, данная статья дала вам представление, что такое DevOps и что нужно сделать для улучшения жизни developers, operations и business.

создание цепочек DevOps с помощью инструментов с открытым исходным кодом / Блог компании Southbridge / Хабр

Создание первой цепочки DevOps за пять шагов для новичков.

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

Мое знакомство с DevOps

Когда-то я работал с облаками в Citi Group и разрабатывал веб-приложение IaaS, чтобы управлять облачной инфраструктурой Citi, но мне всегда было интересно, как можно оптимизировать цепочку разработки и улучшить культуру среди разработчиков. Грег Лавендер, наш техдиректор по облачной архитектуре и инфраструктуре, посоветовал мне книгу Проект «Феникс». Она прекрасно объясняет принципы DevOps, при этом читается, как роман.

В таблице на обороте показано, как часто компании выкатывают новые версии:

Как Amazon, Google и Netflix успевают столько выкатывать? А все просто: они поняли, как создать почти идеальную цепочку DevOps.

У нас в Citi все было совсем не так, пока мы не перешли на DevOps. Тогда у моей команды были разные среды, но поставку на сервер разработки мы делали вручную. У всех разработчиков был доступ только к одному серверу разработки на базе IBM WebSphere Application Server Community Edition. При одновременной попытке поставки сервер “падал”, а нам приходилось каждый раз “болезненно” договариваться между собой. А еще у нас было недостаточное покрытие кода тестами, трудоемкий ручной процесс поставки и никакой возможности отслеживать поставку кода по некоторой задаче или требованию клиента.

Было понятно, что нужно срочно что-то делать, и я нашел коллегу-единомышленника. Мы решили вместе создать первую цепочку DevOps — он настроил виртуальную машину и сервер приложений Tomcat, а я занялся Jenkins, интеграцией с Atlassian Jira и BitBucket, а также и покрытием кода тестами. Проект был успешным: мы полностью автоматизировали цепочку разработки, добились почти 100% бесперебойной работы сервера разработки, могли отслеживать и улучшать покрытие кода тестами, а ветку Git можно было привязать к поставке и задаче Jira. И почти все инструменты, которыми мы строили цепочку DevOps, были открытым исходным кодом.

По факту, цепочка была упрощенной, ведь мы даже не применяли расширенные конфигурации с помощью Jenkins или Ansible. Но у нас все получилось. Возможно, это следствие принципа Парето (он же правило 80/20).

Краткое описание цепочки DevOps и CI/CD

У DevOps есть разные определения. DevOps, как и Agile, включает в себя разные дисциплины. Но большинство согласятся с следующим определением: DevOps — это метод, или жизненный цикл, разработки ПО, главный принцип которого — создание культуры, где разработчики и другие сотрудники “на одной волне”, ручной труд автоматизирован, каждый занимаются тем, что лучше всего умеет, возрастает частота поставок, повышается продуктивность работы, увеличивается гибкость.

И хотя одних только инструментов недостаточно для создания среды DevOps, без них не обойтись. Самым важным из них является непрерывная интеграция и непрерывная поставка (CI/CD). В цепочке для каждого окружения есть разные этапы (например, DEV (разработка), INT (интеграция), TST (тестирование), QA (контроль качества), UAT (приемочное тестирование пользователями), STG (подготовка), PROD (использование)), ручные задачи автоматизированы, разработчики могут делать качественный код, делают его поставку и могут легко перестраиваться.

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

Перейдем к делу.

Шаг 1: Платформа CI/CD

Первым делом вам нужен инструмент CI/CD. Jenkins — это открытый инструмент CI/CD написанный на Java с лицензией MIT, с которого началась популяризация движения DevOps и который де-факто стал стандартом для CI\CD.

А что такое Jenkins? Представьте, что у вас есть волшебный пульт управления для самых разных сервисов и инструментов. Сам по себе инструмент CI/CD, типа Jenkins, бесполезен, но с разными инструментами и сервисами он становится всемогущим.

Кроме Jenkins есть множество других открытых инструментов, выбирайте любой.

Вот как выглядит процесс DevOps с инструментом CI/CD

У вас в localhost есть инструмент CI/CD, но делать пока особо нечего. Перейдем к следующему шагу.

Шаг 2: управление версиями

Лучший (и, пожалуй, самый простой) способ проверить магию инструмента CI/CD — интегрировать его с инструментом контроля версий (source control management, SCM). Зачем нужен контроль версий? Допустим вы делаете приложение. Вы пишете его на Java, Python, C++, Go, Ruby, JavaScript или на любом другом языке, коих вагон и маленькая тележка. То, что вы пишете, называется исходным кодом. Поначалу, особенно если вы работаете в одиночку, можно сохранять все в локальный каталог. Но когда проект разрастается и к нему присоединяется больше людей, вам нужен способ делиться изменениями в коде, но при этом избежать конфликтов при слияниях изменений. А еще вам нужно как-то восстанавливать предыдущие версии без использования резервных копий и применения метода copy-paste для файлов с кодом.

И тут без SCM никуда. SCM сохраняет код в репозиториях, управляет его версиями и координирует его среди разработчиков.

Инструментов SCM немало, но стандартом де-факто заслуженно стал Git. Я советую использовать именно его, но есть и другие варианты.

Вот как выглядит пайплайн DevOps после добавления SCM.

Инструмент CI/CD может автоматизировать загрузку и выгрузку исходного кода и совместную работу в команде. Неплохо? Но как теперь из этого сделать рабочее приложение, любимое миллиардами пользователей?

Шаг 3: инструмент автоматизации сборки

Все идет как надо. Вы можете выгружать код и фиксировать изменения в системе контроля версий, а также пригласить друзей поработать с вами. Но приложения у вас пока нет. Чтобы это было веб-приложение, его нужно скомпилировать и поместить в пакет для поставки или запустить как исполняемый файл. (Интерпретируемый язык программирования, вроде JavaScript или PHP, компилировать не надо.)

Применяйте инструмент автоматизации сборки. Какой бы инструмент вы ни выбрали, он будет собирать код в нужном формате и автоматизировать очистку, компиляцию, тестирование и поставку. Инструменты сборки бывают разные в зависимости от языка, но обычно используются следующие варианты с открытым кодом.

Превосходно! Теперь вставим файлы конфигурации инструмента автоматизации сборки в систему контроля версий, чтобы инструмент CI/CD их собрал.

Вроде, все нормально. Но куда теперь все это выкатить?

Шаг 4: сервер веб-приложений

Итак, у вас есть запакованный файл, который можно исполнять или выкатывать. Чтобы приложение действительно приносило пользу, у него должен быть какой-то сервис или интерфейс, но вам нужно где-то это все разместить.

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

Есть несколько открытых серверов веб-приложений.

У нас уже получился почти рабочая цепочка DevOps. Отличная работа!

В принципе, здесь можно остановиться, дальше вы справитесь сами, но стоит еще рассказать о качестве кода.

Шаг 5: Тестовое покрытие

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

Тестирование разделено на две части: фреймворки тестирования, чтобы писать и выполнять тесты, и инструменты с подсказками по повышению качества кода.

Фреймворки тестирования

Инструменты с подсказками по качеству

Большинство этих инструментов и фреймворков написаны для Java, Python и JavaScript, потому что C++ и C# — проприетарные (хотя у GCC открытый исходный код).

Инструменты тестового покрытия мы применили, и теперь пайплайн DevOps должен выглядеть, как на рисунке в начале руководства.

Дополнительные шаги

Контейнеры

Как я уже говорил, сервер приложений можно разместить на виртуальной машине или сервере, но контейнеры более популярны.

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

Для контейнеров обычно берут Docker и Kubernetes, хотя есть и другие варианты.

Почитайте статьи о Docker и Kubernetes на Opensource.com:

Инструменты автоматизации промежуточного ПО

Наша цепочка DevOps ориентирована на совместную сборку и поставку приложения, но с инструментами DevOps можно делать и другие интересные штуки. Например, использовать инструменты «инфраструктура как код» (IaC), которые еще называются инструментами автоматизации промежуточного ПО. Эти инструменты помогают автоматизировать установку, управление и другие задачи для промежуточного ПО. Например, инструмент автоматизации может брать приложения (сервер веб-приложений, базу данных, инструменты мониторинга) с правильными конфигурациями и выкатывать их на сервер приложений.

Вот несколько вариантов открытых инструментов автоматизации промежуточного ПО:

Подробности в статьях на Opensource.com:

И что теперь?

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

Вот еще несколько хороших статей о DevOps для начинающих:

А еще можно интегрировать DevOps с открытыми инструментами для agile:

Что и кто такое DevOps?

В жизни каждого приличного успешного проекта наступает момент, когда количество серверов начинает стремительно увеличиваться. Сервер с приложением перестаёт справляться с нагрузкой и приходится вводить в строй ещё несколько серверов и ставить перед ними балансировщик. База данных, прежде спокойно жившая на сервере с приложением, разрослась и нуждается не просто в отдельной машинке, но и ещё в одной для надёжности и бо́льшей скорости работы. Внутренняя команда теоретиков вдруг прослышала про микросервисы и теперь вместо проблемы одного монолита появляется много микропроблем.

Не успеешь и глазом моргнуть, как количество серверов ушло далеко за несколько десятков, каждый из которых нужно мониторить, с каждого нужно собирать логи, каждый нужно защищать от внутренних (“ой, я случайно дропнул базу”) и внешних угроз.

Зоопарк используемых технологий растёт после каждого совещания программистов, которые хотят поиграться с ElasticSearch, Elixir, Go, Lotus и бог знает с чем ещё.

Прогресс тоже не стоит на месте: редок месяц без важного обновления используемого софта и операционной системы. Ещё вчера ты жил спокойно с SysVinit, но теперь тебе говорят что нужно использовать systemd. И ведь правда нужно.

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

A system administrator, or sysadmin, is a person who is responsible for the upkeep, configuration, and reliable operation of computer systems; especially multi-user computers, such as servers.

Все эти проблемы далеко не новы – умелые сисадмины вовремя подтянули знания программирования и автоматизировали всё по-максимуму, походу дела подарив миру такие инструменты, как, например, Chef и Puppet. Но возникла проблема: далеко не все сисадмины оказались достаточно умелыми, чтобы переквалифицироваться в настоящих инженеров сложных инфраструктур.

Более того, программисты, по-прежнему слабо представляющие, что происходит с их приложениями после деплоя, упорно продолжают считать сисадминов виновными в том, что новая версия софта съела весь CPU и открыла двери нараспашку всем хакерам мира. “Мой код идеален, это вы хреново сервера крутите”, – говорили они.

В такой непростой ситуации инженерам и сочувствующим пришлось заниматься просветительской деятельностью. А какая может быть просветительская деятельность без модного словечка? Так и появился DevOps – маркетинговый термин, вызывающий у людей совершенно разные ассоциации, от “культура внутри организации” до “мастер на все руки”.

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

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

Так же в сферу DevOps включают такие темы как Continuous Integration, Continuous Delivery и т. п. Мы уже однажды немножко рассказывали о CI в статье Непрерывная интеграция, Jenkins и Middleman.

Естественным путём DevOps из разряда “культуры” и “идеологии” переместился в разряд “профессии”. Рост вакансий с этим словом внутри стремительно растёт. Но что же ждут от DevOps-инженера рекрутёры и компании? Зачастую от него ждут смеси таких навыков как системное администрирование, программирование, использование облачных технологий и автоматизация крупной инфраструктуры.

Это означает, что нужно не только быть хорошим программистом, но так же идеально разбираться в том, как работают сети, операционные системы, виртуализация, как обеспечить безопасность и отказоустойчивость, а так же несколько десятков различных технологий, начиная от основных и проверенных временем вещей как iptables и SELinux и заканчивая более свежими и модными ранее упомянутыми технологиями как Chef, Puppet или даже Ansible.

Здесь внимательный читатель-программист скажет:

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

Другой внимательный читатель-сисадмин скажет:

Я отлично умею пересобирать ядро Linux и настраивать сеть, зачем мне учиться программировать, зачем мне ваши Chef, git и прочий странный зоопарк?

На это мы скажем: настоящий инженер должен уметь не Ruby, Go, Bash или “настраивать сеть”, а уметь строить сложные, красивые, автоматизированные и безопасные системы, и понимать как они работают от самого низкого уровня вплоть до генерации и отдачи HTML-страничек в браузер.

Конечно, мы частично согласны, что нельзя быть абсолютном профессионалом во всех сферах IT в каждый конкретный момент времени. Но ведь и DevOps – это не только о людях, умеющих всё делать хорошо. Это так же о максимальной ликвидации безграмотности по обе стороны баррикад (на самом деле являющихся одной командой), будь ты уставшим от ручной работы сисадмином или молящимся на AWS разработчиком.

В этой серии статей мы шаг за шагом будем знакомиться с основными инструментами и технологиями современного DevOps-инженера.

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

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

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

Для работы тебе обязательно понадобится Linux. Мы очень сильно настаиваем на Red Hat дистрибутивах. Автор статьи сам в качестве основной системы использует Fedora 27 Workstation, а сервера mkdev крутятся на Centos 7.

В следующей статье мы ознакомимся с виртуализацией: узнаем зачем она нужна и как и при помощи чего ей пользоваться.

Что такое DevOps? | гибкий админ

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

Определение DevOps

DevOps — это новый термин, возникший в результате столкновения двух основных взаимосвязанных тенденций. Первый также назывался «гибкая инфраструктура» или «гибкие операции»; он возник в результате применения подходов Agile и Lean к операционной работе. Второй — это значительно более широкое понимание ценности сотрудничества между персоналом разработки и эксплуатации на всех этапах жизненного цикла разработки при создании и эксплуатации сервиса, а также того, насколько важными стали операции в нашем все более ориентированном на сервисы мире (см.Шеф: Новый секретный соус).

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

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

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

Основным следствием этого является то, что часть основного изменения практики по сравнению с предыдущими методами составляет

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

Эти методы могут варьироваться от использования системы контроля версий до тестирования и участия в процессе гибкой разработки.

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

DevOps тесно связан с подходами Agile и Lean. Старый взгляд на операции имел тенденцию к тому, что сторона «Dev» была «создателями», а сторона «Ops» — «людьми, которые занимались творением после его рождения» — осознанием вреда, нанесенного индустрии эти две проблемы, рассматриваемые как разрозненные, являются основным драйвером DevOps.Таким образом, DevOps можно интерпретировать как продукт Agile — гибкая разработка программного обеспечения требует тесного сотрудничества с клиентами, менеджментом продукта, разработчиками и (иногда) QA, чтобы заполнить пробелы и быстро перейти к лучшему продукту — DevOps говорит: «Да , но предоставление услуг и то, как приложение и системы взаимодействуют, также являются фундаментальной частью ценностного предложения для клиента, поэтому производственной группе необходимо включить эти проблемы в качестве элемента верхнего уровня ». С этой точки зрения DevOps просто расширяет принципы Agile за рамки «кода» на всю предоставляемую услугу.

Подробное определение

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

• Agile Values ​​ — Философия высшего уровня, обычно согласованная для воплощения в Agile Manifesto. Это основные ценности, которые определяют Agile.
• Agile Principles — В целом согласованные стратегические подходы, поддерживающие эти ценности.Agile Manifesto цитирует дюжину этих более конкретных принципов. Необязательно покупать все из них, чтобы стать Agile, но если вы не подписаны на многие из них, вероятно, вы занимаетесь чем-то другим.
• Agile Methods — Более конкретные процессы реализации принципов. XP, Scrum, ваш собственный доморощенный процесс — вот где философия уступает место практическим сценариям «как мы собираемся делать это в реальной жизни». Ни один из них не является обязательным, только возможные реализации.
• Agile Practices — узкоспециализированные тактические приемы, которые обычно используются в сочетании с гибкими реализациями. Ни от одного из них не требуется быть гибким, но многие гибкие реализации оценили их использование. Стендапы, покер планирования, резервные журналы, CI, все специфические артефакты, которые разработчик использует для выполнения своей работы.
• Agile Tools — Конкретные технические реализации этих практик, используемые командами для облегчения выполнения своей работы в соответствии с этими методами.JIRA Agile (также известный как Greenhopper), Planningpoker.com и др.

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

• DevOps Values ​​ — я считаю, что фундаментальные ценности DevOps эффективно отражены в Agile Manifesto — возможно, с одной небольшой поправкой, чтобы сосредоточиться на общей услуге или программном обеспечении, полностью предоставляемом клиенту, а не просто на «рабочем программном обеспечении».Некоторые предыдущие определения DevOps, такие как слова Алекса Хонора «Люди важнее процессов, а не инструменты», перекликаются с основными заявлениями Agile Manifesto и призывают к сотрудничеству между разработчиками и операторами.
• Принципы DevOps — Нет единого согласованного списка, но есть несколько широко признанных попыток — вот Джон Уиллис, придумавший «CAMS», и вот Джеймс Тернбулл, дающий свое собственное определение на этом уровне. «Инфраструктура как код» — это часто цитируемый принцип DevOps. Я сделал сокращение «DevOps’ing» существующего манифеста и принципов Agile здесь.Я лично считаю, что DevOps на концептуальном уровне — это в основном просто расширение принципов Agile для включения систем и операций вместо того, чтобы избавляться от проблем при проверке кода.
• DevOps Methods — Некоторые методы здесь такие же; вы можете использовать Scrum с операциями, Kanban с операциями и т. д. (хотя обычно больше внимания уделяется интеграции операций с разработчиками, QA и продуктом в продуктовых группах). Есть еще несколько различных методов, таких как контроль изменений в стиле Visible Ops и использование системы управления инцидентами для реагирования на инциденты.Набор этих методологий растет; Например, более продуманный подход к мониторингу — это область, в которой общие методологии не имеют четкого определения.
• DevOps Practices — Конкретные методы, используемые как часть реализации вышеуказанных концепций и процессов. Непрерывная интеграция и непрерывное развертывание: «Дайте своим разработчикам пейджер и позвольте им позвонить», используя управление конфигурацией, метрики и схемы мониторинга, подход к инструментарию с помощью цепочки инструментов … Даже использование виртуализации и облачных вычислений является обычной практикой, используемой для ускорения изменений в современный мир инфраструктуры.
• DevOps Tools — Инструменты, которые вы будете использовать при соблюдении этих принципов. В мире DevOps наблюдается бурный рост выпускаемых инструментов (jenkins, travis, teamcity), управления конфигурацией (puppet, chef, ansible, cfengine), оркестрации (zookeeper, noah, mesos), мониторинга, виртуализации и контейнеризации (AWS, OpenStack , бродяга, докер) и многое другое. Хотя, как и в случае с Agile, неверно говорить, что инструмент является «инструментом DevOps» в том смысле, что он волшебным образом принесет вам DevOps, безусловно, существуют специальные инструменты, которые разрабатываются с явной целью облегчить выполнение вышеуказанных принципов, методов и практик. , и целостное понимание DevOps должно включать этот уровень.

В конце концов, DevOps немного сложно определить, как и его старший брат Agile. Но это того стоит. Оставшись на уровне чистой философии, оба могут показаться пустыми утверждениями типа «мама и яблочный пирог», подверженные критике: «Ты просто говоришь мне:« делай мою работу лучше », да…» Но, наоборот, просто практики без руководство высшего уровня превратилось в культ карго. «Я делаю то, что написано в этой книге по Scrum, поэтому я занимаюсь Agile» так же ошибочно, как «Я использую Chef, значит, я DevOps, верно?» Чтобы быть успешным практиком Agile или DevOps, необходимо понимать все уровни, которые в них входят, и что данная реализация DevOps может содержать или не содержать.В конце концов, то, что DevOps надеется привнести в Agile, — это понимание и практика того, что программное обеспечение не создается до тех пор, пока оно не будет успешно доставлено пользователю и не будет соответствовать его ожиданиям в отношении доступности, производительности и скорости изменений.

В частности, я пришел к выводу, что есть три основные области практики, которые обычно обсуждаются в контексте DevOps.

• Автоматизация инфраструктуры — создавайте свои системы, конфигурации ОС и развертывания приложений в виде кода.
• Непрерывная доставка — создавайте, тестируйте и развертывайте свои приложения быстро и автоматически.
• Site Reliability Engineering — управляйте своими системами; конечно, мониторинг и оркестровка, но в первую очередь проектирование для удобства работы.

История DevOps

Возникновение DevOps связано с растущей потребностью в инновациях в области системных технологий. Движение DevOps унаследовано от движения Agile System Administration и движения Enterprise Systems Management (ESM).

ESM, появившийся в середине 2000-х годов, послужил первоначальным толчком к заявлению: «Эй, наша методология работы с системами, кажется, все еще находится в довольно примитивном состоянии, несмотря на годы усилий.Давай поговорим о том, чтобы сделать это лучше «. Джон Уиллис, Уёрли и Марк Хинкль из Zenoss участвовали в этом и спонсировали BarCamp вокруг этой концепции. Я думаю, что на этом этапе первоначальное восхищение ITIL как структурой управления было в значительной степени опровергнуто подходом «ITIL Lite» Visible Ops, а также переходом от ориентации на «крупных поставщиков» — раньше это были корпоративные инфраструктуры, такие как HP, IBM и CA были единственными значимыми решениями для непрерывного управления системами, но выходило все больше продуктов с открытым исходным кодом и более мелких поставщиков, включая Spiceworks, Hyperic, Zenoss и другие.

Также в 2008 году O’Reilly провела первую конференцию Velocity, на которой основное внимание было уделено производительности и операциям в Интернете, которая предоставила площадку для обмена информацией о передовых методах работы. В 2009 году было проведено несколько важных презентаций о сотрудничестве разработчиков и операторов в крупных магазинах (особенно на Flickr) и о том, как это способствовало безопасным и быстрым изменениям в веб-средах. Инструменты обеспечения, такие как Puppet и Chef, хорошо зарекомендовали себя здесь. Все больше людей задумывались об этих новых концепциях и задавались вопросом, как бы они могли их реализовать.

В некоторой степени параллельно, когда рост agile-разработки в сфере разработки достигал своего наиболее лихорадочного пика и переходил от ниши к общепринятой практике, это превратилось в размышления об «администрировании гибких систем», особенно в Европе. Гордон Баннер из Великобритании говорил об этом в начале своей презентации. В центре внимания этого движения были процессы и аналогии от процессов канбан и бережливого производства до администрирования ИТ-систем. Затем в 2009 году Патрик Дебуа из Бельгии и Эндрю «Клэй» Шафер из США встретились и начали обсуждать (и придумали термин) DevOps, а затем Патрик провел первое мероприятие DevOpsDays в Генте, которое зажгло фитиль.Теперь, когда у него было название, концепция стала больше обсуждаться в других местах (я узнал о ней на OpsCamp Austin), включая Velocity и DevOpsDays здесь, в США, и быстро распространилась.

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

DevOps возникла из «идеального шторма», когда все эти вещи объединились. Растущий подход к автоматизации и цепочке инструментов, подкрепленный более хорошими инструментами мониторинга и обеспечения, необходимостью в гибких процессах и совместной работе разработчиков и операторов, а также неудачи крупных / тяжелых реализаций ITSM / ITIL — они столкнулись и бессознательно соединили все три уровня того, что вам нужно для гибкого движения (принципы, процессы и практики) и загорелся. С тех пор он получил дальнейшее развитие, в первую очередь за счет включения принципов бережливого производства многими лидерами мнений.

Чем не является DevOps?

Это не NoOps

Это не «они забирают нашу работу!» Некоторые думают, что DevOps означает, что разработчики берут на себя операции и делают это сами. Частично это правда, а частично нет.

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

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

Это не просто инструменты

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

Аналогичным образом, практикующие Agile-практики скажут вам, что простое начало работы в итерациях или принятие других конкретных практик без начала конструктивного сотрудничества, скорее всего, не сработает. В компаниях, в которых я работал, есть команды, которые переняли некоторые методы и / или инструменты гибкой разработки, но не ее принципы, и результаты оказались неоптимальными.Конечно, инструмент может быть полезен в Agile (или DevOps), но если вы не знаете, как им пользоваться, это все равно, что дать штурмовое оружие неподготовленному человеку.

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

Это не (просто) культура

Многие люди настаивают, что DevOps — это «просто культура», и вы не можете применить это слово к данному принципу или практике, но мне кажется, что это преувеличено и неверно. Agile не помог тысячам разработчиков, потому что работа над ним остановилась на «культуре», с увещеваниями обнимать коллег и ведущих практиков, которые определили лучшие практики, просто заявив, что все это самоочевидно, и отказались быть более предписывающими.(Хотя кое-что из этого есть). DevOps состоит из элементов на всех уровнях, которые я перечисляю выше, и в значительной степени бесполезен без ощутимой практики, которая сложилась вокруг него. Возможно, вам удастся выяснить все эти передовые методы самостоятельно, учитывая культурную направленность и много времени для экспериментов, но обмен информацией — вот почему у нас есть Интернет (и печатный станок, если на то пошло).

Это не (просто) разработчики и операторы

И, в конце концов, это не исключение. Некоторые люди жаловались: «А как же охранники! И сетевые админы! Зачем оставлять нас в стороне!?! » Дело в том, что все участники создания продукта или системы должны сотрудничать с самого начала — бизнесмены разного уровня, разработчики разного уровня и операторы разного уровня, и все это включает безопасность, сеть и все остальное.Также существует множество различных бизнес-структур и заинтересованных сторон-разработчиков; Тот факт, что никто не получил конкретного призыва («Не забывайте про дизайнеров иконок!»), не означает, что они не включены в список. Первоначальные специалисты по гибкой разработке в основном думали о сотрудничестве «бизнес + разработчик», а DevOps указывает на проблемы и решения, связанные с сотрудничеством «разработка + операторы», но зрелый результат всего этого — «все сотрудничают». В этом смысле DevOps — это лишь важный шаг для одной дисциплины, чтобы присоединиться к общей культуре гибкого сотрудничества, которая должна включать все дисциплины в организации.Итак, кто бы ни участвовал в поставке программного обеспечения или услуги, он является частью DevOps.

Это не (просто) Должность

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

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

Это еще не все

Иногда DevOps увлекаются и делают грандиозные заявления, что DevOps — это «все и везде!» Поскольку DevOps во многом входит в общую структуру бережливого и гибкого мышления, и есть возможности для такого рода сотрудничества во всей организации, приятно видеть все параллели, но создание и реинжиниринг ваших бизнес-процессов на самом деле не является DevOps per se.Это часть общей, мы надеемся, совместной и гибкой корпоративной культуры, но DevOps — это именно то, как операции подключаются к этому. Некоторые люди перегибают палку и в конечном итоге превращают DevOps в сильно разбавленную версию Lean, Agile или просто любви для всех. Что замечательно на уровне видения, но по мере продвижения вниз по иерархии детализации вы в конечном итоге в основном имеете дело с операционной интеграцией — другие усилия касаются других частей (вы, конечно, можете и лично). Но есть еще много нерешенных проблем, связанных с доставкой программного обеспечения и обслуживанием услуг, а также с его быстрым, надежным, безопасным и т. Д.- если кто-то хочет использовать то, что они узнали из DevOps, чтобы стать крупным корпоративным консультантом, это нормально, но большинство людей, вовлеченных в DevOps, являются техническими практиками, которые ищут более эффективные способы выполнения своей работы, а не кого-то другого. В Agile есть «гибкая разработка программного обеспечения», а затем — более крупная гибкая организационная работа. Я думаю, что DevOps лучше всего определить как «гибкую поставку программного обеспечения и операции», которые должны аналогичным образом работать вместе с другими, работающими над более крупными организационными инициативами, но не упуская из виду его основное ценностное предложение для организации.

Начало работы с DevOps

Нет одного пути к DevOps — есть только то, что работает в вашей организации. Очень успешные инициативы DevOps были инициированы командами разработчиков и командами операторов сверху вниз и снизу вверх, внутри компании и консультантами, получившими широкое образование и участвовавшими в пилотных проектах. Поэтому сложно дать общий план действий по его реализации. Я думаю, можно с уверенностью сказать, что все начинается с того, что вы сами узнаете о ценностях, принципах, методах и практиках DevOps и пытаетесь распространить их по любому наиболее эффективному каналу — рассказывать коллегам-техническим специалистам, получать поддержку от руководства, просто начинать внедрять вещи. в большей степени DevOps и позволяя успеху говорить сам за себя … Люди будут пытаться рассказать вам, как добиться успеха в вашей организации, но этот совет обычно больше политика и принятие желаемого за действительное, чем реальность.Понаблюдайте, как другие популярные вещи в вашей организации возникли и приобрели популярность, и попробуйте те же каналы. И продолжайте учиться.

Учебные курсы LinkedIn

Поскольку мы были разочарованы состоянием образования DevOps, мы начали создавать несколько курсов с помощью lynda.com/LinkedIn Learning, чтобы помочь людям понять основные концепции DevOps! Посмотрите их:

• Основы DevOps (Джеймс, Эрнест) — трехчасовой набор видеороликов, предназначенных для ознакомления новичков со всеми аспектами DevOps.Об этом подробнее здесь!
• DevOps Foundations: Infrastructure as Code (James, Ernest) — два часа концепций автоматизации инфраструктуры с демонстрациями, иллюстрирующими их во всем, от облачной информации до шеф-повара.
• DevOps Foundations: Continuous Integration / Continuous Delivery (Джеймс, Эрнест) — все, что вам нужно знать о непрерывной интеграции и доставке, с демонстрациями в jenkins, nexus и т. Д.
• Основы DevOps: Lean и Agile (Картик, Эрнест) — Lean и Agile информируют DevOps на фундаментальном уровне, и принятие их методов будет способствовать вашему успеху.
• Основы DevOps: Разработка надежности сайта (Джеймс, Эрнест) — «Третья часть» DevOps наряду с IaC и CI / CD, это «операционная» часть операций.
• DevOps Foundations: Monitoring and Observability (Peco, Ernest) — Мониторинг — это такая огромная тема, которую мы сделали отдельно от курса SRE.

Список чтения DevOps

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

• Лучший выбор — Руководство DevOps, написанное Джином Кимом, Патриком Дебойсом, Джоном Уиллисом, Джоном Олспоу и Джезом Хамблом, вышло в конце 2016 года и, наконец, стало исчерпывающим источником информации о DevOps. Если у вас есть только одна книга, возьмите эту.
• The Phoenix Project, Джин Ким, Джордж Спаффорд, Кевин Бер — В новом формате, вдохновленном основополагающей работой по бережливому производству The Goal, это повествование о внедрении DevOps в проблемной компании-разработчике программного обеспечения.
• Веб-операции, различные — книга О’Рейли, в которой собрана серия эссе по веб-операциям, которые на самом деле являются мыслями многих ключевых пионеров DevOps.
• Continuous Delivery, Джез Хамбл и Дэвид Фарли. Хотя CI / CD не является общей суммой DevOps, как некоторые люди, это, безусловно, основная область инноваций, и это окончательная работа над ней.
• Практический подход к крупномасштабной гибкой разработке, Гэри Грувер — Для тех, кто думает, что DevOps предназначен только для стартапов или только для веб-программного обеспечения, это рассказ о том, как подразделение прошивки HP LaserJet перешло на гибкую структуру / CI / DevOps.
• Практика администрирования облачных систем, Том Лимончелли, Страта Чалуп, Кристина Хоган — учебное руководство по стилю работы со стороны эксплуатации, с множеством отличных рекомендаций по системам нового стиля и большим количеством явного контента DevOps.
• Release It !, Майкл Найгард — Подобных книг должно быть больше, в которых объясняются общие закономерности сбоев систем и шаблоны успеха — я думаю об этом как о книге «Банда четырех шаблонов проектирования» для систем.
• Lean Software Development, Мэри и Том Поппендики — Lean все больше внедряется в сообществе DevOps, но начиная с Деминга и TPS это несколько пугает.Эта книга является основополагающей работой по бережливому производству программного обеспечения.
• И завершите это еженедельным информационным бюллетенем Гарета Рашгроува DevOps Weekly.

— Эрнест Мюллер, 2 августа 2010 г. — Последняя редакция 12 января 2019 г.

.

Что такое 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). Все они принципиально включают в себя итерацию и непрерывную обратную связь, которая обеспечивает последовательное усовершенствование и поставку системы программного обеспечения. Все они включают непрерывное планирование, непрерывное тестирование, непрерывную интеграцию и другие формы непрерывной эволюции как проекта, так и программного обеспечения.Все они легкие, особенно по сравнению с традиционными процессами в стиле водопада, и по своей сути адаптируемы. И что наиболее важно в гибких методах, так это то, что все они сосредоточены на том, чтобы дать людям возможность сотрудничать и быстро и эффективно принимать решения.

Изначально agile-команды в основном состояли из разработчиков. По мере того, как эти гибкие команды становились все более эффективными и действенными в производстве программного обеспечения, стало ясно, что наличие отдельных команд по обеспечению качества (QA) и разработчикам неэффективно.Agile вырос, чтобы охватить QA, чтобы увеличить скорость доставки программного обеспечения, и теперь agile снова растет, чтобы охватить участников доставки и поддержки, чтобы расширить гибкость от идеи до доставки.

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

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

Команды

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

2. Какие проблемы решает DevOps?

До разработки приложений DevOps группы отвечали за сбор бизнес-требований к программному обеспечению и написание кода. Затем отдельная группа QA тестирует программу в изолированной среде разработки, если требования были выполнены, и выпускает код для операций для развертывания.Команды развертывания далее фрагментируются на разрозненные группы, такие как сети и базы данных. Каждый раз, когда программа «бросается через стену» независимой команде, она создает узкие места. Проблема с этой парадигмой в том, что когда команды работают отдельно:

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

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

Обычный сценарий перед DevOps

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

В конце концов, проблемы решаются, и QA отправляет отлаженный новый выпуск «через стену» в Ops. Цель команды Ops — ограничить изменения в своей системе, но они с опаской выпускают код, и система дает сбой.Указание пальца возобновляется.

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

3. Какова цель DevOps?

Улучшение сотрудничества между всеми заинтересованными сторонами от планирования до доставки и автоматизации процесса доставки, чтобы:

• Повысить частоту развертывания
• Ускорение вывода на рынок
• Меньше отказов новых выпусков
• Сократить время между исправлениями
• Увеличить среднее время восстановления

Согласно отчету о состоянии DevOps за 2015 год, «высокопроизводительные ИТ-организации развертывают в 30 раз чаще и в 200 раз короче; у них в 60 раз меньше отказов и в 168 раз быстрее.”

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

Каждый день развертывается новый код по мере его завершения разработчиками. Автоматическое тестирование гарантирует, что код готов к развертыванию. После того, как код проходит все автоматизированное тестирование, он развертывается для небольшого числа пользователей. Новый код отслеживается в течение короткого периода времени, чтобы гарантировать отсутствие непредвиденных проблем и его стабильность.Затем новый код распространяется среди оставшихся пользователей, как только мониторинг покажет, что он стабилен. Многие, если не все шаги после планирования и разработки выполняются без вмешательства человека.

4. Где вы находитесь в среде DevOps Continuum?

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

Вертикальная ось отображает три уровня цепочки доставки DevOps: непрерывная интеграция, непрерывная доставка и непрерывное развертывание. Сообщество DevOps называет организации в верхнем правом углу континуума DevOps розовыми единорогами, потому что в настоящее время их так мало, что вы не часто видите их в дикой природе. Популярными примерами этих единорогов являются такие компании, как Netflix, Etsy, Amazon, Pinterest, Flicker, IMVU и Google. В недавнем опросе участники указали, какое место их организации занимают в континууме DevOps:

• 55% Внизу слева
• 26% Внизу справа
• 14% Вверху слева
• 5% вверху справа

Лидеры, тренеры и блоггеры часто изображают видение DevOps в правом верхнем углу, и они часто имеют сильное предубеждение либо к культуре DevOps, либо к инструментам автоматизации.Хотя эзотерические дебаты о том, что важнее, культура или инструменты DevOps — это нормально, реальность такова, что у вас не может быть DevOps без инструментов, и все инструменты в мире не помогут, если у вас нет сильной поддержки. культура.

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

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

5. Каковы этапы зрелости DevOps?

Зрелость DevOps состоит из нескольких этапов; вот несколько ключевых этапов, которые вам необходимо знать.

Развитие водопада

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

Непрерывная интеграция

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

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

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

Непрерывная доставка

Непрерывная доставка — это расширение непрерывной интеграции [DevOps stage 2]. Он находится на вершине непрерывной интеграции. При выполнении непрерывной доставки вы добавляете дополнительную автоматизацию и тестирование, чтобы не просто часто объединять код с основной строкой кода, но вы получаете код, почти готовый к развертыванию, практически без вмешательства человека. Это практика, когда кодовая база постоянно находится в состоянии готовности к развертыванию.

Непрерывное развертывание

Непрерывное развертывание, не путать с непрерывной доставкой [DevOps nirvana], является наиболее продвинутым развитием непрерывной доставки.Это практика полного развертывания в производственной среде без вмешательства человека.

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

Существует очень небольшое количество компаний, которые действительно практикуют непрерывное развертывание.Netflix, Etsy, Amazon, Pinterest, Flicker, IMVU и Google — популярные примеры компаний, осуществляющих непрерывное развертывание.

Хотя нирвана DevOps часто не является конечной целью для большинства предприятий, они часто сосредотачиваются на движении к непрерывной доставке.

6. Каковы ценности DevOps?

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

Культура DevOps

Культура

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

Гибкие методы — более целостный способ доставки программного обеспечения. Команды гибкой разработки измеряют прогресс с точки зрения работающего программного обеспечения.Владельцы продуктов, разработчики, тестировщики и специалисты по UX работают в тесном сотрудничестве для достижения одних и тех же целей.

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

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

Инструменты DevOps

Инструменты

DevOps состоят из средств управления конфигурацией, систем тестирования и сборки, развертывания приложений, контроля версий и мониторинга. Для непрерывной интеграции, непрерывной доставки и непрерывного развертывания требуются разные инструменты. Хотя все три практики могут использовать одни и те же инструменты, вам понадобится больше инструментов по мере продвижения по цепочке доставки. [/ spb_text_block] [/ spb_column] [spb_column el_position = «first last»] [spb_text_block animation = «none» animation_delay = «0» padding_vertical = «0» padding_horizontal = «0» 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-тестирование ориентировано на автоматическое тестирование в конвейере сборки, чтобы убедиться, что к тому времени, когда у вас будет развертываемая сборка, вы будете уверены, что она готова к развертыванию.Вы не можете достичь точки непрерывной доставки, когда без какого-либо вмешательства человека вы будете достаточно уверены в том, что ваш код можно развернуть без обширной стратегии автоматического тестирования. Популярные инструменты — Селен и Вода.

Управление конвейером

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

Объединение разработки и доставки корпоративного программного обеспечения

VersionOne VS объединяет гибкое управление жизненным циклом приложений и DevOps, обеспечивая полную картину всего конвейера доставки программного обеспечения на единой платформе. VersionOne® Continuum ™ для DevOps — это корпоративное решение для непрерывной доставки, предназначенное для автоматизации, координации и визуализации потока изменений на протяжении всего цикла доставки программного обеспечения.

8. Что такое история DevOps?

2007

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

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

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

2008

Эндрю Шафер опубликовал идею сеанса «птицы пера» по гибкой инфраструктуре на конференции Agile 2008. Патрик Дебуа увидел пост и пошел на сеанс. К сожалению, он был единственным, кто появился.Идея была так плохо воспринята, что Эндрю даже не явился на собственное обсуждение.

К счастью, Патрик был так взволнован, увидев, что кто-то еще заинтересован в решении проблем совместной работы разработчиков и операторов, что он выследил Эндрю, и они решили создать группу Google под названием Agile System Administration.

2009

Джон Олспоу, старший вице-президент по техническим операциям в Flickr, и Пол Хаммонд, технический директор Flickr, выступили на конференции O’Reilly Velocity в Сан-Хосе с презентацией «10+ развертываний в день: сотрудничество разработчиков и операторов на Flickr. .«Презентация заложила основу того, как разработчики и операторы могут эффективно работать вместе для улучшения развертывания программного обеспечения.

Патрик Дебуа смотрел презентацию в Бельгии в прямом эфире и был вдохновлен начать свою собственную конференцию DevOpsDays в Генте, Бельгия. Конференция собрала энергичную группу дальновидных умов, пытающихся улучшить развертывание программного обеспечения. Что может быть еще более важным, так это то, что эта группа людей поддерживала разговор в Твиттере с хэштегом #DevOpsDays.Стремясь сэкономить пространство для персонажей в Твиттере, люди вскоре отказались от нескольких дней, и хэштег стал #DevOps.

2010

В следующем году DevOpsDays проводились в Австралии и США. Со временем DevOpsDays проводилось все больше и больше в разных странах и городах по всему миру. Личные встречи вдохновляли все больше и больше людей на DevOps, пока он не превратился в полноценное массовое движение.

2011

Вплоть до 2011 года движение DevOps поддерживалось отдельными людьми и инструментами с открытым исходным кодом, при этом аналитики и продавцы уделяли мало внимания.Но в 2011 году это движение стало массовым, привлекая внимание таких аналитиков, как Кэмерон Хейт из Gartner и Джей Лайман из 451 Research. На рынок DevOps начали продавать крупные поставщики.

2012

К 2012 году DevOps быстро превратился в модное слово, а количество DevOpsDays продолжало расти.

2013

Общественная жажда информации DevOps побудила нескольких авторов написать книги по этой теме. Яркими примерами являются The Phoenix Project Джина Кима, Кевина Бера и Джорджа Спаффорда и Implementing Lean Software Development Мэри и Тома Поппендик.

2014 Крупные компании, такие как Target, Nordstrom и LEGO, стали одними из первых компаний, которые внедрили DevOps в свои предприятия.

.

Что такое DevOps? | Разъяснение методологии и принципов DevOps

Если вы работаете в ИТ-индустрии, то наверняка слышали одно из самых популярных модных словечек под названием DevOps. Если вы хотите продолжить карьеру в DevOps, то, безусловно, будет полезно и полезно пройти сертификацию DevOps Certification . Прежде чем мы продолжим, я предлагаю вам просмотреть следующие блоги:

10 главных причин для изучения DevOps

Кто такой DevOps Engineer?

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

Что такое DevOps?

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

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

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

Итак, раз уж, что такое DevOps, давайте посмотрим на историю DevOps.

История DevOps

До DevOps у нас было два подхода к разработке программного обеспечения, а именно Waterfall и Agile.

Модель водопада

• Модель водопада — это модель разработки программного обеспечения, которая довольно прямолинейна и линейна. В этой модели используется нисходящий подход.

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

• Следующим этапом является этап Design , на котором вы готовите проект программного обеспечения.Здесь вы думаете о том, как на самом деле будет выглядеть программное обеспечение.

• Когда проект готов, вы переходите к этапу «Реализация », где вы начинаете с кодирования приложения. Команда разработчиков вместе работает над различными компонентами приложения.

• После завершения разработки приложения вы тестируете его на этапе Verification . В приложении проводятся различные тесты, такие как модульное тестирование, интеграционное тестирование, тестирование производительности и т. Д.

• После завершения всех тестов приложение развертывается на рабочих серверах.

• Наконец, наступает этап Maintenance . На этом этапе выполняется мониторинг производительности приложения. На этом этапе решаются любые проблемы, связанные с производительностью приложения.

Преимущества модели Waterfall:

• Простота понимания и использования

• Позволяет легко проводить тестирование и анализ

• Экономит значительное количество времени и денег

• Хорошо для небольших проекты, если все требования четко определены

• Разрешает подразделение и управленческий контроль

Недостатки модели Waterfall:

• Рискованно и неопределенно

• Отсутствие видимости текущего прогресса

• Не подходит, когда требования постоянно меняются

• Трудно внести изменения в продукт, когда он находится на стадии тестирования

• Конечный продукт доступен только в конце цикла

• Не подходит для крупных и комплексные проекты

Agil e Methodology

Agile Methodology — это итеративный подход к разработке программного обеспечения, при котором проект программного обеспечения разбивается на различные итерации или спринты.Каждая итерация имеет такие фазы, как модель водопада, например сбор требований, проектирование, разработка, тестирование и сопровождение. Продолжительность каждой итерации обычно составляет 2-8 недель.

Agile Process

• В Agile компания выпускает приложение с некоторыми высокоприоритетными функциями в первой итерации.

• После выпуска конечные пользователи или заказчики оставляют отзывы о производительности приложения.

• Затем вы вносите необходимые изменения в приложение вместе с некоторыми новыми функциями, и приложение снова выпускается, что является второй итерацией.

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

Преимущества гибкой модели

• Она адаптивно реагирует на изменения требований благоприятно

• Устранение ошибок на ранних этапах процесса разработки делает этот процесс более экономичным

• Повышает качество продукта и делает его безошибочным

• Позволяет напрямую общаться между людьми, участвующими в программном проекте

• Очень подходит для крупных и долгосрочных проектов

• Минимальные требования к ресурсам и очень простое управление

Недостатки Agile Model

• Сильно зависит от четких требований клиентов

• Довольно сложно предсказать время и усилия для крупных проектов

• Не подходит для сложных проектов

• Недостаток эффективности документации

• Увеличение Риски ремонтопригодности sed

Теперь перейдем к обсуждению этапов и инструментов DevOps.

Этапы и инструменты DevOps

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

Этап — 1: Непрерывная разработка

Используемые инструменты: Git, SVN, Mercurial, CVS

Процесс:

• Это этап, который включает в себя «планирование» и «кодирование» программного обеспечения.Вы определяете видение проекта на этапе планирования, и разработчики начинают разработку кода для приложения.

• Нет инструментов DevOps , необходимых для планирования, но есть ряд инструментов для поддержки кода.

• Код может быть на любом языке, но вы поддерживаете его с помощью инструментов контроля версий. Этот процесс поддержки кода известен как Управление исходным кодом.

• После разработки кода вы переходите к этапу непрерывной интеграции.

Этап — 2: Непрерывная интеграция

Инструменты: Jenkins, TeamCity, Travis

Поток процесса:

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

• Затем вы создаете каждую фиксацию, и это позволяет на раннем этапе обнаруживать проблемы, если они есть.Сборка кода включает не только компиляцию, но также включает проверку кода, модульное тестирование, интеграционное тестирование и упаковку.

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

• На этом этапе вы используете инструменты для сборки / упаковки кода в исполняемый файл, чтобы вы могли передать его на следующие этапы.

Этап — 3: Непрерывное тестирование

Инструменты: Jenkins, Selenium TestNG, JUnit

Процесс:

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

• Selenium используется для автоматического тестирования, а отчеты генерируются TestNG . Вы можете автоматизировать весь этот этап тестирования с помощью инструмента непрерывной интеграции под названием Jenkins.

• Предположим, вы написали код селена на Java для тестирования своего приложения. Теперь вы можете собрать этот код с помощью ant или maven. После создания кода вы затем тестируете его для пользовательского приемочного тестирования (UAT). Весь этот процесс можно автоматизировать с помощью Jenkins .

Этап — 4: Непрерывное развертывание

Используемые инструменты:

Управление конфигурацией — Chef, Puppet, Ansible

Контейнерная обработка — Docker, Vagrant

223 Процесс потока Это этап, на котором вы развертываете код на производственных серверах. Также важно убедиться, что вы правильно развернули код на всех серверах. Прежде чем двигаться дальше, давайте попробуем разобраться в некоторых вещах об управлении конфигурациями и инструментах контейнеризации .Этот набор инструментов помогает в достижении непрерывного развертывания (CD).

• Управление конфигурацией — это процесс установления и поддержания согласованности функциональных требований и производительности приложения. Позвольте мне выразиться проще: это действие по выпуску развертываний на серверах, планированию обновлений на всех серверах и, что наиболее важно, поддержанию согласованности конфигураций на всех серверах.

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

Этап 5: Непрерывный мониторинг

Используемые инструменты: Splunk, ELK Stack, Nagios, New Relic

Поток процесса:

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

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

Наконец, мы обсудим, кто именно является DevOps-инженером.

Кто такой DevOps-инженер?

DevOps Engineer — это тот, кто разбирается в жизненном цикле разработки программного обеспечения и имеет полное представление о различных инструментах автоматизации для разработки цифровых конвейеров (конвейеры CI / CD).

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

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

Ниже приведен список блогов, которые могут вас заинтересовать:

1. DevOps Tutorial
2. Git Tutorial
3. Continuous Delivery Tutorial
4. Docker Container Tutorial

5. 2 Ansible Puppet Tutorial

Теперь, когда вы поняли Что такое DevOps , ознакомьтесь с обучающим курсом DevOps DevOps от Edureka, надежной компании онлайн-обучения с сетью из более чем 250 000 довольных учеников по всему миру.Курс Edureka DevOps Certification Training помогает учащимся понять, что такое DevOps, и получить опыт работы с различными процессами и инструментами DevOps, такими как Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack и GIT для автоматизации нескольких этапов в SDLC.

Есть к нам вопрос? Пожалуйста, укажите это в комментариях, и мы свяжемся с вами.

.

Что такое DevOps и как он работает?

Что такое DevOps и как он работает? | Synopsys

• Продукты

• Решения

• Ресурсы

• Сервисы

• Сообщество

• Подготовка

• Инструменты и услуги

• Решения

• Подготовка

• Клиенты

• Ресурсы

• Партнеры

• Блог

• Насчет нас

• Отношения с инвесторами

• Сообщество

• отдел новостей

• Ресурсы

• Карьера

.

No related posts.