Какой был релизный цикл на последней работе?

Релизный цикл на последнем проекте (B2C мобильное приложение)

На последнем месте работы мы использовали гибридную модель релизного цикла, сочетающую элементы Scrum (для разработки фич) и Continuous Delivery (для инфраструктуры и стабильности). Основной целью было обеспечить баланс между скоростью поставки нового функционала и поддержанием высокой стабильности приложения с миллионной аудиторией.

Ключевые этапы и практики

1. Планирование и разработка (Scrum Framework):

• Работали в двухнедельных спринтах. Бэклог формировался из эпиков, разбитых на пользовательские истории.
• Каждая история проходила 3-этапный процесс:

  // Пример workflow задачи в Jira:
  // 1. Backlog -> In Development (кодирование, модульные тесты)
  // 2. In Development -> Code Review (обязательный ревью кода коллегой)
  // 3. Code Review -> QA
  // 4. QA -> Done
  

• Code Review был обязательным перед мерджем в основную ветку (develop). Использовали Git Flow с адаптациями.

2. Непрерывная интеграция и тестирование (CI/CD):

• На каждый пулл-реквест в develop автоматически запускался pipeline в Jenkins:

    *   Сборка проекта.
    *   Запуск **unit-тестов** и **статического анализа кода** (Detekt, Android Lint).
    *   Деployment сборки на **Firebase App Distribution** для внутреннего тестирования.

• Ветка develop считалась "всегда готовой к выпуску". После мерджа PR автоматически собиралась ночная сборка, на которой запускались UI-тесты (Espresso) на эмуляторах в Firebase Test Lab.

3. Релизный процесс и дистрибуция:

• Каждую неделю (по четвергам) из develop создавалась релизная ветка (release/x.x.x).

    *   В ней фиксировались только **критические багфиксы** и **переводы**.
    *   Проводилось **регрессионное тестирование** QA-командой.

• После sign-off QA, ветка мерджилась в main и создавался тэг.
• Релиз в Google Play осуществлялся по фазированной модели (gradual rollout):

    *   День 1: релиз для 5% пользователей.
    *   День 2-3: мониторинг ключевых метрик (**Crash-free rate**, ANR rate, конверсии) через **Firebase Crashlytics** и **Google Play Console**.
    *   При отсутствии критических проблем — увеличение до 50%, затем до 100% в течение недели.

4. Мониторинг и обратная связь:

• После полного релиза мы активно мониторили:

    *   **Crashlytics** и **ANR-отчеты** в реальном времени.
    *   **Отзывы в Google Play** (автоматически парсились в Jira).
    *   Ключевые бизнес-метрики (**Amplitude**, **AppMetrica**).

• Для горячих фиксов использовался App Distribution (Google Play) или, в крайних случаях, remote config для отключения проблемного функционала.

Инструменты и технологии

• Version Control: Git, Git Flow.
• CI/CD: Jenkins, Fastlane для автоматизации сборки и загрузки в магазины.
• Тестирование: JUnit, Espresso, Firebase Test Lab, ручное тестирование.
• Мониторинг: Firebase Crashlytics, Performance Monitoring, Google Play Console, Amplitude.
• Task Tracking: Jira, Confluence для документации.

Такой подход позволял нам выпускать стабильные обновления каждые 1-2 недели, быстро реагировать на инциденты и иметь прозрачный для всей команды процесс, от идеи до релиза. Ключевым вызовом была координация между iOS и Android командами для синхронных релизов, что требовало четкой коммуникации на этапе планирования спринтов.