что такое devops для чайников

Зачем нужен DevOps и кто такие DevOps-специалисты

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

Какие практики входят в понятие DevOps и зачем они нужны? Чем занимаются DevOps-инженеры и что они должны уметь? На эти и другие вопросы отвечают эксперты из EPAM: Кирилл Сергеев, системный инженер и DevOps-евангелист, и Игорь Бойко, ведущий системный инженер и координатор одной из DevOps-команд компании.

Зачем нужен DevOps?

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

Что такое DevOps?

Вопрос хороший – и спорный: окончательно в мире об этом пока не договорились. В ЕРАМ считают, что DevOps объединяет в себе технологии, процессы и культуру взаимодействия внутри команды. Это объединение нацелено на непрерывную доставку ценностей конечным пользователям.

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

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

В чем состоит суть DevOps-культуры?

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

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

Какие бывают DevOps-практики?

DevOps-практики покрывают все этапы жизненного цикла ПО.

Игорь Бойко: «Идеальный случай – когда мы начинаем использовать DevOps-практики прямо при инициации проекта. Вместе с архитекторами мы планируем, какой у приложения будет архитектурный ландшафт, где оно будет располагаться и как масштабироваться, выбираем платформу. Сейчас в моде микросервисная архитектура – для нее мы выбираем систему оркестрации: нужно уметь управлять каждым элементом приложения по отдельности и обновлять его независимо от других. Еще одна практика – это “инфраструктура как код”. Так называют подход, при котором инфраструктура проекта создается и управляется при помощи кода, а не через прямое взаимодействие с серверами.

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

На этапах CI/CD код проходит через quality gates. С их помощью проверяют, чтобы код, который вышел с рабочей станции разработчика, соответствовал заданным критериям качества. Здесь добавляется юнит- и UI-тестирование. Для быстрого, безболезненного и фокусированного разворачивания продукта можно выбрать подходящий тип деплоймента.

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

Чем полезны DevOps-практики?

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

Кирилл Сергеев: «Первое – это автоматизация. Все взаимодействия в команде мы можем автоматизировать: написали код – выкатили – проверили – установили – собрали фидбэк – вернулись в начало. Всё это – автоматически.

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

Третье – это ускорение обратной связи от пользователя. Если у него есть замечания, мы можем сразу же вносить корректировки и тут же обновлять приложение».

Как соотносятся понятия «системный инженер», «билд-инженер» и «DevOps-инженер»?

Они пересекаются, но относятся к немного разным сферам.

Системный инженер в ЕРАМ – это должность. Они бывают разных уровней: от джуниора до chief-специалиста.

Билд-инженер – это скорее роль, которую можно выполнять на проекте. Сейчас так называют людей, ответственных за CI/CD.

DevOps-инженером называют специалиста, который внедряет на проекте DevOps-практики.

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

Чем именно занимается DevOps-инженер?

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

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

Кирилл Сергеев: «Прежде чем внедрять обновления в продукт, их нужно протестировать на стороннем окружении. Его готовят DevOps-инженеры. Они же насаждают на проекте DevOps-культуру в целом: внедряют DevOps-практики на всех слоях своих проектов. Эти три принципа: автоматизация, упрощение, ускорение – они привносят всюду, куда могут дотянуться».

Что должен знать DevOps-инженер?

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

1. Языки программирования

DevOps-инженеры знают несколько базовых языков для автоматизации и могут, например, сказать программисту: «Давай ты будешь делать установку кода не руками, а с помощью нашего скрипта, который всё автоматизирует? К нему мы подготовим config-файл, его будет удобно читать и тебе, и нам – и мы в любой момент сможем его изменить. А еще мы будем видеть, кто, когда и для чего вносит в него изменения».

DevOps-инженер может выучить один или несколько из этих языков: Python, Groovy, Bash, Powershell, Ruby, Go. Знать их на глубинном уровне не требуется – достаточно основ синтаксиса, принципов ООП, умения писать несложные скрипты для автоматизации.

2. Операционные системы

DevOps-инженер должен понимать, на каком сервере будет установлен продукт, в какой среде будет запускаться, с какими сервисами будет взаимодействовать. Можно выбрать специализацию на Windows или Linux-семействе.

3. Системы контроля версий

Без знаний системы контроля версий DevOps-инженеру никуда. Git – одна из самых популярных систем в настоящий момент.

4. Облачные провайдеры

AWS, Google, Azure – особенно если мы говорим про Windows-направление.

Кирилл Сергеев: «Облачные провайдеры предоставляют нам виртуальные сервера, которые прекрасно ложатся на рельсы CI/CD.

Установка десяти физических серверов требует порядка ста ручных операций. Каждый сервер нужно вручную запустить, установить и настроить нужную операционную систему, установить наше приложение на этих десяти серверах, а потом десять раз всё перепроверить. Облачные сервисы заменяют эту процедуру десятью строчками кода, и хороший DevOps-инженер должен уметь ими оперировать. Так он экономит время, силы и деньги – и для заказчика, и для компании».

