Rose debug info
---------------

Заметки (не) разработчика

LinkedIn · Github · ИТ-консалтинг · Теги

Позднее Ctrl + ↑

asdf — менеджер версий языков программирования

Для установки пакетов на macOS я пользовался долгое время пакетным менеджером Homebrew. Утилита позволяет устанавливать и обновлять не только актуальные, но и major-версии:


$ brew install [email protected]

Однако, Homebrew не предоставляет функциональности для управления несколькими версиями пакетов, которые могут совместно существовать в пользовательском пространстве. Особенно, это критично, когда нет необходимости или желания использовать Docker, но есть потребность иметь разные версии языка программирования, например, для тестирования разрабатываемых библиотек или программного обеспечения.

Чтобы решить данную проблему разработчики стали придумывать утилиты вокруг командной оболочки для своих языков и рантаймов: nvm для Node.js, rvm и rbenv для Ruby и т. д. Если вы работаете с несколькими языками одновременно, то тащить для каждого из них свою утилиту, да еще и добавлять в shell ее скрипты, не всегда удобно и эффективно. Чтобы этого не делать, можно воспользоваться менеджером версий asdf.

asdf имеет хорошую документацию, совместим со всеми популярными командными оболочками и расширяем при помощи системы плагинов.

Python и JDK устанавливаются следующим образом:


# Python
$ asdf plugin add python
$ asdf install python 3.9.4
$ asdf global python 3.9.4

# JDK
$ asdf plugin add java
$ asdf list-all java | grep "openjdk-11"
$ asdf install java openjdk-11
$ asdf global java openjdk-11
$ java --version

Через плагин для Java можно также конфигурировать переменную окружения $JAVA_HOME.

 400   6 мес   asdf   cli

От задачи к релизу

В предыдущем посте я описал как выглядит Jira Workflow и пайплайн задач в кросс-функциональной команде разработки. В этой заметке, которая писалась как шпаргалка для внутреннего использования, вы найдете более полное описание процесса от момента постановки задачи до ее релиза для конечного пользователя. А еще, она точно не понравится адептам канонического Scrum.

Команда состоит из:

  • Владельца продукта
  • Delivery-менеджера
  • Тимлида
  • Двух бэкенд-разработчиков
  • Двух фронтенд-рабработчиков
  • QA
  • DevOps-инженера

Используются следующие инструменты:

  • Jira — таск-трекер
  • Confluence — командная Wiki
  • Slack — основной месседжер
  • Gitlab — управление репозиториями кода и CI + CD
  • Artifactory — репозиторий пакетов и Docker-образов
  • Sentry — отслеживание исключений
  • EFK — стек для сбора и обработки логов
  • Prometheus + Graphana — метрики
  • OpenShift — PaaS для cloud-native окружения

Теперь о процессе. Самое важное — у каждого шага пайплайна есть владелец, который мониторит его выполнение и проталкивает дальше по цепочке.

Требования к задаче

Каждая задача имеет как минимум:

  • Внятное короткое название
  • Развернутое описание, желательно со ссылками на спецификацию и дополнительные материалы
  • Компонент: бэкенд, фронтенд, инфраструктура
  • Исполнителя

Планирование и спринт

Задача привязана к эпику, эпик привязан к цели, цель — важная.

Владелец: product owner ⇢ delivery manager ⇢ тимлид.

Очередь работ

Общий процесс:

  • В бэклог проекта (не спринта) могут добавляться задачи в любой момент времени.
  • Product Owner определяет видение и будущие цели, которые разворачиваются в эпики (большие изменения).
  • На основе эпиков предварительно создаются спецификации.
  • Обсуждение спецификаций доступно всей команде, автор спецификации может обозначить SLA, по прошествию которого все обсуждения будут закрыты, т. е. спецификация считается готовой к реализации.
  • В конце текущего спринта (последний рабочий день) команда планирует новый спринт на основе эпиков, отдельно взятых задач и задач, которые остались невыполненными в текущем спринте (их приоритет может быть пересмотрен).
  • Владелец продукта и delivery manager определяют продуктовую цель спринта → создание спринта в Jira с указанием цели спринта на Scrum-доске.
  • В процессе планирования выполняется декомпозиция и оценка задач командой.
  • Для того, чтобы внести задачу в спринт, необходимо:
    • Понять суть задачи ⇠ выяснить непонятные моменты, поговорить с коллегами, дополнить описание и документацию
    • Проставить приоритет
    • Добавить оценку в сторипойнтах (числа Фибоначчи)
    • Выбрать спринт, сменить статус с Backlog на Todo, иначе она не будет отображена на Scrum-доске
    • Delivery manager стартует новый спринт в понедельник в 12:00

😲 Нужно сделать

