Сон — это мегаважно. Не только его количество, но и качество. Если по количеству, все плюс-минус понятно — спи себе минимум 8 часов, то на качество влияет довольно много факторов. Один из них — ваша подушка и положение во сне.

Общие советы:

• Простая пухо-перьевая подушка, не сентипоновая
• Размер 50x70, т. е. не квадратная
• Наволочка не должна стискивать подушку
• Для ребенка подушка должна быть мягкой и тонкой — больше пуха или всего 30% пера
• Спать на спине или на боку, не на животе, чтобы не выкручивать шею
• Лежа на боку плечо не должно лежать на подушке — подушка под шеей (как валик), рука на плече
• Лежа на спине, подушка должна образовывать валик в области шеи
• Ортопедическая подушка пригодна только для сна на боку
• Подушка должна проветриваться/сохнуть, а не лежать постоянно накрытой

Один из способов подключить к Keycloak провайдер существующих пользователей — механизм, который называется User Federation. Он позволяет используя Kerberos или LDAP синхронизировать учетные записи из корпоративного хранилища. Если пользователей в хранилище много, и оргструктура организации предполагает вложенность, то это может усложнить получение подмножества учетных записей.

Так, например, в Active Directory используются следующие сущности:

• CN = Common Name
• OU = Organizational Unit
• DC = Domain Component

Документация по LDAP с расшифровкой аббревиатур есть на сайте Microsoft.

В настройках LDAP провайдера необходимо указать User DN. Самый простой вариант — когда все учетные записи разложены по организационным единицам:

OU=Main,DC=Orgname,DC=ru

В этом случае Keycloak с легкостью найдет все учетные записи в юните, даже если внутри него есть какая-то вложенная структура. Для этого, правда, придется включить дополнительный параметр Search Scope: Subtree.

Но что делать если администраторы AD вместо создания OU сущностей добавляют нужных вам пользователей в CN? Другого способа, как дополнить описанное выше решение дополнительным фильтром для LDAP, я не нашел. В настройке Custom User LDAP Filter можно прописать все CN группы через оператор или |:

(&(objectCategory=Person)(sAMAccountName=*)(|(memberOf=CN=CMS_EDITOR,OU=Security,OU=Groups,OU=Central,OU=Main,DC=Orgname,DC=ru)))

В примеры указана только одна группа CMS_EDITOR.

В нескольких рабочих проектах я использую в качестве сервиса аутентификации Keycloak. Проект спонсируется компанией RedHat, активно развивается и адаптирован для cloud-native окружения. Хотя документация у Keycloak достаточная для основных пользовательских сценариев, иногда ее не хватает для решения специфичных вопросов. Последнее с чем я столкнулся — подключение Active Directory как User Federation через протокол LDAPS (LDAP over SSL).

Как и полагается внутренним корпоративным сервисам, наш сервер LDAPS предоставляет самоподписанный сертификат. Keycloak в этом случае для успешного соединения с ldaps://ldap.orgname.com:636 требует, чтобы сертификат находился в truststore. Вариантов конфигурирования несколько:

1. глобальный cacerts ОС, в которой запускается сервис
2. cacerts из каталога установленного JDK
3. системное свойство javax.net.ssl.trustStore для JVM
4. truststore в каталоге Keycloak

Если вам необходимо просто добавить самоподписанный сертификат или root.crt, то самым простым способом будет добавление его в источники на уровне ОС и обновление списка доверенных сертификатов. Тогда вам не придется каждый раз искать где находиться JDK в системе, переписывать startup-скрипты сервиса или заботиться о безопасной работе с паролями для своего truststore.

Для разворачивания в Kubernetes или OpenShift можно собрать образ следующим способом:

FROM jboss/keycloak:13.0.0

USER root

ARG CERT="root.crt"

COPY $CERT /etc/pki/ca-trust/source/anchors/
RUN update-ca-trust

USER 1000

Убедиться, что сертификат был добавлен в список доверенных:

$ cd /etc/pki/ca-trust/extracted/java
$ keytool -list -keystore cacerts

Your keystore contains 137 entries. В оригинальном образе их 136.

Для установки пакетов на 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.

В предыдущем посте я описал как выглядит 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-образу (префикс компонента не требуется)

2. Проставить релиз в поле «Исправить в версиях:» всех развернутых задач

3. Скопировать информацию о релизе из Jira и отправить в канал #releases: в списке релизов кликнуть на версию → на странице релиза нажать ссылку «Описание релиза» → скопировать описание:

4. Отправить скопированные 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.

🍾 Выполнено

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

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

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

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

Советы:

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