Руководство TeamLead'a

В данном руководстве приведены основные правила, которым должен следовать TeamLead в IT департаменте LR/CB.

Монорепа VS Мультирепа

Монорепозиторий - все части приложения (кроме open-source библиотек/фреймворков) хранятся в одном репозитории

Мультирепозиторий - все части приложения разбиты по отдельным репозиториям.

Мы используем подход МОНОРЕПОЗИТОРИЯ

Почему? - потому что такие проекты легче поддерживать как со стороны разработки, так и со стороны DevOps структуры, в т.ч. и приватные сервисы/пакеты.

Если речь идет про монорепозиторий с множеством сервисов и пакетов, то вы должны использовать yarn. Также вы можете использовать инструменты: husky и commitizen.

Постановка задачи

Задачи ставятся в YouGile. Доступ к нему обеспечивает руководитель IT департамента или TeamLead.

Статусы задач: 🦖 Backlog -> 🚀 To Start -> 👍 In Work -> ⏳ In Review -> ✅ Done

Стикеры к задаче: дедлайн/таймер*, тип задачи*, приоритет*, исполнитель*, модуль

Система учета багов

Все баги создаются в GitHub в разделе Issues.

Шаблон баг-отчета для добавления в .github/ISSUE_TEMPLATE/bug_report.md:

---
name: Баг-отчет
about: Создайте отчет, чтобы помочь нам стать лучше
title: '[BUG]: Описание ошибки'
labels: ['bug']
assignees: teamlead_nickname
projects: ['PROJECT-NAME']

---

**Опишите ошибку**
Четкое и краткое описание ошибки.

**Воспроизвести**
Шаги для воспроизведения поведения:
1. Перейдите к «...»
2. Нажмите «….»
3. Прокрутите вниз до «….»
4. См. ошибку

**Ожидаемый результат**
Четкое и краткое описание того, что вы ожидали.

**Фактический результат**
Четкое и краткое описание того, что вы ожидали.

**Окружение:**
  - Устройство: [например. iPhone XR]
  - ОС: [например. IOS]
  - Браузер [например. Chrome, Safari, Firefox]
  - Версия [например. 22]
  - Разрешение [например. 900x1024]

**Скриншоты**
Если применимо, добавьте снимки экрана, чтобы объяснить проблему.

**Дополнительный контекст**
Добавьте любой другой контекст проблемы здесь, если необходимо.

Лейблы для багов:

• Блокирующий - Система полностью не работает

• Высокий - Элементы системы работают неверно

• Критический - Важная часть системы не работает

• Незначительный - Опечатки/ проблемы с версткой

• Низкий - Система работает, но пользоваться неудобно

Выпуск релизов

Работая над проектом, придерживайтесь семантического версионирования semver.

ci/cd

На проекте обязательно должен быть настроен ci/cd с настроенным docker-контейнером.

Тестовый стенд

На проекте рекомендуется настроить раскатку тестовых стендов (когда, где и сколько вы решаете самостоятельно, в зависимости от условий проекта).

Все же основной тестовый стенд раскатывается в ветке develop в GitHub, и обновляется по выпуску pre-release. Отмечайте причастных разработчиков к релизу.