Владелец:

  • на этапе формирования: delivery manager ⇢ тимлид ⇢ члены команды
  • на этапе спринта: QA ⇢ delivery manager / тимлид ⇢ члены команды

Данная колонка содержит бэклог спринта и формируется на основе предварительного планирования и декомпозиции. После старта спринта в нее могут добавляться только задачи высокого приоритета, например, неотложные баги.

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

Крайне желательно избегать внеплановое пополнение спринта задачами на разработку новой функциональности. Такая ситуация может возникать в рамках плохого планирования и оценки. Под этим также понимается взаимодействие компонент проекта, например, бэкенда (API) и представления (фронтенд).

На данном этапе QA уже может начинать работу над тест-кейсами.

Совет: настроенные фильтрами позволяют увидеть статус по каждому члену команды.

💪🏻 В работе

Владелец: исполнитель задачи.

Задача, над которой в данный момент работает исполнитель, имеет соответствующий статус. В работе у исполнителя может быть одновременно не более двух задач. Идеальная ситуация — фокус на одной задаче.

Если задача заблокирована какими-то внешними факторами, то она должна быть возвращена в колонку «😲 Нужно сделать» с указанием причины в комментариях. При возникновении внутренних факторов, следует указать на них на ежедневном стендапе или в командном чате.

📝 Ревью

Владелец: ревьювер.

Исполнитель задачи после ее выполнения оформляет merge request в Gitlab согласно заданному шаблону, убеждается в том, что на CI выполнены успешно все шаги сборки и назначает подходящего по его (ее) мнению ревьювера. Задача переходит в статус «📝 Ревью» и остается в нем до тех пор, пока автор не внесет правки согласно комментариям ревьювера и изменения не будут одобрены для тестирования. Достаточно одного одобрения 👍🏻

SLA на ревью:

  • блокер: 1 час — автор изменений связывается лично с ревьювером в общем чате
  • высокий приоритет: 3 часа
  • нормальный приоритет: 1 день

На ревью должно накапливаться не более трех открытых MR.

Аналогичный процесс может быть не только для технических задач, но и, например, для спецификаций и документации.

После получения одобрения изменений ветка сливается с мастером (squash commits, fast forward merge) и MR автоматически закрывается. Задача в Jira переходит в статус «К тестированию», на нее назначается дежурный разработчик.

Совет: при создании MR Gitlab автоматически берет в качестве заголовка заголовок первого коммита. Поэтому старайтесь писать понятные и короткие сообщения коммитов. В большинстве ситуаций за сообщение коммита можно взять название задачи из тикета Jira.

🎩 Дежурные разработчики

Меняются каждую неделю как со стороны бэкенда, так и со стороны фронтенда.

Задачи:

  • следить за SLA ревью
  • следить за событиями в Sentry, приоритизировать их с командой и при необходимости заводить задачи в Jira
  • собирать и разворачивать сборки для тестирования или по запросу членов команды
  • уведомлять о релизах в канале
  • переводить задачи на QA
  • собирать и разворачивать сборки для продакшен-окружения

При планировании спринта стоит учитывать нагрузку на дежурных разработчиков с учетом их дополнительных активностей в течение дежурной недели.

🟡 Разворачивание на тестовом окружении

Владелец: разработчик, вмерживающий ветку в master.

После прохождения ревью изменения попадают в мастер-ветку. Мастер-ветка всегда должна быть готова к развертыванию как минимум на тестовое окружение.

Сборка и деплой на staging-окружение выполняется автоматически в рамках CI/CD при мерже в master.

Следует также учитывать fullstack-задачи, в случае которых бэкенд и фронтенд должны быть доставлены единовременно. В такой ситуации дежурные разработчики совместно обдумывают и выполняют план одновременного разворачивания приложений.

Релиз в Jira

  1. Создать новый релиз с тэгом, соответствующим Docker-образу (префикс компонента не требуется)
  1. Проставить релиз в поле «Исправить в версиях:» всех развернутых задач
  1. Скопировать информацию о релизе из Jira и отправить в канал #releases: в списке релизов кликнуть на версию → на странице релиза нажать ссылку «Описание релиза» → скопировать описание:
  1. Отправить скопированные release notes в канал.

После разворачивания новых изменений и информирования о релизе в канале #releases задачи в Jira назначаются на QA.

🔅 К тестированию

Владелец: QA.

Перед стартом тестирования QA проверяет:

  • Наличие всей необходимой информации по задаче — от описания до документации от разработчиков. Также полезно посмотреть на merge request в Gitlab и % покрытия тестами.
  • Развернута ли задача на тестовом окружении, см. канал #releases

🐹 Тестирование

Владелец: QA.

Тест-кейсы создаются в отдельной системе.

