Если вы работаете в сфере программного обеспечения или ИТ, вы, возможно, сталкивались с терминами непрерывная интеграция и непрерывная поставка, или, что еще лучше, вы практикуете их ежедневно! Теперь Фонд CD выпустил свой ежегодный отчет о Состоянии CD, разбив некоторые ключевые статистические данные о том, как организации и команды используют CICD для достижения своих целей. В этой статье я расскажу о некоторых ключевых вещах, которые мне показались интересными как инженеру DevOps, работающему в отрасли.
Полный отчет State of CD 2022 можно найти здесь:
CICD продолжает расти в отрасли
Отчет показал, что 47% разработчиков так или иначе используют непрерывную интеграцию или развертывание. Тем не менее, только каждый пятый использует подходы непрерывной интеграции и развертывания для автоматизации всех аспектов создания, тестирования и развертывания кода в производственных средах.
Судя по этим цифрам, у нас есть хороший показатель того, что входной барьер для использования процессов разработки относительно низок, и разработчики готовы взяться за эту работу, если смогут. Потому что, в конце концов, процессы DevOps могут автоматизировать некоторые обычные действия, которые могут выполняться разработчиком, такие как проверка и тестирование своего программного обеспечения. Мы видим это, особенно при мониторинге. Многие поставщики SAAS представляют собой готовые к работе решения для многих стандартных требований, поэтому разработчики выбирают их на ранних стадиях своего пути DevOps в качестве легкой победы.
По мере того, как мы спускаемся по ступеням к некоторым активам DevOps с более низким рейтингом, разработчики изо всех сил пытаются полностью реализовать или даже начать эти действия из-за повышенной сложности, требуемой от организационной поддержки. Например, автоматическая сборка и тестирование изменений кода может быть легко запущена одной командой, но создание автоматизированного регрессионного тестирования в ваших пайплайнах для проверки изменения кода теперь требует от организации согласования тестовых случаев, ограничений для развертывания и т. д. каков план отката и т. д., так что эти изменения нуждаются в организации, чтобы увидеть преимущества этих подходов и дальше развивать свою внутреннюю бизнес-логику, чтобы позволить своим инженерам автоматизировать такие вещи, как тестирование и выпуски, чтобы сократить время выполнения изменений кода.
Кто занимается DevOps?
Что касается тех, кто выполняет и не выполняет какие-либо действия DevOps, вы можете увидеть высокий уровень внедрения DevOps в организациях всех размеров.
Опять же, обещание DevOps автоматизировать обычную деятельность разработчиков означает, что независимо от размера организации вы в какой-то степени выиграете от этой автоматизации. Понятно, что фрилансеры составляют наименьшую долю, поскольку автоматизация некоторых действий не имеет смысла, когда вы единственный разработчик. Тем не менее, даже эта группа может извлечь выгоду из DevOps, используя свою деятельность, позволяя им разрабатывать с помощью общей платформы для разработчиков или более эффективно развертывать свои проекты при работе с несколькими клиентами и избегая повторяющихся задач.
CICD помогает нам быстрее выпускать лучшее программное обеспечение
В отчете также показано, что внедрение современных серверных технологий обычно коррелирует с повышением производительности в отношении времени выполнения изменений кода и времени восстановления обслуживания, но не может значительно повысить частоту развертывания. Также сохраняется сильная корреляция между показателями скорости и стабильности, а не одна компрометирует другую, когда дело доходит до разработчиков, пытающихся восстановить обслуживание своих приложений.
Это время выполнения имеет смысл для разработчика. Если приложения терпят неудачу в продакшене, если мы не можем развернуть их быстрее, мы не сможем исправить это быстрее. Тем не менее, необходимо вложить средства в процесс выпуска изменений кода, чтобы убедиться, что он соответствует назначению и удобен для ваших разработчиков, чтобы сервисы можно было восстанавливать быстрее.
Подобно инвестициям в процесс выпуска, инвестиции в контейнерные технологии позволяют командам в два раза чаще добиваться лучших результатов в деятельности DevOps. Производительность здесь измеряется временем выполнения изменений кода для вашего приложения в рабочей среде.
Эти контейнерные инструменты поощряют инвестиции в вашу платформу разработчика, чтобы максимально эффективно использовать их, чтобы команды могли эффективно выполнять сборки контейнеров на нескольких базах кода, которые могут быть задействованы в вашем приложении, и поддерживать инфраструктуру и развертывания, настроенные как код, близкий к коду приложения. Разработчики могут лучше использовать эту контейнерную платформу для более быстрой работы за счет простых изменений рабочего процесса, таких как возможность запускать контейнер на своем локальном компьютере для разработки, который идентичен тому, который запущен в рабочей среде. Контейнеры также отлично подходят для работы с нуля, когда вы можете следовать всем передовым методам работы с контейнерами, и для уже существующих, когда разработчики могут использовать контейнеры для лучшего определения и совместного использования своей локальной среды выполнения для тестирования, в то время как использование различных методов развертывания может по-прежнему быть значительным улучшением для разработчика. производительность и время выполнения кода изменения.
Однако контейнеры не делают нас автоматически мастерами развертывания и не исправляют все наши ошибки.
Отсюда можно сказать одно, технологии контейнеров и микросервисов сложны. Они требуют инвестиций в платформу, чтобы быть в курсе всех различных операционных аспектов микросервисов, таких как мониторинг, безопасность и производительность стека, который вы используете. Таким образом, мы видим, что начать работу с этими технологиями легко, но для достижения успеха требуются реальные инвестиции и изменение мышления, чтобы команды следовали всем принципам DevOps, таким как владение инфраструктурой, развертывание и мониторинг на уровне команды, чтобы уменьшить это. время на смену кода и восстановление обслуживания.
Подведение итогов
В целом, как инженер DevOps, я не удивлен этими результатами. DevOps как практика все еще развивается, поскольку новые инструменты становятся лучше и проще для интеграции в рабочие процессы разработчиков. Почти каждая платформа репозитория SASS git имеет встроенную систему CICD, что упрощает начало работы с DevOps. Несмотря на то, что разработчики могут быстро решить некоторые проблемы с помощью практики DevOps, такие как автоматизированное модульное тестирование или рабочие процессы управления исходным кодом для проверки кода перед слиянием, получение фундаментальных важных изменений, таких как регрессивное тестирование и более быстрый выпуск, требует реальной поддержки. от более крупной организации, и они должны принять некоторые из этих принципов DevOps, чтобы обеспечить более быстрые изменения, определяя, каков их продукт и требования, чтобы их можно было протестировать и автоматизировать. Но по мере того, как инструменты созрели, чтобы сделать эти легко висящие плоды почти обязательными для передовой практики, эти более сложные задачи DevOps решаются медленно, и инструменты могут со временем лучше автоматизировать эти требования для нас.
Подключиться дальше
- Если вы думаете о подписке на Medium, вы можете помочь мне, воспользовавшись моей реферальной ссылкой.
- Ознакомьтесь с другими моими публикациями здесь, на Medium, и, если вы хотите быть в курсе, подпишитесь через Email.
- Свяжитесь со мной в Twitter или LinkedIn, если вы хотите пообщаться, если вы хотите нанять меня, я на Codementor.
Повышение уровня кодирования
Спасибо, что являетесь частью нашего сообщества! Перед тем, как ты уйдешь:
- 👏 Хлопайте за историю и подписывайтесь на автора 👉
- 📰 Смотрите больше контента в публикации Level Up Coding
- 🔔 Подписывайтесь на нас: Twitter | ЛинкедИн | "Новостная рассылка"
