Многие из вас, возможно, знают все теории, связанные с . Но знаете ли вы, как реализовать принципы DevOps в реальной жизни? В этом блоге я расскажу о сценариях DevOps в реальном времени, которые помогут вам вкратце понять, как все работает в реальном времени.
Указатели, о которых я расскажу в этомСтатья DevOps Real Time Scenariosнаходятся:
- Что такое DevOps?
- Проблемы, решаемые DevOps
- Сценарии CI (непрерывной интеграции)
- CT (непрерывное тестирование) сценарии
- CD (непрерывная доставка) Сценарии
- Сценарии данных DevOps
Итак, давайте начнем с нашей первой темы.
Что такое DevOps?
DevOps - это подход к разработке программного обеспечения, который включает непрерывную разработку, непрерывное тестирование, непрерывную интеграцию, непрерывное развертывание и непрерывный мониторинг программного обеспечения на протяжении всего жизненного цикла разработки. Эти действия возможны только в DevOps, а не в Agile или водопаде. Вот почему Facebook и другие ведущие компании выбрали DevOps для достижения своих бизнес-целей.DevOps в основном предпочтительнее для разработки высококачественного программного обеспечения с более короткими циклами разработки, что приводит к большему удовлетворению запросов клиентов.
В следующем разделе этогоВ статье «Сценарии реального времени DevOps» мы рассмотрим различные проблемы, решаемые DevOps.
Проблемы, решаемые DevOps
1. Предоставление клиентам ценности
- DevOps минимизирует время это необходимо, чтобы приносить пользу клиентам. Время цикла от завершения разработчиком истории / задачи до производства значительно сокращается, что позволяет реализовать ценность как можно быстрее.
Самая важная ценность DevOps заключается в том, что он позволяет ИТ-организациям: сосредоточиться на своей «основной» деятельности . Устраняя ограничения в потоке создания ценности и автоматизируя конвейеры развертывания, команды могут сосредоточиться на деятельности. Это помогает создавать ценность для клиента, а не просто перемещать биты и байты. Эти действия увеличивают устойчивое конкурентное преимущество компании и улучшают результаты бизнеса.
2. Сокращенное время цикла
DevOps внутри компании - это единственный способ добиться гибкости и предоставить безопасный код с ценной информацией. Важно иметь ворота и хорошо продуманный процесс DevOps. Когда вы доставляете новую версию, она может работать параллельно с текущей версией. Вы также можете сравнить показатели, чтобы достичь желаемого, с показателями приложения и производительности.
DevOps побуждает команды разработчиков к постоянное улучшение и более быстрые циклы выпуска . Если все сделано правильно, этот повторяющийся процесс позволяет со временем больше сосредоточиться на вещах, которые действительно имеют значение. Например, вещи, которые создают отличный опыт для пользователей - и меньше времени на управление инструментами, процессами и технологиями.
3. Время выхода на рынок
Самая главная решаемая проблема - это снижение сложности процесса. Это в значительной степени способствует успеху нашего бизнеса, сокращая время вывода продукта на рынок, обеспечивая быструю обратную связь по функциям и делая нас более отзывчивыми к потребностям наших клиентов.
4. Решение проблемы
Самая большая ценность успешной реализации DevOps - это более высокая уверенность в доставке, прозрачности и отслеживаемости происходящего, чтобы вы могли быстрее решать проблемы.
Еще одно важное преимущество DevOps - не тратить время зря. Согласование сотрудников и ресурсов организации обеспечивает быстрое развертывание и обновление. Это позволяет программам DevOps устранять проблемы до того, как они перерастут в катастрофу.DevOps создает культуру прозрачности, которая способствует сосредоточенности и сотрудничеству между группами разработки, эксплуатации и безопасности.
CI (непрерывная интеграция) вСценарии DevOps в реальном времени
1. Люди могут увидеть, что непрерывная интеграция является контрпродуктивной
У членов команды разработчиков разные роли, обязанности и приоритеты. Вполне возможно, что первоочередной задачей менеджера по продукту может быть запуск новых функций, менеджер проекта должен убедиться, что его команда уложится в срок. Программисты могут подумать, что если они будут останавливаться, чтобы каждый раз исправлять мелкую ошибку, то это замедлит их работу. Они могут почувствовать, что поддержание чистоты сборки - это дополнительная нагрузка для них, и они не получат выгоды от их дополнительных усилий. Это потенциально может поставить под угрозу процесс адаптации.
Чтобы преодолеть это:
Во-первых, убедитесь, что вся ваша команда работает, прежде чем переходить на непрерывную интеграцию.
Технические директора и руководители групп должны помочь членам команды понять затраты и преимущества непрерывной интеграции.
Подчеркните, что и когда кодировщики получат выгоду, если посвятят себя другому методу работы, требующему немного большей открытости и гибкости.
2. Интеграция CI в существующий поток разработки
Принятие CI неизбежно связано с необходимостью существенного изменения некоторых частей рабочего процесса разработки. Возможно, ваши разработчики не исправят рабочий процесс, если он не нарушен. Это возможно, в основном, если у вашей команды больше рутины при выполнении текущего рабочего процесса.
Если вы хотите изменить рабочий процесс, вы должны сделать это с большой осторожностью. В противном случае это может поставить под угрозу производительность команды разработчиков, а также качество продукта. Без достаточной поддержки со стороны руководства команда разработчиков может неохотно браться за задачу с такими рисками.
Чтобы преодолеть это:
Вы должны убедиться, что даете вашей команде достаточно времени для разработки нового рабочего процесса. Это делается для того, чтобы выбрать гибкое решение для непрерывной интеграции, которое сможет поддерживать их новый рабочий процесс.
Кроме того, убедитесь, что компания их поддерживает, даже если вначале все может идти не очень гладко.
3. Возвращение к прежним привычкам тестирования.
Непосредственный эффект от внедрения непрерывной интеграции состоит в том, что ваша команда будет чаще проводить тестирование. Таким образом, для большего количества тестов потребуется больше тестовых примеров, а написание тестовых примеров может занять много времени. Следовательно, разработчикам часто приходится делить свое время между исправлением ошибок и написанием тестовых примеров.
Временно разработчики могут сэкономить время, тестируя вручную, но в долгосрочной перспективе это может навредить. Чем дольше они откладывают написание тестовых примеров, тем труднее становится следить за ходом разработки. В худшем случае ваша команда может вернуться к своему старому процессу тестирования.
Чтобы преодолеть это:
Вы должны подчеркнуть, что написание тестовых примеров с самого начала может сэкономить много времени вашей команде и может обеспечить высокий уровень тестового покрытия вашего продукта.
Кроме того, внедрите в культуру своей компании идею, согласно которой тестовые примеры являются такими же ценными активами, как и сама кодовая база.
4. Разработчики игнорируют сообщения об ошибках.
Распространенная проблема заключается в том, что, когда большие команды работают вместе, количество уведомлений CI становится непомерно большим, и разработчики начинают их игнорировать и отключать. Таким образом, они могут пропустить актуальные для них обновления.
каковы 6 способов использования этого ключевого слова?
Это может привести к стадии, когда кодировщики выработают относительную невосприимчивость к сломанным сборкам и сообщениям об ошибках. Чем дольше они игнорируют соответствующие уведомления, тем дольше развиваются без обратной связи в неправильном направлении. Это потенциально может привести к огромным откатам, потере денег, ресурсов и времени.
Чтобы преодолеть это:
Вам следует отправлять только критические обновления.
Отправляйте уведомление только соответствующим разработчикам, которые отвечают за его исправление.
CT (непрерывное тестирование) вСценарии DevOps в реальном времени
Получение правильной спецификации требований
Если вы правильно уловите свои требования, то почти половина битвы будет выиграна. Таким образом, если у вас есть очень конкретное и точное понимание требований, вы можете лучше разработать планы тестирования и хорошо охватить требования.
Тем не менее, многие команды тратят много времени и усилий просто на разъяснение требований. Это очень распространенная ошибка, и чтобы ее избежать, команды могут применять методы тестирования на основе моделей и разработки на основе поведения. Это помогает точно и адекватно разрабатывать сценарии тестирования.
Эти методы определенно помогут быстрее устранить и устранить пробелы. Кроме того, это позволяет им автоматически создавать больше тестовых примеров прямо на ранних этапах спринта.
Трубопроводная оркестровка
Преимущества непрерывного тестирования и непрерывная доставка тесно связаны с конвейерной оркестровкой. Это напрямую означает понимание того, как это работает, почему это работает, как анализировать результаты, а также как и когда масштабировать. Все зависит от конвейера, поэтому вам необходимо интегрировать конвейер с пакетом автоматизации.
Но причина того, что команды ошибаются, заключается в том, что ни одно решение не предоставляет полную цепочку инструментов, которая требуется для создания конвейера CD.
Командам обычно приходится искать те части головоломки, которые им подходят. Не существует идеальных инструментов, как правило, только лучшие в своем классе, которые обеспечивают интеграцию с множеством других инструментов. И, конечно же, API, который также позволяет легко интегрировать.
Короче говоря, невозможно реализовать непрерывное тестирование без скорости и надежности стандартизированного и автоматизированного конвейера.
Увеличение масштаба и управление сложностью
Другой важный сценарий состоит в том, что непрерывное тестирование становится более сложным по мере продвижения в производственную среду. Количество тестов растет, а их сложность растет по мере усложнения кода и среды.
Вы должны обновлять тесты каждый раз, когда обновляете различные этапы и автоматизированные скрипты. В результате общее время, необходимое для запуска тестов, также имеет тенденцию увеличиваться к выпуску.
Решение этой проблемы заключается в улучшенной оркестровке тестов, которая обеспечивает необходимый объем тестового покрытия за более короткие циклы спринта и позволяет командам уверенно работать. В идеале весь процесс должен быть автоматизирован с проведением КТ на разных этапах. Это делается с помощью шлюзов политик и ручного вмешательства, пока код не будет запущен в производство.
Создание петель обратной связи
Без частых циклов обратной связи на каждом этапе цикла разработки непрерывное тестирование невозможно. Отчасти это причина того, что CT сложно реализовать. Вам нужны не только автоматизированные тесты, но и наглядность результатов и выполнения тестов.
Традиционные циклы обратной связи, такие как инструменты ведения журналов, профилировщики кода и инструменты мониторинга производительности, больше не эффективны. Они не работают вместе и не обеспечивают глубокого понимания, необходимого для устранения проблем. Панели мониторинга в реальном времени, которые автоматически генерируют отчеты и дают полезную обратную связь по всему SDLC, помогают быстрее выпускать программное обеспечение в производство с меньшим количеством дефектов. Доступ в реальном времени к информационным панелям и доступ для всех членов команды помогает механизму непрерывной обратной связи.
Отсутствие окружающей среды
Непрерывное тестирование просто означает более частое тестирование, а это требует более частого попадания в несколько сред. Это является узким местом, если указанные среды недоступны в то время, когда они требуются. Некоторые среды доступны через API, а некоторые - через различные интерфейсы. Некоторые из этих сред могут быть построены с использованием современной архитектуры, а другие - с использованием устаревших монолитных систем клиент / сервер или мэйнфреймов.
Но вопрос здесь в том, как вы координируете тестирование через различных владельцев среды? Также возможно, что они не всегда могут поддерживать среду в рабочем состоянии. Ответ на все это Виртуализация . Виртуализируя среду, вы можете протестировать код, не беспокоясь о неизменных областях.Обеспечение доступности сред и их доступности по запросу с помощью виртуализации, несомненно, поможет устранить значительное узкое место в вашем конвейере.
CD (непрерывная доставка) вСценарии DevOps в реальном времени
Развертывания занимают слишком много времени
Распределенным приложениям обычно требуется нечто большее, чем просто «копирование и вставка» файлов на сервер. Сложность имеет тенденцию к увеличению, если у вас есть ферма серверов. Неуверенность в том, что развертывать, где и как развертывать, - вполне нормальное явление. Результат? Долгое время ожидания, чтобы наши артефакты попали в следующую среду на пути к задержке всего, тестированию, времени жизни и т. Д.
Что дает DevOps? Команды разработки и ИТ-операций определяют процесс развертывания в безупречном сеансе совместной работы. Сначала они проверяют, что работает, а затем переходят на новый уровень с помощью автоматизации, чтобы облегчить непрерывную доставку. Это резко сокращает время развертывания, а также открывает путь для более частых развертываний.
Отсутствующие артефакты, скрипты и другие зависимости
Мы часто сталкиваемся с ошибками после развертывания новой версии работающего программного обеспечения. Часто это вызвано отсутствием библиотек или скриптами базы данных, которые не обновляются. Обычно это вызвано отсутствием ясности в отношении того, какие зависимости развертывать и их расположение. Налаживание сотрудничества между разработчиками и производителями может помочь решить подобные проблемы в большинстве случаев.
Когда дело доходит до автоматизации, вы можете определять зависимости, что очень помогает ускорить развертывание. Инструменты управления конфигурацией, такие как Кукольный или Начальник способствуют дополнительному уровню определения зависимостей. Мы можем определять зависимости не только внутри нашего приложения, но также на уровне инфраструктуры и конфигурации сервера. Например, мы можем создать виртуальную машину для теста и установить / настроить Кот до публикации наших артефактов.
как разобрать xml в java
Неэффективный мониторинг производства
Иногда вы настраиваете инструменты мониторинга таким образом, чтобы получать много нерелевантных данных из производственной среды, однако в других случаях они не производят достаточно или вообще ничего. Нет определения того, за чем нужно ухаживать и каковы показатели.
Вы должны договориться о том, что отслеживать и какую информацию производить, а затем установить меры контроля. Инструменты управления производительностью приложений станут отличным подспорьем, если ваша организация может себе это позволить. Взгляните на AppDynamics, New Relic и AWS X-Ray.
Сценарии данных DevOps
DevOps - это устранение рисков, связанных с разработкой нового программного обеспечения: анализ данных выявляет эти риски. Для непрерывного измерения и улучшения процесса DevOps аналитика должна охватывать весь конвейер. Это дает бесценную информацию руководству на всех этапах жизненного цикла разработки программного обеспечения.
1. Меньше времени на анализ данных.
Со всеми данными, которые создаются в любой момент времени, организации должны признать, что они не могут их все проанализировать. Днем просто не хватает времени - и, к сожалению, роботы еще недостаточно сложны, чтобы делать все это за нас.
По этой причине важно определить, какие наборы данных наиболее важны. В большинстве случаев это будет разное для каждой организации. Итак, прежде чем приступить к делу, определите ключевые бизнес-цели и задачи. Обычно эти цели вращаются вокруг потребностей клиентов - в первую очередь, наиболее ценных функций, которые наиболее важны для конечных пользователей. Например, для розничного продавца анализ взаимодействия трафика со страницей оформления заказа на сайте и проверка того, как это работает в серверной части, находятся в верхней части списка.
Несколько быстрых советов, чтобы определить, какие данные наиболее важно анализировать:
Составьте диаграмму. Определите, какое влияние перебои в работе окажут на ваш бизнес, задав такие вопросы, как «Если X ломается , как это повлияет на другие функции? »
Изучите исторические данные: определите, где проблемы возникали в прошлом, и продолжайте анализировать данные тестов и сборки, чтобы убедиться, что это больше не повторится.
2. Сложное общение
Сегодня большинство организаций по-прежнему работают с разными командами и персонажами, определяя свои собственные цели и используя свои собственные инструменты и технологии. Каждая команда действует независимо, отключена от конвейера и встречается с другими командами только на этапе интеграции.
Когда дело доходит до более широкой картины и определения того, что работает, а что не работает, организация изо всех сил пытается найти одно решение. В основном это потому, что все не могут поделиться общими данными, что делает анализ невозможным.
Чтобы преодолеть эту проблему, пересмотрите поток коммуникации, чтобы гарантировать, что все взаимодействуют на протяжении всего SDLC, а не только в процессе интеграции.
Во-первых, с самого начала убедитесь, что есть надежная синхронизация показателей DevOps. Прогресс каждой команды должен отображаться на единой панели инструментов с использованием одних и тех же ключевых показателей эффективности (KPI), чтобы руководство могло видеть весь процесс. Это сделано для того, чтобы они могли собрать все необходимые данные для анализа того, что пошло не так (или что удалось).
Помимо первоначального разговора о показателях, должно быть постоянное общение через собрания команд или цифровые каналы, такие как Slack.
3. Нехватка рабочей силы
В условиях нехватки персонала нам нужны более умные инструменты, которые используют глубокое обучение для обработки данных, которые мы собираем, и быстрого принятия решений. В конце концов, ни у кого нет времени смотреть на выполнение каждого теста (а в некоторых крупных организациях их может быть около 75 000 в день). Хитрость заключается в том, чтобы устранить шум и найти то, на чем нужно сосредоточиться.
Здесь могут помочь искусственный интеллект и машинное обучение. Многие инструменты, представленные сегодня на рынке, используют ИИ и машинное обучение для следующих целей:
Разрабатывать скрипты и тесты для перемещения и проверки различных фрагментов данных.
Отчет о качестве на основе ранее изученного поведения
Работайте в соответствии с изменениями в реальном времени.
Итак, на этом мы подошли к концу статьи о сценариях DevOps в реальном времени.
Теперь, когда вы поняли, что такое сценарии DevOps в реальном времени, ознакомьтесь с этим от Edureka, надежной компании по онлайн-обучению с сетью из более чем 250 000 довольных учащихся по всему миру. Курс Edureka DevOps Certification Training помогает учащимся понять, что такое DevOps, и получить опыт работы с различными процессами и инструментами DevOps, такими как Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack и GIT для автоматизации нескольких этапов в SDLC.
Есть вопрос к нам? Пожалуйста, укажите это в комментариях к этомуСтатья о сценариях в реальном времени DevOpsи мы свяжемся с вами.