Все найденные дефекты указываются в комментариях к оригинальной задаче. Проблема должна быть внятно описана, указано окружение (ОС, браузер, разрешение экрана и пр.), при необходимости добавлены скриншоты.

Если недочеты мелкие и не влияют напрямую на реализованную функциональность, то они могут быть вынесены в отдельные задачи в будущих спринтах с сохранением ссылки на оригинальную задачу.

  1. Успешно протестирования задача получает статус «Готово к релизу».
  2. Задача, по которой найдены дефекты, получает статус «Нужно сделать», и итерация начинается с начала

В обоих случаях задача назначается на исполнителя, который над ней работал. Тестирование на этом заканчивается.

🚢 Готово к релизу

Владелец: дежурные разработчики.

Как и в случае с тестовым окружением, релиз может быть выполнен в любое время как только для него будет сформирован список из минимум 3-4х задач.

🟢 Релиз

Владелец: дежурные разработчики.

Не блокирующие друг-друга фронтенд и бэкенд могут развертываться независимо.

Развертывание релиза в prod осуществляется в рамках CI/CD, но, в отличии от развертывания на staging, только по ручной запуску соответствующего job’а в pipeline Gitlab.

После сборки и успешного деплоя:

  1. статусы задач меняются на «Выполнено»
  2. релиз в Jira выпускается: список релизов → ... (действия) → выпустить (желательно указать дату релиза)
  3. копируются release notes (см. выше)
  4. создается уведомление о релизе в канале #releases со списком доставленных для конечного пользователя задач
  5. привлекается QA (при желании и команда) для базового тестирования самой критичной с точки зрения конечного пользователя функциональности:
    1. Успешная аутентификация в портальной части / CMS
    2. Свой профиль
    3. На главной отображается список всех новостей
    4. Доступно главное меню
    5. ...

Найденные на этом этапе дефекты заводятся новыми задачами.

В случае серьезного сбоя после развертывания изменений есть возможность откатиться на предыдущий тэг Docker-образа. Однако, для бэкенда необходимо поддерживать downgrade-миграции схемы данных.

🔥 Hotfixes

Если после выкатки релиза на прод обнаруживается наличие какого-то бага, который необходимо срочно поправить, то необходимо выполнить fix в коде, смержить его в master и тегнуть как v.0.59.1 , где .1 — номер фикса. После того, как pipeline выполнит сборку образов запустить job’ы раскатки этого фикса на prod’e. Оформлять новый релиз при этом не нужно.

Обратите внимание, что выполнить сборку фикса для prod можно не только из ветки master, но и ветки hotfix’a, не дожидаясь код-ревью. Для этого необходимо также как и описано выше назначить тег нужному коммиту в ветке hotfix’a.

🍾 Выполнено

Владелец: дежурные разработчики.

Развернутые на продакшен-окружении задачи. На этом цикл разработки заканчивается.

🆘 Управление рисками

Владелец: исполнитель.

Советы:

  • Всегда следите за ситуацией.
  • Если кажется что что-то идет не так, копните глубже и подумайте, как это можно сгладить — предлагайте варианты команде / менеджеру.
  • Все должны понимать все части проекта на высоком уровне — от сайта до влияния на бизнес.
  • Документирование стека, подходов, узких мест обязательно.
  • Когда работаете над новой задачей и делаете ее оценку, сначала сделайте небольшое исследование, проясните непонятные моменты и выставьте оценку с учетом рисков.
  • Честно подсвечивайте риски по мере их возникновения — это самое лучшее время. Второе лучшее время — это сейчас, а не позже.
 3800   8 мес   Менеджмент

Jira Workflow

Я стараюсь придерживаться принципа KISS (keep it stupid, keep it simple) не только при написании кода, но при выстраивании процессов внутри команд. Так, например, приведенный Jira Workflow имеет максимально прозрачный пайплайн выполнения задач.

Типы запросов

  • Задача — задача, которую необходимо выполнить.
  • Подзадача — задача меньшего объема в рамках задачи.
  • Баг — проблема, которая влияет на функциональность сервиса.
  • Общая задача — активности, связанные с выяснением функциональных требований будущей спецификации. Может выступать в роли спайка / исследовательской деятельности.
  • User Story — новая функциональность продукта с точки зрения пользователя. В нашей команде выполняет функцию эпика из-за специфики настройки корпоративной Jira.
  • Инцидент — системный сбой или инцидент. Для Remedy.

Приоритеты

  • Блокер
  • Высокий
  • Нормальный
  • Низкий

Статусы задач

  • 📥 Бэклог
  • 😲 To Do — бэклог спринта
  • 💪🏻 В работе
  • 📝 Ревью
  • 🔅 К тестированию ← только после выполнения автоматических тестов на CI и тестирования исполнителем
  • 🐹 Тестирование ← QA берет в работу
  • 🚢 Готово к релизу ← для планирования релиза и его деплоя на продакшен-окружение
  • ✅ Выполнено

