Недавно мы писали о том, как четыре фигурные скобки на 4 часа остановили работу крупного сервиса Skyscanner. В комментариях тогда заметили, что скоро должность «Senior YAML Developer» может перестать быть шуткой.
К старту курса по DevOps делимся рекомендациями из блога Github, которые могут помочь начинающему разработчику избежать ошибок команды Skyscanner.
DevOps сегодня в сфере технологий нарасхват — от CI/CD (непрерывной интеграции и развёртывания ПО) до управления контейнеризацией и подготовки серверов. Можно даже сказать, что это модное словечко... на слуху. Как разработчик вы можете быть частью команды DevOps — не обязательно готовить серверы к работе и управлять контейнерами, но создавать отличное ПО.
Многое из того, чем занимаются разработчики, инженеры DevOps и ИТ-команды в современном жизненном цикле разработки ПО, — это инструменты, тестирование, автоматизации и оркестрация серверов.
Особенно если команда участвует в большом проекте Open Source или речь идёт об одном человеке. Предлагаем вашему вниманию пять рекомендаций по DevOps для разработчиков, желающих работать эффективнее и быстрее.
YAML упрощает работу фронтенда
Появившись в 2001 году, YAML стал одним из языков для многих декларативных автоматизаций — его часто используют в DevOps и разработке разных интерфейсных конфигураций, автоматизации и т. д. YAML расшифровывается как Yet Another Markup Language («ещё один язык разметки»). Разметка YAML легко читается. В нём слабее акцент на символах типа круглых и фигурных скобок и кавычек {}, [], ".
Почему это важно? Изучая или даже совершенствуя свои навыки YAML, вам проще сохранять конфигурации для приложений, например настройки на удобном для написания и чтения языке.
Файлы YAML повсюду: от рабочих процессов корпоративной разработки до проектов с открытым исходным кодом. Много файлов YAML и на GitHub (они поддерживают продукт, который нам очень нравится: GitHub Actions, но о нём позже).
Где бы вы ни применяли YAML — в рутинных рабочих процессах или при использовании различных инструментов с YAML — начать работу с этим языком или отточить свои навыки в YAML очень полезно. Хотите узнать больше о YAML? Попробуйте Learn YAML in Y Minutes guide («Руководство по изучению YAML за Y минут»).
Инструменты DevOps помогают ускориться
Сначала проясним кое-что: инструменты DevOps — это широкое понятие, охватывающее облачные платформы, инструменты оркестрации серверов, управление кодом, контроль версий и многое другое. Всё это технологии, которые упрощают написание, тестирование, размещение, выпуск ПО и оставляют в прошлом любые опасения по поводу неожиданных сбоев. Вот три инструмента DevOps, которые позволят ускорить рабочие процессы и сосредоточиться на создании отличного ПО.
Git
Наверняка вы знаете, что Git — это распределённая система контроля версий и инструмент управления исходным кодом. Для разработчиков это основа основ и популярный инструмент DevOps.
Почему?
Git упрощает контроль версий, позволяет вести совместную работу, экспериментировать с различными ветками и объединять новые функции в основную ветвь разработки.
Узнайте больше о том, как работает Git [мы заменили англоязычную ссылку на статью ссылкой на перевод подробной книги о Git. — прим. ред.]
Облачные интегрированные среды разработки (IDE)
Знаю, произносить это вслух трудновато (спасибо, маркетинг). Проще будет — облачные IDE. Но эти платформы стоит начать изучать немедленно.
И вот почему. Облачные IDE — это размещаемые полностью среды разработки, позволяющие писать и запускать код, выполнять его отладку, а также быстро разворачивать новые, предварительно настроенные среды. Нужны подтверждения? В начале года мы запустили собственную облачную IDE Codespaces и начали использовать её для создания GitHub. Раньше на развёртывание новых сред разработчика у нас уходило до 45 минут — теперь лишь 10 секунд.
С облачными IDE очень просто и быстро разворачивать новые, предварительно настроенные среды разработки, в том числе одноразовые. Кроме того, с ними не надо думать о мощности компьютера (привет всем, кто отважился писать код на планшетах).
Представьте: ноутбук вдруг загорается (со мной это случалось пару раз). А там версии npm, инструменты подключения к облачному провайдеру и куча настроек! С IDE вы развёртываете среду в облаке со всеми конфигурациями, и это просто магия.
Узнайте, как работают облачные IDE
Контейнеры
Не хотите облачную IDE? Используйте контейнеры — локально или в облаке. За последние 10 лет популярность контейнеров резко выросла благодаря их использованию в архитектуре микросервисов, CI/CD, разработке облачных приложений и т. д. По своей сути контейнеры легковесны и эффективны: с ними легко создавать, тестировать, прогонять по этапам сборки и развёртывать ПО.
Освоение основ контейнеризации очень полезно — особенно при тестировании кода в легковесной среде, имитирующей эксплуатационную. С контейнерами также очень легко обновить библиотеку или попробовать приложение в следующей версии до перехода на продакшн.
Особенно полезно это для «сдвига влево» — важной стратегии DevOps. Выявление ошибок или проблем до перехода к продакшну избавит от лишней головной боли. Найти эти ошибки во время написания кода — ещё лучше. Любые проблемы в итоге прибавляют работы, поэтому, чем раньше их найдёте, тем лучше. Опять же, выявление проблемы до перехода к этапу компиляции избавит от лишней головной боли.
Узнайте, как работают контейнеры.
Автоматизированное тестирование и непрерывная интеграция (CI) позволяют быть на шаг впереди
В разговорах о DevOps часто упоминают об этих двух понятиях. Автоматизированное тестирование, будучи обычно частью практики CI, не является строгим требованием (хотя должно быть... по крайней мере частью этапа непрерывного развёртывания ПО).
Многие команды ограничиваются базовым модульным тестированием в рамках процесса CI, обходясь без автоматизированного тестирования пользовательского интерфейса, интеграционного тестирования, выявления уязвимостей безопасности и т. д.
Но как ускорить рабочие процессы и уменьшить нагрузку на команду DevOps?
1. Убедитесь, что код работает с главной веткой.
2. Находите уязвимости безопасности и другие проблемы.
Ниже о том, как это можно сделать.
GitHub Actions для автоматизации тестирования
С GitHub Actions возможно многое — к примеру, заказать пиццу или активировать сигнал тревоги. Всё сводится к автоматизации рабочего процесса. Чтобы настроить тесты с помощью GitHub Actions, создайте свой Action или примените готовый из GitHub Marketplace.
Узнайте, как автоматизировать рабочиек процессы с GitHub Actions.
Рекомендация профессионала: отличный способ проверить наличие уязвимостей безопасности и проблем в коде перед объединением с главной веткой — это использование рабочих процессов GitHub Actions, которые запускаются в ответ на запросы на включение изменений в репозиторий проекта. В итоге главная ветка чистая, а вы — на шаг впереди.
Также можно настроить рабочие процессы для развёртывания во временных тестовых средах. То есть запускать тесты и развёртывать изменения в среде и в ней тестировать приложение. Можно даже настроить рабочий процесс так, чтобы после завершения автоматически удалять эти тестовые среды. Всё это позволяет протестировать как можно больше до перехода к производственной среде.
Использование GitHub Actions для создания конвейеров CI
CI, или непрерывная интеграция, — это процесс автоматической интеграции кода нескольких пользователей проекта. Хорошая практика CI позволяет: быстрее работать; убедиться в том, что код компилируется корректно; более эффективно объединять изменения кода и быть уверенным, что код вписывается в работу других пользователей.
Самые мощные рабочие процессы CI — те, которые проверяют всё, что вам нужно, при каждом добавлении кода на сервер. Работаете на GitHub? GitHub Actions делают и это. На GitHub Marketplace много готовых рабочих процессов CI (и всегда можно создать свой), но при внедрении CI в процесс разработки стоит учитывать нюансы:
Запускайте необходимые тесты. Подумайте, какие средства автоматизации сборки, интеграции и тестирования вам нужны. Посмотрите, что было не так с прошлыми выпусками и не добавить ли тест для них в CI.
Оптимизируйте время, необходимое для тестирования кода, со скоростью запуска нового кода. Если вы добавляете новый код каждые пять минут (гипотетически), но выполнение тестов занимает 10 минут… это не очень хорошо. Всегда лучше соотносить, что и когда вы проверяете, с тем, сколько времени это занимает, и сокращать список тестов до более реалистичного их числа, по крайней мере для сборок CI.
Ознакомьтесь с руководством по созданию конвейера CI с GitHub Actions.
Оркестрация серверов для повышения гибкости и скорости
Если вы создаёте облачное приложение или даже просто используете разные серверы, виртуальные машины, контейнеры или хостинговые сервисы, то наверняка имеете дело с несколькими средами. Возможность убедиться, что приложение и инфраструктура подходят друг другу, уменьшает вашу зависимость от команды разработчиков, пытающихся запустить ПО на вашей инфраструктуре в последнюю минуту.
Здесь пригодится оркестрация серверов. Оркестрация серверов или инфраструктуры — это обычно задачи ИТ- и DevOps-команд. К ним относятся настройка, управление, подготовка и координация систем, приложений и базовой инфраструктуры для запуска ПО.
Рекомендация профессионала: есть набор инструментов, позволяющих определять и обновлять необходимую инфраструктуру.
Большое преимущество автоматизации инфраструктуры — улучшенная масштабируемость. Когда среды определены, их проще удалять и воссоздавать, когда что-то идёт не так (а не начинать с нуля, как это было обычно).
И ещё одно большое преимущество — если надо что-то протестировать, не нужно просить команду разработчиков настраивать сервер. Вы сделаете это в рамках рабочего процесса. И без подгонки вручную аппаратных или системных требований.
Как начать: не пытайтесь заменить всё в своей среде на автоматизированную автоматизацию инфраструктуры. Найдите часть, которую легко автоматизировать, и начните с неё, затем другую, потом следующую.
И никогда не запускайте в производственной среде. Начните с тестовой среды. Заработает там — переходите к промежуточной среде (если заработает в ней, будет работать и на боевом сервере).
Пробуйте писать повторяющиеся задачи на Bash или PowerShell
Представьте: у вас куча повторяющихся задач, выполняемых локально, и каждую неделю на них уходит слишком много времени. Есть лучший, эффективный способ работы с ними — писать скрипты с Bash или PowerShell.
Bash имеет глубокие корни в мире Unix. Это основа основ для ИТ-, DevOps-команд и многих разработчиков.
PowerShell моложе. Разработанная в Microsoft и запущенная в 2006 году, PowerShell заменила командную оболочку и ранние языки сценариев для автоматизации задач и управления конфигурацией в средах Windows.
Сегодня и Bash, и PowerShell кросс-платформенные (хотя большинство привыкших работать в Windows используют PowerShell, а большинство знакомых с Linux или macOS — Bash).
Рекомендация профессионала: Bash и PowerShell работают по-разному. Там, где PowerShell работает с объектами, Bash передаёт информацию в виде строк. Что выбрать — во многом зависит от личных предпочтений.
Например, я с помощью Bash и PowerShell сделал скрипт, который берёт последнюю версию кода, создаёт новую ветку, переключается на неё, отправляет в GitHub черновик запроса на включение изменений (пул-реквеста), а затем открывает VSCode (подраздел в выбранном редакторе) в этой ветке.
Это серия небольших этапов, к жизнь намного проще. Сделал её один-два раза в неделю, написал скрипт — и имеешь больше времени на то, что важно: написание отличного кода.
Итоги
Между ИТ-специалистом, инженером DevOps и разработчиком большая разница. Но в современном мире разработки ПО многие базовые практики DevOps становятся доступными для всех.
Кроме того, любому разработчику, который освоит несколько приёмов работы DevOps, легче работать самостоятельно (и притом более эффективно), продолжая фокусироваться на самом важном, то есть на создании отличного ПО. И сделать это может каждый из нас.
Коллекция инструментов DevOps и другие ссылки
Продолжить изучение DevOps или разработки вы сможете на наших курсах:
Узнайте подробности акции.
Другие профессии и курсы
Data Science и Machine Learning
Python, веб-разработка
Мобильная разработка
Java и C#
От основ — в глубину
А также
