Как разработчики могут использовать DevOps — введение и контроль версий
1 марта 2023 г.Некоторые выступления я начинаю с шутки: в свое время у нас не было мониторинга или наблюдения. Мы шли на сервер и давали ему пинок. Слышите HD спину? Это работает!
У нас не было DevOps. Если нам повезло, у нас были администраторы и технический специалист для решения проблем с оборудованием. Вот и все. В небольшой компании мы бы сделали все это сами. Сегодня это уже не практично. Сложность развертывания и масштабирования настолько велика, что трудно представить растущую компанию без инженера, занимающегося операциями.
В этой серии я надеюсь познакомить вас с некоторыми основными принципами и инструментами, используемыми DevOps. Это важный навык, которым нам нужно овладеть в стартапе, где у нас может вообще не быть роли DevOps. Или в крупной корпорации, где нам нужно общаться с командой DevOps и объяснять свои потребности или требования.
https://www.youtube.com/watch?v=2HatFLh4xoA&embedable=true
Что такое DevOps?
DevOps – это методология разработки программного обеспечения, призванная сократить разрыв между командами разработки и эксплуатации. Особое внимание уделяется сотрудничеству и взаимодействию между этими двумя командами для обеспечения беспрепятственного выпуска высококачественных программных продуктов.
Основные принципы, лежащие в его основе:
- Непрерывная интеграция и непрерывная доставка (CI/CD). CI/CD — один из ключевых принципов DevOps. Он включает в себя автоматизированные процессы для создания, тестирования и развертывания программного обеспечения. С помощью CI/CD разработчики могут выявлять и исправлять ошибки на ранних этапах цикла разработки, что приводит к более быстрой и надежной доставке программного обеспечения.
Как разработчик, CI/CD может помочь вам, ускорив обратную связь, позволяя вносить изменения в код и видеть результаты в режиме реального времени. Это поможет вам быстро выявлять и устранять любые проблемы, что экономит время и гарантирует, что ваш код всегда будет готов к выпуску.
Обратите внимание, что CD означает непрерывную доставку и развертывание. Это ужасно раздражающая аббревиатура. Хотя разница между ними проста. Развертывание зависит от доставки, мы не можем развернуть приложение, если оно не было создано и доставлено. Аспект развертывания означает, что слияние наших коммитов с основной веткой в какой-то момент приведет к изменению рабочей среды без какого-либо участия пользователя. 2. Автоматизация. Автоматизация включает в себя автоматизацию повторяющихся задач, таких как создание, тестирование и развертывание программного обеспечения. Это помогает сократить время и усилия, необходимые для выполнения этих задач, освобождая разработчиков, чтобы они могли сосредоточиться на более важных задачах.
Автоматизация может помочь вам, как разработчику, высвободив время и позволив сосредоточиться на написании кода, а не на ручных задачах. Кроме того, автоматизация помогает снизить риск человеческой ошибки, гарантируя, что ваш код всегда будет правильно развернут. 3. Сотрудничество и общение. DevOps уделяет особое внимание сотрудничеству и общению между командами разработки и эксплуатации. Это помогает убедиться, что все находятся на одной странице и работают для достижения общей цели. Это также помогает сократить время и усилия, необходимые для решения любых проблем, которые могут возникнуть.
Разработка платформы
В последнее время наблюдается подъем в области разработки платформ. Это несколько сбивает с толку, поскольку совпадение ролей DevOps и разработчика платформы не обязательно очевидно. Тем не менее, это две связанные, но разные области разработки программного обеспечения. Хотя оба они занимаются улучшением процессов доставки и эксплуатации программного обеспечения, у них разные цели и подходы.
Разработка платформ – это дисциплина, которая фокусируется на создании и обслуживании инфраструктуры и инструментов, необходимых для поддержки процесса разработки программного обеспечения. Сюда входят базовое оборудование, программное обеспечение и сетевая инфраструктура, а также инструменты и платформы, используемые командами разработки и эксплуатации.
Другими словами, DevOps занимается улучшением способов разработки и доставки программного обеспечения, а проектирование платформ занимается созданием и обслуживанием платформ и инструментов, поддерживающих этот процесс.
Хотя и DevOps, и проектирование платформ дополняют друг друга, они служат разным целям. DevOps помогает командам работать вместе более эффективно и быстрее выпускать программное обеспечение, а разработка платформы предоставляет инфраструктуру и инструменты, необходимые для поддержки этого процесса.
С чего начать?
При изучении DevOps важно иметь четкое представление об инструментах и методах, обычно используемых в этой области. Вот некоторые из наиболее важных инструментов и методов для изучения:
- Системы контроля версий. Понимание того, как использовать системы контроля версий, такие как Git, является ключевым компонентом DevOps. Системы контроля версий позволяют командам отслеживать изменения в своем коде, совместно работать над проектами и при необходимости откатывать изменения. Я предполагаю, что вы знакомы с git, поэтому пропустите его и сразу перейдете к следующему этапу.
- Инструменты непрерывной интеграции (CI) и непрерывного развертывания (CD). Инструменты CI/CD лежат в основе DevOps и используются для автоматизации сборки, тестирования и развертывания кода. Популярные инструменты CI/CD включают Jenkins, Travis CI, CircleCI и GitLab CI/CD. Я сосредоточусь на GitHub Actions. Это непопулярный инструмент в сфере DevOps, поскольку он относительно ограничен, но для нужд разработчиков он вполне подходит.
- Инструменты "Инфраструктура как код" (IaC). Инструменты IaC позволяют нам управлять нашей инфраструктурой, как если бы это был исходный код. Это упрощает автоматизацию подготовки, настройки и развертывания инфраструктуры. Популярные инструменты IaC включают Terraform, CloudFormation и Ansible. Мне также нравится Pulumi, который позволяет использовать обычные языки программирования для описания инфраструктуры, включая Java.
- Контейнеризация. Технологии контейнеризации, такие как Docker, позволяют упаковывать и развертывать приложения согласованным и переносимым способом, упрощая перемещение приложений между средами разработки, тестирования и производства.
- Оркестровка. Под оркестровкой понимается автоматическая координация и управление несколькими задачами и процессами, часто в нескольких системах и технологиях. В DevOps оркестрация используется для автоматизации развертывания и управления сложными многоуровневыми приложениями и инфраструктурой. Популярные инструменты оркестрации включают Kubernetes, Docker Swarm и Apache Mesos. Эти инструменты позволяют командам управлять контейнерами и развертывать их, автоматизировать масштабирование приложений и управлять общим состоянием и доступностью своих систем.
- Инструменты мониторинга и ведения журнала. Инструменты мониторинга и ведения журнала позволяют отслеживать производительность и поведение ваших систем и приложений. Популярные инструменты мониторинга включают Nagios, Zabbix и New Relic. Prometheus и Grafana, пожалуй, самые популярные в этой области в последние годы. К популярным инструментам ведения журналов относятся ELK Stack (Elasticsearch, Logstash и Kibana), Graylog и Fluentd.
- Инструменты управления конфигурацией. Инструменты управления конфигурацией, такие как Puppet, Chef и Ansible, позволяют автоматизировать настройку и управление вашими серверами и приложениями.
- Платформы облачных вычислений. Платформы облачных вычислений, такие как Amazon Web Services (AWS), Microsoft Azure и Google Cloud Platform (GCP). Они предоставляют инфраструктуру и услуги, необходимые для практики DevOps.
В дополнение к этим инструментам также важно понимать практики и методологии DevOps, такие как Agile.
Помните, что конкретные инструменты и методы, которые вам необходимо изучить, будут зависеть от потребностей вашей организации и проектов, над которыми вы работаете. Однако, имея четкое представление о наиболее часто используемых инструментах и методах DevOps, вы будете хорошо подготовлены к решению широкого круга проектов и задач.
Большинство функций и возможностей можно передавать. Если вы изучите принципы CI в одном инструменте, переход на другой не будет гладким. Но это будет относительно легко.
Контроль версий
Мы все используем git, по крайней мере, я на это надеюсь. Доминирование Git в управлении версиями значительно упростило создание решений с глубокой интеграцией. Как разработчики, Git в первую очередь рассматривается как система контроля версий, которая помогает нам управлять и отслеживать изменения в нашей кодовой базе. Мы используем Git для совместной работы с другими разработчиками, создания веток и управления ими, слияния изменений кода, отслеживания проблем и ошибок. Git — это важный инструмент для разработчиков, поскольку он позволяет им эффективно работать над проектами кода.
У DevOps другая точка зрения. Git рассматривается как важнейший компонент конвейера CI/CD. В этом контексте Git используется как репозиторий для хранения кода и других артефактов, таких как файлы конфигурации, сценарии и файлы сборки. Специалисты DevOps используют Git для управления конвейером выпуска, автоматизации сборок и управления конфигурациями развертывания. Git — важная часть цепочки инструментов DevOps, поскольку она позволяет легко интегрировать изменения кода в конвейер CI/CD, обеспечивая своевременную доставку программного обеспечения в производство.
Защита ветки
По умолчанию проекты GitHub позволяют любому фиксировать изменения в основной (главной) ветке. Это проблема в большинстве проектов. Обычно мы хотим предотвратить коммиты в этой ветке, чтобы мы могли контролировать качество основной ветки. Это особенно актуально при работе с CI, так как перерыв в мастере может остановить работу других разработчиков.
Мы можем свести к минимуму этот риск, заставив всех работать с ветками и отправлять пул-реквесты мастеру. Это можно продвинуть дальше с помощью правил проверки кода, которые требуют одного или нескольких рецензентов. GitHub имеет легко настраиваемые правила, которые можно включить в настройках проекта. Как вы можете видеть здесь.
Включение защиты ветки в главной ветке GitHub дает несколько преимуществ, в том числе:
* Предотвращение случайных изменений в главной ветке: Включив защиту ветки в главной ветке, вы можете предотвратить случайное внесение изменений в ветку участниками. Это помогает гарантировать, что основная ветка всегда содержит стабильный и проверенный код. * Принудительные проверки кода: вы можете потребовать, чтобы все изменения в основной ветке были проверены одним или несколькими людьми, прежде чем они будут объединены. Это помогает обеспечить высокое качество изменений в главной ветке и соответствие стандартам вашей команды. * Предотвращение принудительной отправки: включение защиты ветки в главной ветке может предотвратить принудительную отправку изменений в ветку участниками, которые могут перезаписать изменения, сделанные другими. Это помогает гарантировать, что изменения в ветке master вносятся преднамеренно и тщательно. * Принудительные проверки состояния: вы можете потребовать, чтобы определенные критерии, такие как прохождение тестов или успешные сборки, были соблюдены, прежде чем изменения в основной ветке будут объединены. Это помогает гарантировать, что изменения в основной ветке будут высокого качества и не приведут к новым ошибкам или проблемам.
В целом, включение защиты ветки в главной ветке в GitHub может помочь гарантировать, что изменения в вашей кодовой базе тщательно просматриваются, тестируются и имеют высокое качество. Это поможет повысить стабильность и надежность вашего программного обеспечения.
Работа с запросами на включение
Как разработчики, мы считаем, что работа с ветвями и запросами на вытягивание позволяет нам собирать несколько отдельных коммитов и изменений для одной функции. Это одна из первых областей совпадения между нашей ролью разработчиков и ролью DevOps. Запросы на вытягивание позволяют нам сотрудничать и проверять код друг друга, прежде чем объединять его в основную ветку. Это помогает выявлять проблемы и гарантирует, что кодовая база останется стабильной и согласованной. С помощью запросов на вытягивание команда может обсуждать и просматривать изменения в коде, предлагать улучшения и выявлять ошибки до того, как они попадут в рабочую среду. Это критически важно для поддержания качества кода, сокращения технического долга и обеспечения возможности сопровождения кодовой базы. Роль DevOps заключается в том, чтобы настроить соотношение качества и оттока.
Сколько рецензентов у нас должно быть для запроса на включение? Требуется ли специальный рецензент? Нужны ли нам уровни тестового покрытия?
DevOps необходимо настроить соотношение между производительностью разработчиков, стабильностью и оттоком. Увеличивая количество рецензентов или навязывая рецензию конкретному инженеру, мы создаем узкие места и замедляем разработку. Обратная сторона — потенциальное повышение качества. Мы выбираем эти показатели на основе эмпирических правил и лучших практик. Но хороший инженер DevOps будет следить за всем с помощью показателей, которые помогут принять обоснованное решение в будущем. Например, если мы заставим двух рецензентов, мы сможем посмотреть на время, необходимое для слияния запроса на включение, которое, вероятно, увеличится. Но мы можем сравнить это с количеством регрессов и проблем после того, как политика имела место. Таким образом, у нас есть четкое и фактическое представление о затратах и преимуществах полиса.
Второе преимущество запросов на вытягивание — их решающая роль в процессе CI/CD. Когда разработчик создает запрос на вытягивание, он запускает автоматизированный процесс сборки и тестирования, который проверяет, что изменения кода совместимы с остальной кодовой базой и что все тесты пройдены. Это помогает выявлять любые проблемы на ранних этапах процесса разработки и предотвращает попадание ошибок в рабочую среду. После успешного завершения процессов сборки и тестирования запрос на вытягивание может быть объединен с основной веткой, что приведет к запуску конвейера выпуска для развертывания изменений в рабочей среде. В следующей части этой серии я расскажу о CI более подробно.
Наконец-то
Я чувствую, что обсуждение DevOps часто очень расплывчато. Между ролью DevOps-инженера и ролью разработчика нет жесткой границы, поскольку они являются разработчиками и частью команды R&D. DevOps преодолевают эту тонкую грань между администрированием и разработкой, им необходимо удовлетворять иногда противоречивые требования с обеих сторон. Я думаю, что понимание их работы и инструментов может помочь нам стать лучшими разработчиками, лучшими товарищами по команде и лучшими менеджерами.
В следующий раз мы обсудим создание конвейера непрерывной интеграции с помощью действий GitHub. Работа над своими артефактами. Управление секретами и держать все под контролем. Обратите внимание, что на данном этапе мы не будем подробно обсуждать непрерывную доставку, потому что это затянет нас в обсуждение развертывания. Я полностью намерен вернуться к нему и обсудить компакт-диск, как только мы рассмотрим такие технологии развертывания, как IaC, Kubernetes, Docker и т. д.
Оригинал