Workflow

Задача и баг

Workflow задачи и бага

Общая задача

Workflow общей задачи

На основе перечисленных статусов задач команда может создавать Kanban и Scrum-доски для удобной визуализации пайплайна.

 614   8 мес   Jira   Менеджмент

Внутренняя Wiki команды

Первое что я делаю когда прихожу в новую команду — это смотрю на состояние документации в проекте / продукте и выступаю евангелистом единого места правды — внутренней Wiki. Постепенно совместно с командой привожу все в порядок, и документация начинает выглядеть как на скриншоте.

Внутренняя Wiki команды

Когда всех начали переводить на удаленку, мои команды уже были готовы к такому формату в том числе из-за отсутствия белых пятен в знаниях. И не раз на ретроспективах было сказано друг другу «Спасибо» за туториалы, продуктовые спецификации или описание почему когда-то было принято то или иное решение.

Не экономьте на документации. Да, в Agile-манифесте написано «Работающий продукт важнее исчерпывающей документации», но это не значит, что на нее не нужно выделять время команды.

Срыв дедлайна — в 99% случаев вина менеджмента, а не команды разработки

В своем маленьком Телеграм-канале я делал опрос на тему «Срыв дедлайна — в 99% случаев вина менеджмента, а не членов команды разработки?». Проголосовали 15 человек — почти половина канала:

  • За ответ «Нет» 7% — один человек
  • За ответ «Да» 20% — три человека включая меня
  • За ответ «Все не так однозначно» 73% — одиннадцать человек

Итак, почему я считаю, что почти всегда срыв дедлайна — вина и ошибки менеджмента.

Давайте представим среднестатистическую кросс-функциональную команду разработки: продакт или деливери менеджер, бэкенд, фронтенд, DevOps, QA. И новый проект, фичу или какие-то серьезные изменения в продукте.

У бизнеса (под бизнесом в нашем примере я понимаю либо топ-менеджмент компании, который отвечает за стратегию, либо владельца продукта, который отвечает за результат перед топ-менеджментом) есть некая цель заработать денег или завоевать определенную долю пользователей или рынка, а лучше и то, и другое в некоторой временной перспективе. Таким образом, бизнес ставит задачу команде, а команда коммитится на результат.

Первая ошибка менеджмента возникает уже на этапе договоренностей с бизнесом. Как правило, менеджер продукта обсуждая с бизнесом результат, ставит перед собой и командой дедлайн. Бизнес, конечно же, ничего не знает про команду, ее состав, опыт, сработанность и др. факторы и просто ожидает некую временную отсечку, после которой можно смотреть на достижение поставленных целей и дальнейшее изменение стратегии. Если менеджеры договорились между собой о дедлайне, не вовлекая в процесс оценки команду и не заложив дополнительное время на непредвиденные обстоятельства, то практически всегда мы в итоге получаем срыв этого самого дедлайна: скоуп задач оказался слишком большим, затянулись этапы подготовки (анализ, описание требований и спецификаций, инфраструктуры и др. операционные вопросы), команда посмотрев требования высказала свою точку зрения, оценки менеджера и команды разошлись и т. п.

Ок, даже если так случилось, и менеджер вдруг понял, что команда не вложится в оговоренные сроки, то вырулить все еще можно порезав скоуп задач и цели, а затем пойти передоговариваться с бизнесом (в счет не берем ситуации сделай или умри, когда бизнес запускается под какой-то ивент). И на этом этапе решает умение управлять ожиданиями заказчика и стекхолдеров. Если менеджер этого не делает, то с большей вероятностью, исходная ситуация будет усугубляться при приближении даты дедлайна: менеджер и команда будут пытаться вкидывать больше ресурсов, принимать рискованные решения. За счет этого увеличиться уровень стресса и напряжения внутри команды. Здесь мы видим вторую ошибку менеджмента, которая может оказаться фатальной для всех — бизнеса, который пребывал в неведении и ждал результатов от команды; команды, которая в поте лица пыталась все же выполнить срок и выгорела; менеджера, который показал, что не в силах спланировать разработку, управлять ожиданиями и рисками.

Вот и получается, что на 1% срывов всех дедлайнов остаются внешние факторы, которые случились либо перед самым запуском: например, ваш провайдер инфраструктуры внезапно упал из-за урагана, либо кто-то из команды заболел (но и в этой ситуации вы, как менеджер, тоже просчитались — допустили bus factor на проекте), либо вы совместно с бизнесом поняли, что не стоит выпускать на рынок сырой продукт, и репутация компании стоит дороже тех изменений, которые вы планировали показать конечным пользователям.

 54   8 мес   Менеджмент
Ранее Ctrl + ↓