Как были организованы рабочие процессы на предыдущем месте работы?

Ага, смотри, как мы тут всё организовали, чтобы не превратиться в стадо мартышлюшек, которые пилят код в полной жопе. Всё по Agile, но без этого ебанного фанатизма, когда каждый митинг — это пиздец какой перформанс.

1. Ветки — наше всё, но без фанатизма. Сидели, думали — какой GitFlow выбрать. Классический? Да ну его нахуй, слишком много церемоний. Сделали модифицированный, чтоб мозг не вытекал.

• Главные ветки: main — тут у нас святое, продакшен, тронуть можно только через горящий обруч. develop — тут всё кипит, как в котле у ведьмы.
• Ветки для задач: Всё просто, как три копейки. Хочешь новую фичу — feature/PROJ-123-название. Чинишь баг — bugfix/. Всё горит и срочно — hotfix/. ID задачи из Jira в названии, чтобы потом не ебать мозг, что это за хуйня.

# Рабочий день обычного разработчика:
git checkout develop # Переключился на основную кухню
git pull origin develop # Подтянул свежие ингредиенты
git checkout -b feature/PROJ-123-enhanced-search # Создал свою песочницу
# Тут два дня пишешь код, пьешь кофе...
git push origin feature/PROJ-123-enhanced-search # Вывалил всё на обозрение
# И создаёшь Pull Request — мол, ребята, полюбуйтесь на моё творение, а теперь давайте его разнесите в хлам.

2. Код-ревью — священная корова. Без этого — ни шагу. Правило железное: два аппрува минимум. Не просто "ок", а внятные комментарии. Чеклист у ревьювера:

• Код не выглядит так, будто его писал кот, наступивший на клавиатуру? (Соответствие код-стайлу)
• Ты это хоть как-то протестировал, или мы должны верить на слово? (Наличие тестов)
• Сломав это, мы не отправим в нокдаун половину приложения? (Отсутствие регрессий)
• Ты написал, как это работает, или это теперь тайна великая? (Качество документации) А ещё SwiftLint и юнит-тесты автоматом прогоняются — если тут красное, даже не суйся.

3. CI/CD — наш робот-раб. Всё на Bitrise. Настроили пайплайн, который работает, пока мы спим (или делаем вид, что работаем).

Этапы:
1. Запуск unit-тестов (Если упали — всё, пиздец, иди чини)
2. Сборка проекта (Соберётся — уже хорошо)
3. Статический анализ кода (Ищет косяки, которые мы просрали)
4. Генерация IPA (Вот он, почти артефакт)
5. Деплой на TestFlight (Отправка в зону тестирования)
6. Уведомление команды (Всем в слаке: "Собрали! Можно качать!")

Автоматизация — это, блядь, святое. Руками ничего не делаем, чтоб не накосячить.

4. Управление задачами — чтобы не было бардака.

• Jira — наша библия. Тут бэклог, спринты, эпики (это такие жирные задачи), стори поинты (оценки сложности, чтоб не пиздеть на планировании).
• Confluence — свалка знаний. Архитектура, решения, гайды. Чтоб не объяснять каждому новому, где тут туалет.
• Мероприятия регулярные, как понос:
  • Daily standup (15 мин): Что сделал, что будешь делать, что мешает. Быстро, без воды. Кто начал рассказывать про свою собаку — получает тапком.
  • Planning (2 часа): Что делаем в следующем спринте. Спорим, тыкаем пальцами в оценки, в итоге договариваемся.
  • Retrospective (1.5 часа): Что было хорошо, что было хуёво, что будем делать иначе. Главное — без перехода на личности, а то будет мордобой.
  • Demo (1 час): Показываем, что наворотили за спринт. Похвастаться, так сказать.

5. Контроль качества — чтоб не опозориться перед пользователями.

• QA-тестирование — это святое. Ни одна фича не попадает в develop, пока тестировщик её не потрогал и не сказал "ок".
• Стабилизационная ветка перед релизом — туда сливаем всё, что готово, и потом только баги фиксим, ни одной новой фичи. Чтоб не принести в релиз какую-нибудь неожиданную дичь.
• Мониторинг крашей через Firebase Crashlytics — если у пользователей всё падает, мы узнаем об этом первыми. Ну, почти.
• Регрессионное тестирование для самого важного функционала — чтобы, добавляя новую кнопку, не сломать авторизацию.

Вот так, примерно. Вроде бюрократии дохуя, но на самом деле она отъедает не так много времени, зато спасает от полного пиздеца. А без этого — волнение ебать, доверия ноль, и проект накрывается медным тазом через полгода.