<![CDATA[Статьи]]> https://habr.com/ru/users/dragfaq/publications/articles/ ru editor@habr.com habr.com Sat, 02 May 2026 18:48:20 GMT https://habr.com/ru/ https://habrastorage.org/webt/ym/el/wk/ymelwk3zy1gawz4nkejl_-ammtc.png Хабр <![CDATA[Монорепозитории NX и Lerna, или Туда и обратно]]> https://habr.com/ru/articles/520186/ https://habr.com/ru/articles/520186/?utm_campaign=520186&utm_source=habrahabr&utm_medium=rss

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

В скриптах деплоймента (или в моем случае еще и в настройках GitLab репозитория), нужно сформировать токены/ключи доступов к докер реджистри, кубернетесу, разным кластерам и т.д. И если у вас пару сервисов, то это не проблема, но если сервисов 15-20, то это весьма болезненный процесс. Особенно, когда настройки кластера меняются и нужно эти изменения вносить во все репозитории.

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

После того как мы перешли на монорепозиторий появилось еще несколько преимуществ, без которых, в принципе, тоже можно жить, но все равно это был приятный бонус.

И вот мы решили использовать монорепозиторий, но с чего начать и как все организовать?

Поехали!]]> Mon, 05 Oct 2020 11:50:16 GMT <![CDATA[Самодокументируемый REST сервер (Node.JS, TypeScript, Koa, Joi, Swagger)]]> https://habr.com/ru/articles/449906/ https://habr.com/ru/articles/449906/?utm_campaign=449906&utm_source=habrahabr&utm_medium=rss
Про преимущества и недостатки REST написано уже довольно много статей (и еще больше в комментариях к ним) ). И если уж так вышло, что вам предстоит разработать сервис, в котором должна быть применена именно эта архитектура, то вы обязательно столкнетесь с ее документированием. Ведь, создавая каждый метод, мы конечно же понимаем, что другие программисты будут к этим методам обращаться. Поэтому документация должна быть исчерпывающей, а главное — актуальной.

Добро пожаловать под кат, где я опишу, как мы решали эту задачу в нашей команде.
Читать дальше →]]> Thu, 02 May 2019 10:21:49 GMT <![CDATA[Автоматизация workflow небольшой команды разработки (Часть 2)]]> https://habr.com/ru/articles/270321/ https://habr.com/ru/articles/270321/?utm_campaign=270321&utm_source=habrahabr&utm_medium=rss В предыдущей публикации я описывал список продуктов и их настройки, которые необходимы для работы нашей организации.

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

На протяжении 4-х лет у нас выработался следующий формат команды разработки:
  • 1 Project Manager, он же Product Manager, он же Delivery Manager.
  • 4-5 программистов
  • 1 Team lead
  • 3-4 QA
  • 1 Аналитик
  • 1 Техпис (иногда он же и аналитик в одном лице).

В итоге команда размером около 10-11 человек. Таких команд (ячеек) у нас несколько.

Работа в основном в стиле стартапа, когда нет конкретной и подробной постановки. Очень часто эксперименты вроде “а давайте попробуем так, посмотрим что получится” или “вы классно все сделали, но теперь надо все совсем по-другому”.
За эти годы концепцию нашей работы можно описать одной фразой — это “стремительная смена концепции”.
Понятное дело, что применить в таких условиях различные методологии никак не удавалось.

Начинал в этой системе я как программист, потом Team lead, ну а теперь PM (DM). Т.е. руковожу, полностью участвую в проектировании и иногда даже пописываю. Во времена моего программирования у меня был замечательный ПМ (выходец из тестировщиков), которая поддерживала все мои идеи по автоматизации workflow. Даже более того, концептуально этот процесс придуман ей, а я уже смог его технически реализовать и в некоторых местах усовершенствовать.
Читать дальше →]]> Fri, 06 Nov 2015 12:30:16 GMT <![CDATA[Автоматизация workflow небольшой команды разработки (Часть 1)]]> https://habr.com/ru/articles/270299/ https://habr.com/ru/articles/270299/?utm_campaign=270299&utm_source=habrahabr&utm_medium=rss
Года 4 назад я морально, а затем и фактически дорос до уровня тимлида. Взгляды стали шире и выше текущих процессов. В голову стали приходить разные мысли о мотивации, оптимизации, автоматизации и прочих -циях. В этой статье я хотел бы поделиться опытом из разряда технических компетенций тимлида: как автоматизировать ежедневные процессы (например, автоматическая сборка продукта, выкладывание, документирование, управление правами т.д. и т.п.).

После третьей страницы текста моей статьи, я решил разделить ее на 2 блока:


Итак. Настройка ПО, сопровождающего процесс разработки



Читать дальше →]]> Fri, 06 Nov 2015 10:01:42 GMT