- Новые issues создаются и добавляются в столбце New issues
- Planned - Needs Definition - здесь карточки, которые нужно сформулировать в конкретные issues. Если issue получается очень большая, то разбиваем ёё на небольшие issue так, чтобы на их выполнение уходило не больше недели. Создаём Epic и группируем связанные issue в этом Epic
- Поместите issue либо Epic в колонку Product Backlog после завершения определения. Четко определенная issue будет включать в себя описание требования, ключевые результаты/определение выполненного, макеты, если нужно
- Расставить карточки по порядку приоритета, что самое важное – вверх. Можно обсудить с командой
Примечание:
Спринт длится 2 недели. Определяем что мы будем делать: исправлять ошибки, добавлять новые функции, или все вместе.
- Сначала проверьте, нет ли Pull Request, Issues, которые назначены вам, они в приоритете
- Выберите одну, или несколько задач из Product Backlog
- Проверьте что задача четко определена
- Перенесите карточку либо карточки в Sprint Backlog
- Назначьте себя исполнителем issue
- Перенесите карточку в In Progress
- Создайте новую ветвь от текущей рабочей ветви (develop)
- Решите issue
- Во время работы над issue старайтесь фиксировать (коммитить) небольшие изменения, и давать им понятные названия
- Создайте PR для feature-ветки в develop
- При создании PR необходимо коротко описать проделанную работу в Description
- Убедитесь, что PR связан с соответствующей рассматриваемой issue
- Убедитесь, что для проверки PR, назначено как минимум 2 Reviewers. Уведомите Reviewers о том, что им необходимо проверить PR
- Проведите ручную проверку кода, чтобы убедиться, что нет простых ошибок, таких как оставшиеся комментарии и console.log()
- При создании PR карточка автоматически перемещается в Review/QA
- Если сделана последняя задача из Epic то перенесите Epic в Review/QA
- Если есть замечания по коду от Reviewers, вы получите комментарии по недостаткам кода
- Как только получаете два одобрения, подтверждаете запрос на слияние веток (merge pull request)
- После слияния веток удалите ветку, над которой вы работали
- Перенесите карточку в Done
- По окончании Sprint Review перенесите карточку в Closed
Примечание:
По окончании спринта делать release в ветку master
где type - тип ветви (feature, fix) name - псевдоним разработчика, работающего над ветвью number - номер прикрепленного issue GitHub
Например, feature-john-34
Примечание:
Если над проектом идёт командная работа, то при создании ветви необходимо указывать псевдоним разработчика, работающего над ветвью. В случае, если над ветвью работают несколько разработчиков, псевдоним не указывают. Этого правила надо также придерживаться в случае, если вы один работаете над проектом (feature-12)
- Убедитесь, что шаги для воспроизведения ошибки ясны и точны
- Если ошибка критичная, то делаем hotfix ветку от master, проходим все шаги; если все в порядке, то публикуем в master и в develop
- Если ошибка не критичная, то работаем по обычной схеме
- Не допускать закомментированных кусков кода, console.log()
- Changelog и version в package.json надо обновить (sermver)
- Стараться придерживаться codestyle. Если есть какие-то добавления, замечания - дополнять ими стандарт оформления кода
- Не забывать про документацию. Если внесены изменения в UI/UX, отметить это в документации, обновить скриншоты
Учитывая номер версии {major}.{minor}.{patch}, следует увеличивать:
- major-версию, когда сделаны обратно несовместимые изменения API
- minor-версию, когда вы добавляете новую функциональность, не нарушая обратной совместимости
- patch-версию, когда вы делаете обратно совместимые исправления
Семантическое версионирование также поддерживает и дополнительные части, идущие после патч версии. Например, там могут быть метки о том что это предварительный релиз или какой-то конкретный билд. Например: 1.2.3-beta.1, 1.2.3+abc123 или 1.2.3-beta.1+abc123 — обратите внимание что билд отделяется + (плюс), а наименование предварительного релиза - (дефис). Данные дополнительные указатели говорят о том, что релиз не стабильный, и в нём могут как всё поменять, так и вовсе удалить, либо добавить совершенной новый функционал в будущем.
Для подробного ознакомления с семантическим версионированием перейдите на страницу Semantic Versioning
Все заметные изменения необходимо задокументировать в этом файле
- заголовок изменения
- заголовок изменения
- заголовок изменения
- заголовок изменения
- заголовок изменения
- заголовок изменения
- В коде должны быть понятные имена для переменных
- Выносить дублируемые куски кода в файл helper.js, который находится в корне проекта
- Стараться создавать файлы, код которых не превышает 100 строк
- Искать возможность вынести код в RCL, или расширить существующую библиотеку
- Использовать hooks для того чтобы оптимизировать приложение
- Не делать слишком перегруженный код с множеством if/else
- После себя оставлять код чуточку чище и лучше
- Если кусок кода сложен для понимания - надо добавить комментарии в формате jsdocs
Для форматирования кода в проекте настроен eslint и prettier.
Для деплоя настроены экшены.
Деплой делается в netlify.
Единственными конкретными папками Next.js являются папки pages, public и styles
- components
- Appbar.js
- pages
- api
- getUser.js
- _app.js
- index.js
- public
- favicon.ico
- vercel.svg
- styles
- globals.css
- utils
- hooks.js
- supabaseClient.js
- CHANGELOG.md
- .env.local.example
- helper.js
- workflow.md
components - Здесь находятся компоненты приложения, которые переиспользуются на страницах
pages - Это компоненты React. Каждый файл — это страница, а каждая страница — это компонент React.
_app.js - Это пользовательский компонент, который находится в папке страниц. Next.js использует этот компонент для инициализации страниц
index.js - Это страница, которая отображается, когда пользователь посещает корень приложения
api - Здесь находятся маршруты API (API routes) и сопоставляются с конечной точкой
Импорт стараемся группировать.
- React
- Next
- сторонние контексты/компоненты/хуки
- наши контексты/компоненты/хуки
- наши константы/конфиги/хэлперы
- картинки/иконки
Например
import { useState, useEffect, useRef } from 'react'
import Head from 'next/head'
import { useRouter } from 'next/router'
import Layout from '../components/Layout'
import VcanaLogo from '../public/vcana-logo.svg'- Макет
- Флексбокс и Сетка
- Интервал
- Размеры
- Типография
- Фоны
- Границы
- Эффекты
- Фильтры
- Переходы и анимация
Например
className="custom-class group absolute flex justify-center pt-0 w-1/4 sm:w-1/3 md:w-1/2 text-xl text-slate-100 bg-orange-500 border-r-2 border-stone-800 shadow-md cursor-pointer hover:text-gray-100 hover:bg-blue-500"Scrum - методология управления проектами.
Kanban - это метод, в основе которого лежит система вытягивания (pull system) производства, то есть, ограничение на количество незавершенной работы (work-in-process). Здесь все устроено так, чтобы застоявшиеся issue легко было отследить и перераспределить внутри команды. Это позволяет обнаруживать операционные проблемы и мотивировать сотрудников к улучшениям.
Pipeline - колонки доски, которые служат для разбиения этапов работы над issue
Issue - задача, созданная в репозитории или в ZenHub. Обладает свойствами:
- Labels - ярлыки, помогающие классифицировать issue, для каждой issue можно поставить один или несколько ярлыков
- Milestones - фазы проекта, позволяет соотносить issue с фазами в которых они должны быть реализованы
- Estimates - оценка трудоемкости issue (измеряется в story points). Без данного показателя невозможно использовать диаграммы ZenHub
- Assignees - исполнители issue
- Dependencies - зависимости. Позволяет определить те issue, которые зависят от исполнения других
Pull Request (PR) - это запрос на интеграцию изменений из одной ветки в другую
Reviewer - обозреватель запроса на интеграцию изменений из одной ветки в другую
Bug - ошибки в системе. issue с данным лейблом имеют наивысший приоритет и должны быть взяты в работу первыми.
Feature - новая функциональность
fix - Если вы работаете над исправлением ошибок проекта, то ветвь начинается со слова fix
Refactoring - issue, связанные с корректировкой ранее написанного кода
WIP - issue, находящиеся в работе
Deploy — это процедура переноса сайта на сервер
JSDoc — генератор документации в HTML-формате из комментариев исходного кода на JavaScript
New Issues Этот Pipeline является отправной точкой для новых issues. Любой из команды может создать issue в любое время и знать, что благодаря этому процессу она будет видна всем.
Icebox issues с низким приоритетом, которые не будут нужны в ближайшее время
Epics это тема работы, которая содержит несколько issues. Эпики — это лучший способ сгруппировать связанные issues в более крупные цели, охватывающие спринты
Planned - Needs Definition issues, которые нужно рассмотреть и оценить. Если issue получается очень большой, то превращаем карточку в Epic
Product Backlog Предстоящие issues, которые были рассмотрены, оценены и расставлены по приоритетам сверху вниз
Sprint Backlog issues, готовые к работе в спринте, с приоритетом сверху донизу.
In Progress issues, над которыми сейчас работает команда
Review/QA issues, которые открыты для тестирования. Код завершен, ожидается отзыв
Done issues протестированы и готовы к развертыванию в рабочей среде