В современной разработке программного обеспечения гибкие методологии, такие как Agile, стали золотым стандартом благодаря их способности адаптироваться к изменяющимся требованиям и поддерживать непрерывное улучшение продукта. Одним из ключевых элементов Agile является разработка через итерации, которые позволяют командам быстро и эффективно реагировать на потребности клиентов и пользователя. В этой статье мы рассмотрим типичный процесс разработки программного обеспечения, начиная от сбора требований до развертывания кода в производственную среду и последующего мониторинга.
Шаг 1: Создание пользовательских историй
Процесс начинается с владельца продукта, который создает пользовательские истории на основе собранных требований. Это краткие описания функций, которые должны быть реализованы, изложенные с точки зрения пользователя.
Пользовательские истории (user stories) — это краткое описание функционала, которое нужно разработать, изложенное с точки зрения конечного пользователя. Это один из основных элементов в методиках гибкой разработки (Agile). Цель пользовательских историй — определить, что именно пользователь или клиент желает получить от продукта и как это должно работать.
Каждая пользовательская история фокусируется на добавлении ценности для пользователя и обычно следует простой формуле:
- Кто: определяет, кто является целевым пользователем.
- Что: описывает, что пользователь хочет сделать.
- Почему: объясняет, почему это важно для пользователя.
Пример пользовательской истории:
Как [пользователь], я хочу [какую-то возможность], чтобы [достичь какой-то цели].
Пользовательские истории помогают команде разработки сосредоточиться на нуждах пользователей и обеспечивают структуру для планирования и приоритизации работы в рамках разработки продукта.
Шаг 2: Планирование спринта
Команда разработки выбирает пользовательские истории из общего списка (бэклога) и включает их в ближайший спринт, который обычно длится две недели. В этот период команда фокусируется на реализации выбранных историй, что позволяет систематически двигаться к завершению проекта.
Шаг 3: Работа с кодом
Разработчики фиксируют изменения в исходном коде в системе управления версиями, такой как Git. Это позволяет отслеживать изменения, вносимые в код, и обеспечивает возможность возврата к более ранним версиям при необходимости.
Шаг 4: Автоматизированная сборка
Зафиксированный код передается в систему сборки, например Jenkins, где автоматически запускаются юнит-тесты и анализ качества кода с помощью инструментов, таких как SonarQube. Это помогает гарантировать, что код соответствует заранее установленным стандартам качества и функциональности.
Шаг 5: Хранение сборок и развертывание в среде разработки
Успешные сборки сохраняются в репозитории артефактов, таком как Artifactory/Docker Hub и тд, и затем разворачиваются в среде разработки. Это позволяет разработчикам тестировать код в условиях, максимально приближенных к реальной эксплуатации.
Шаг 6: Тестирование функционала
Независимо тестирование различных функций происходит в специально предназначенных для этого тестовых средах. Это обеспечивает возможность проверки каждой функции в изоляции от других изменений.
Шаг 7: Комплексное тестирование качества
Команда QA проводит тестирование новых сред, включая regression и performance тестирование, чтобы убедиться, что новый код не влияет отрицательно на существующий продукт.
Шаг 8: Предпроизводственное тестирование (UAT)
После успешного прохождения всех тестов в QA, сборки перемещаются в предпроизводственную среду UAT, где конечные пользователи могут проверить новый функционал.
Шаг 9: Развертывание в производство
Если тестирование UAT успешно, сборки становятся кандидатами на выпуск и развертываются в производственной среде согласно расписанию.
Шаг 10: Мониторинг производственной среды
Команда инженерии надежности сайта (SRE) отвечает за мониторинг состояния производственной среды, обеспечивая стабильность и быстрое реагирование на возникающие проблемы.
Каждый из этих шагов является неотъемлемой частью процесса разработки, который помогает обеспечить выпуск качественного и функционально полноценного программного продукта.
Более подробно о каждом шаге мы поговорим в следующих статьях.
Еще больше полезных статей по теме DevOps/Sre/Admin/Networking в моем tg-канале: https://t.me/devopsbrain