5. Системы оркестрации: Docker и Kubernetes

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

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

6. Системы конфигураций: Chef, Ansible, Puppet

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

Какую карьеру может построить DevOps-инженер?

Развиваться можно и горизонтально, и вертикально.

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

Можно стать системным архитектором, если сотруднику интересно разобраться, как работает приложение на всех этапах своего жизненного цикла – от разработки до поддержки».

Как стать DevOps-инженером?

А также можно посмотреть актуальные тренинги по DevOps на сайте Тренинг-центра EPAM.

Больше информации о DevOps-направлении на сайте.

Источник

Что такое методология DevOps и кому она нужна

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

Также поговорим о DevOps-специалистах: их задачах, зарплатах и навыках.

Фото Matt Moor / Flickr / CC BY-SA

Что такое DevOps

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

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

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

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

Кому нужна и не нужна методология

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

Исключение составляют стартапы, но и здесь все зависит от масштабов проекта. Если ваша цель — запустить минимально жизнеспособный продукт (minimum viable product, MVP), чтобы протестировать новую идею, то можно обойтись и без DevOps. Например, основатель Groupon в начале работы над сервисом сам вручную размещал все предложения на сайте и собирал заказы. Никаких инструментов автоматизации он не использовал.

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

Как внедрить DevOps

Далее — несколько рекомендаций для перехода на новую методологию.

Выявите проблемы в бизнес-процессах. Перед внедрением методологии выделите цели и проблемы организации. От них будет зависеть стратегия перехода на DevOps. Для этого составьте список вопросов, например:

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

Начните с малого. Выберите процесс, который отнимает больше всего времени и сил при выпуске обновлений, и автоматизируйте его. Это может быть тестирование или процесс развертывания приложений. Эксперты советуют первым делом внедрить инструменты распределенного контроля версий. С ними проще управлять исходниками. Среди таких решений наиболее известны Git, Mercurial, Subversion (SVN) и CVS.

Также стоит обратить внимание на системы непрерывной интеграции, ответственные за сборку и тестирование конечного продукта. Примеры таких инструментов: Jenkins, TeamCity и Bamboo.

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

Критика DevOps

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

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

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

Фото Ed Ivanushkin / Flickr / CC BY-SA

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

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

Фишка DevOps-инженера в том, что он совмещает множество профессий: админа, разработчика, тестировщика и менеджера.

Джо Санчес, DevOps-евангелист из VMware, компании-разработчика программного обеспечения для виртуализации, выделил ряд навыков, которыми обязан обладать DevOps-инженер. Помимо очевидного знания методологии DevOps, этот человек должен иметь опыт администрирования ОС Windows и Linux и опыт работы с инструментами автоматизации вроде Chef, Puppet, Ansible. Еще он должен уметь писать скрипты и код на паре-тройке языков и разбираться в сетевых технологиях.

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

Кто нанимает

DevOps-инженеры могут принести пользу любой организации, чья деятельность связана с разработкой приложений или управлением большим количеством серверов. DevOps-инженеров нанимают ИТ-гиганты вроде Amazon, Adobe и Facebook. Еще они работают на Netflix, Walmart и Etsy.

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

Сколько платят

DevOps-инженеры зарабатывают больше всех в отрасли. Средний заработок таких специалистов по миру составляет от 100 до 125 тыс. долларов в год.

В США они получают 90 тыс. долларов в год (500 тыс. рублей в месяц). В Канаде им платят 122 тыс. долларов в год (670 тыс. рублей в месяц), а в UK — 67,5 тыс. фунтов стерлингов в год (490 тыс. рублей в месяц).

Что касается России, то московские компании готовы платить DevOps-специалистам от 100 до 200 тыс. рублей в месяц. В Санкт-Петербурге работодатели чуть щедрее — предлагают 160–360 тыс. рублей в месяц. В регионах указывают зарплату 100–120 тыс. рублей в месяц.

Как стать специалистом по DevOps

DevOps — это относительно новое направление в IT, поэтому устоявшегося перечня требований к DevOps-инженерам нет. В вакансиях среди требований на эту должность можно встретить как навыки администрирования Debian и CentOS, так и умение работать с дисковыми RAID-массивами.

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

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

Чтобы понять, где знаний пока не хватает, можно воспользоваться мини-википедией на GitHub или ментальной картой. Резиденты Hacker News также рекомендуют почитать книги «Проект „Феникс“» и «Руководство по DevOps» (которые мы упоминали выше) и «Философия DevOps. Искусство управления IT» под грифом O’Reilly Media.

Еще можно подписаться на рассылку Devops Weekly, почитать статьи тематического портала DZone и начать общаться с DevOps-инженерами в Slack-чате. Еще стоит изучить бесплатные курсы на Udacity или edX.

Источник

Руководство для чайников: создание цепочек DevOps с помощью инструментов с открытым исходным кодом

Создание первой цепочки 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:

Источник