Как из безголовой CMS сделать полноценную систему управления сайтом: https://habr.com/ru/companies/agima/articles/821115/

На Хабре вышел разбор безголовых CMS от нашего руководителя направления Frontend Леши Кузьмина. Он выступал с этой темой на CodeFest, а сейчас написал статью.

В ней Леша объясняет:

- как быть с архитектурой проектов, интеграциями и динамическими страницами;
- какие подходы удобнее не только для разработчиков, но и для контент-менеджеров;
- как работает динамическая сборка в NuxtJS и NextJS.

Получилась подробная инструкция по работе с Headless CMS с кучей скриншотов и кода. Так что сохраняйте и делитесь с коллегами — будет полезно junior-специалистам и middle+

Статья уже в нашем блоге по ссылке выше.

Junior-специалист за 4 месяца: как мы ищем, обучаем и выпускаем стажеров на реальные проекты: https://habr.com/ru/companies/agima/articles/828454/

Недавно съездил на TeamLead Conf в Питер и рассказал там, как устроена программа стажировок в AGIMA. А теперь написал про это статью.

Будет полезно тимлидам, руководителям, HR-специалистам и всем, кто хочет запустить или оптимизировать программу стажировок в своей компании.

Вы узнаете:

- где искать стажеров, помимо HH.ru, и на что обращать внимание на собеседовании;
- из чего состоит наша программа обучения;
- кто и как учит стажеров, и сколько на это нужно часов;
- как мотивировать стажера и интегрировать его в команду.

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

Материал уже на Хабре по ссылке выше. Делитесь своим опытом по этой теме и задавайте вопросы в комментариях.

Как выжить на стажировке в IT — рассказывают Junior-разработчики и их менторы: https://habr.com/ru/companies/agima/articles/831466/

Вчерашние стажеры, а сейчас уже крепкие джуны фронтенд-отдела Катя Пушкарева и Рома Фетисов рассказывают, как выжить на стажировке и не сбежать из IT на второй день. В статье на Хабре их личный опыт, советы и предостережения для новичков:

- на что стоит обратить внимание гуманитарию в IT;
- какие барьеры поможет преодолеть стажировка;
- необходимый минимум навыков для стажера;
- где и как эффективнее искать вакансии;
- стоит ли отдавать стажировке всё свободное время.

Большой бонус в конце — FAQ от менторов направления Frontend Леши Кузьмина и Леши Песоцкого. Их ответы на самые наболевшие вопросы про стажировки помогут избежать ошибок на собесах и на обучении.

Делитесь своими стажерскими историями в комментариях к статье — она по ссылке выше.

Совместное использование API Gateway и BFF

API Gateway и BFF — популярные архитектурные паттерны применяемые для разработки внешнего API приложения построенного на микросервисной архитектуре.

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

Какие задачи будет решать каждый паттерн?

API Gateway

Маршрутизация и балансировка нагрузки: Все входящие запросы сначала проходят через API Gateway, который уже направляет их к соответствующим BFF. Необходимый BFF определяется по заголовкам или url.

Безопасность и авторизация: Gateway выполняет проверку JWT токенов, групповых политик и других мер безопасности.

Кэширование: Кэширует часто запрашиваемые общие данные, уменьшая нагрузку на микросервисы.

Логирование и мониторинг: Централизованно собирает логи и метрики всех запросов.

BFF

Реализации логики для клиента: Адаптация запросов/ответов под нужды конкретного клиентского приложения (мобильного или веб).

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

Изоляция изменений:
Позволяет быстро вносить изменения для конкретного клиента без влияния на работу других клиентов.

Какие преимущества от совместного использования?

Уменьшение дублирования функционала:
Общие функциональности, такие как маршрутизация, безопасность, кэширование и логирование, реализуются на уровне Gateway. Нет необходимости дублировать код и реализовывать одно и то же в каждом BFF.

Улучшение производительности и масштабируемости:
Кэширование на уровне Gateway снижает нагрузку на микросервисы, а BFF обеспечивает оптимизацию запросов/ответов, что улучшает производительность и масштабируемость системы.

Централизованное управление и безопасность:
API Gateway обеспечивает единые политики безопасности для всего приложения и всех клиентов, что снижает риски и уменьшает количество точек потенциального отказа.

Итоговый поток запросов в системе

1. Клиентское приложение (веб или мобильное) отправляет запрос.
2. Запрос проходит через API Gateway, где проверяются токены безопасности и применяются политики доступа.
3. Gateway маршрутизирует запрос к соответствующему BFF.
4. BFF обрабатывает запрос, взаимодействует с микросервисами, агрегирует данные и возвращает ответ в формате, оптимизированном для конкретного клиента.
5. Ответ возвращается клиентскому приложению через API Gateway.

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

Например вы разработали систему для покупки билета на самолёт. Предположим у вас 3 сервиса: Оплата, Уведомление, Бронирование. Сервис успешно списал деньги, выслал уведомление о покупке, но возникла ошибка на этапе бронирования. Как вернуть всё в исходное состояние когда у нас 3 независимых сервиса? В монолитном приложении нас бы спасли транзакции ACID. А в случае с микросерисами - Саги.

Основная идея шаблона "Сага"

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

Принципы работы саги

1️⃣ Разбиение на шаги: Сага состоит из нескольких шагов (транзакций), каждый из которых выполняется в рамках одного микросервиса. В процессе покупки билета на самолёт, это могут быть шаги: списание средств, уведомление о списании, проверка доступности рейса и его бронирование.

2️⃣ Компенсирующие транзакции: Для каждого шага определяется компенсирующая транзакция, которая откатывает изменения в случае ошибки. Например, если возникла ошибка на этапе бронирования, то нужно его отменить и запустить компенсирующие транзакции для предыдущих шагов.

3️⃣ Асинхронное выполнение: Шаги в саге могут выполняться асинхронно. После успешного выполнения одного шага инициируется следующий. Если какой-либо шаг не удался, запускаются компенсирующие транзакции. Компенсирующее действие для этапа оплаты - вернуть средства. Для этапа уведомления - отправить новое уведомление с информацией, что бронирование не удалось.

Стратегии реализации саги

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

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

Как включение JIT в PHP 8 ускоряет парсинг CSV-файла

С выходом PHP 8 появилась одна из самых мощных функций — JIT компиляция. Эта технология позволяет значительно ускорить выполнение PHP-скриптов, компилируя код в машинные инструкции на лету. Одной из задач, где JIT может проявить себя особенно эффективно, является парсинг больших CSV-файлов.

Рассмотрим классическую задачу: у вас есть объёмный файл и вам нужно его обработать — например, просуммировать все транзакции выше определенной суммы.

Типичный код для решения этой задачи:

$file = fopen('large_file.csv', 'r');
$totalSum = 0;

if ($file !== false) {
    fgetcsv($file);
    
    while (($row = fgetcsv($file)) !== false) {
        $amount = (float)$row[2];
        if ($amount > 1000) {
            $totalSum += $amount;
        }
    }
    fclose($file);
}

echo "Total sum of large payments: " . $totalSum . "\n";

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

Интерпретатор PHP читает исходный код построчно и создаёт набор инструкций opcode. Opcode это не машинный код, а только набор инструкций для виртуальной машины Zend Engine. Затем виртуальная машина исполняет каждую инструкцию opcode последовательно, вызывая в режиме реального времени соответствующие операции на уровне системы.

При этом, когда интерпретатор Zend встречает в opcode цикл, он каждую итерацию заново интерпретирует и исполняет инструкции opcode.

Это и есть нашей с вами платой за использование интерпретируемых языков программирования 🙂

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

Как JIT Ускоряет работу циклов

JIT позволяет сократить значительное количество интерпретаций opcode виртуальной машиной, за счёт компиляции opcode в машинный код, который выполняется напрямую на процессоре. Скомпилированный машинный код сохраняется и уже многократно используется в итерациях цикла, без необходимости повторной интерпретации.

Как это отразится на нашей задаче обработке файла?

1. Ускорение циклов: Основное время тратится на выполнение цикла, где каждая строка файла разбирается и обрабатывается. С JIT этот цикл будет выполняться быстрее за счет компиляции его тела в машинный код.

2. Эффективность работы со строками: Функции, такие как fgetcsv, которые активно работают со строками и массивами, получают прирост в производительности благодаря JIT, за счет того что её не нужно интерпретировать на каждой итерации. Это особенно заметно, если в строке много столбцов или данные требуют интенсивной обработки.

3. Уменьшение накладных расходов: Каждый вызов функции в PHP сопровождается определенными накладными расходами. JIT минимизирует эти расходы, поскольку часть функций может быть оптимизирована и выполнена быстрее на уровне машинного кода.

Настройка и включение JIT

Добавим в конфигурацию PHP:

opcache.enable=1
opcache.enable_cli=1
opcache.jit_buffer_size=100M
opcache.jit=1255

Сравнение производительности: С JIT и Без JIT

Проведем небольшой эксперимент. Подготовим CSV-файл с 10 миллионами строк. Мы запускаем вышеуказанный скрипт — с включенным JIT и без него.

Без JIT: Среднее время выполнения 120 секунд.
С JIT: Средне время выполнения 80 секунд.

Получается, что включение JIT позволило сократить время на парсинг файла на ~33%.

Вопрос читателям: Использовали ли вы JIT для ускорения обработки данных в PHP? Какие результаты вы получили? Поделитесь своим опытом в комментариях!

ИИ-система по извлечению информации со сканов счетов: https://habr.com/ru/companies/agima/articles/849722/

Для автоматизации бизнес-процессов часто требуется обработка бумажных документов со сложной структурой — например, счетов, чеков или накладных.

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

Ребята из AGIMA AI в нашем блоге на Хабре рассказывают, как автоматизировали этот процесс с помощью ИИ и какие сервисы использовали.

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

Как развивать лидеров внутри IT-команды и команды и где искать сильных управленцев: https://clck.ru/3E2mGg.

Осенний сезон полезных митапов продолжается. На этот раз соберемся в нашем офисе 1 ноября и обсудим, как прокачать лидерские качества в вашей команде.

Главные темы митапа:

- как вырастить лидера внутри IT-команды и чем его мотивировать;
- в каких случаях лучше использовать аутстафф;
- как избежать выгорания у руководителей;
- какие стратегии помогут сделать управленческие решения более системными и человечными.

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

Но мы не ограничимся только теорией, а попробуем сразу применить все инсайты на практике. Для этого устроим круглый стол с экспертами из X5, Альфа-Банка, Лемана Про, AGIMA и др., а затем закрепим знания на воркшопе с Алексеем Кельиным, исследователем и бизнес-тренером.

Также обещаем приятную атмосферу, вкусную еду, напитки и много нетворкинга. Подробности и обязательная регистрация — по ссылке выше.

Ждем СТО, руководителей IT-департаментов, IT-рекрутеров, IT-лидов и CPO — всех, кто отвечает за управление и развитие команд в IT.

Когда: 1 ноября, 17:30.
Где: оффлайн, Петровка, 19/4, офис AGIMA.
Регистрация: https://clck.ru/3E2mGg

Почему мы охотно нанимаем джунов и почему советуем всем делать то же самое: https://habr.com/ru/companies/agima/articles/856526/

К специалистам уровня Junior на рынке относятся с опаской — их редко и неохотно берут на работу. Однако у нас иной опыт: мы как раз не боимся учить начинающих разработчиков.

Наш тимлид Артем Валевич рассказывает на Хабре, почему джуниор — это не очередная головная боль для команды, а выгодная инвестиция в будущее. Главное — не бояться.

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

Платим 50 000 рублей всем, кто посоветует хорошего Golang-разработчика в нашу команду. Важно, чтобы у специалиста был опыт работы от четырех лет и уровень английского языка B1+ и выше для общения в международной команде.

Что нужно делать:

✔️разрабатывать и оптимизировать микросервисы на Golang;
✔️работать с высоконагруженными системами и масштабируемыми решениями.

Что предлагаем:

✔️Формат работы: офис, удаленка, гибрид.
✔️Оформление: штат, ГПХ.
✔️График работы: 5/2.
✔️ДМС со стоматологией.
✔️Возможности для профессионального роста — в любом количестве.
✔️Масштабные проекты и здоровая рабочая атмосфера.

Подробнее о вакансии — на нашем сайте [тык].

Мы выплатим бонус, когда рекомендованный специалист пройдет испытательный срок в нашей команде — обычно это 3 месяца после первого рабочего дня.

Присылайте резюме подходящих кандидатов на hr@agima.ru или мне в лс @WizAlx. Спасибо!

У нас суперновость. Билеты на RUNIT 2025 уже в продаже: https://runit.digital

До Нового года осталось всего ничего, а значит, пора строить планы на 2025-й. Поэтому мы решили уже сейчас открыть регистрацию на следующий фестиваль IT и спорта RUNIT.

Пока выбираем оптимальную площадку и дату, но точно можем сказать: всё пройдет летом. И мы 100% учтем расписание крупных IT-конференций, чтобы вы могли везде успеть.

Что будет по-новому:

- теперь регистрируемся сразу в RussiaRunning — так вы сможете сами управлять регистрацией через личный кабинет;

- заявки от компаний и команд ждем на почте runit@agima.ru — для каждого участника тоже создадим личный кабинет;

- заказать гравировку на медали также можно заранее — такая опция на сайте RUNIT уже доступна при покупке билета.

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

Так что готовим телегу зимой и планируем лето. Следить за новостями можно в телеграм-канале RUNIT.

Какими бывают лидеры в IT и почему они тоже выгорают: https://clck.ru/3FSULp.

Недавно на митапе про управленцев в IT мы вместе с бизнес-тренером Алексеем Кельиным разбирали его исследование об органичном лидерстве. Оно, по сути, отвечает на вопрос: «Как руководителю найти органичный подход к лидерству, чтобы не выгорать и уберечь от этого своих сотрудников».

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

Статья точно будет полезна СТО, руководителям IT-департаментов, руководителям IT-рекрутмента, IT-лидам и CPO — всем, кто отвечает за управление и развитие команд в IT.

Читайте текст на Хабре по ссылке выше и делитесь им с коллегами.

Нанять нельзя вырастить: стоит ли прибегать к аутстаффингу, чтобы найти лидера для IT-команды? https://clck.ru/3FiaCS

Инвестировать время и ресурсы в выращивание лидеров внутри команды или оперативно найти готового специалиста через аутстаффинг? Секрет в том, что и тем и другим подходом можно умело пользоваться, если знать как.

Руководитель Outstaff-направления AGIMA Константин Мовчан поделился с редакцией «Бизнес-секретов» критериями успеха для обеих стратегий найма.

Статья получилась интересной: в ней и реальные кейсы, и большая сравнительная таблица с плюсами и минусами, и много практических советов.

Читайте материал по ссылке выше и делитесь своим мнением в комментариях!

Глава Sonos ушел в отставку после провального запуска приложения

Генеральный директор Sonos Патрик Спенс, который руководил компанией более десяти лет, объявил о своей отставке. Причиной стало катастрофическое обновление мобильного приложения, которое привело к огромным финансовым потерям и утрате доверия клиентов.

Под руководством Спенса Sonos выросла из небольшой компании в многомиллиардного производителя беспроводных наушников и колонок. Однако несколько месяцев назад всё пошло не так: выпуск полностью переработанного приложения на Flutter в «сыром» состоянии обернулся провалом.

Что пошло не так?

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

Спенс попытался спасти ситуацию и выпустил видео с извинениями. Но этого оказалось недостаточно. Он покинул пост с выходным пособием в $1,8 млн, что считается скромной суммой для CEO, который построил компанию с миллиардной капитализацией.

Технические причины провала

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

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

Разработчики не смогли (или не успели) должным образом протестировать и стабилизировать все новые функции, что привело к многочисленным проблемам со связью. Итого неготовность продукта к релизу и давление со стороны руководства сыграли роковую роль.

Что дальше?

Новый CEO уже уволил руководителя продукта, а компания пытается восстановить доверие клиентов. Однако этот случай стал ярким примером того, как спешка и игнорирование предупреждений инженеров могут привести к катастрофе.

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

Как обновить Битрикс методом миграций

Что потребуется прежде всего:

✅ Убрать ядро (папка /bitrix/) под гит, например, завернуть в сабмодуль.
✅ Отдельная тестовая площадка с отдельной и актуальной БД.
✅ Скрипт для очистки лога запросов в БД (архив прикреплен).

Дальше идем по процессу:

1. Переходим на тестовую площадку.
2. Включаем режим отладки БД:

//bitrix/php_interface/dbconn.php
 
$DBDebugToFile = true;

3. Заходим на страницу обновления платформы и запускаем обновления: /bitrix/admin/update_system.php?lang=ru.
4. Очищаем лог-файл от лишнего с помощью скрипта.
5. Готовим миграцию.
6. Пушим всё в гит.
7. Выкатываем на прод изменения и запускаем миграцию.

Как подготовить миграцию

Файл mysql_debug.sql с логом изменений в БД довольно большого размера >50Mb. В нем есть и запросы, и время их выполнения, и stacktrace — в общем, много лишнего. Скрипт всё это вычищает и оставляет только запросы: в итоге вместо ~100Mb мы можем получить, например, ~300Kb.

Но скрипт неидеален и пока еще не очень умен. Поэтому финальный файл нужно провалидировать вручную — в лог могут попасть запросы отправки почтового события или еще что-нибудь лишнее.

📌Как работать со скриптом описано в файле readme в прикрепленном архиве.

Дальше берем очищенный файл и начинаем миграцию. Для этого отлично подойдет модуль sprint.migration:

🔹 Если запросов достаточно много (особенно, если вы обновляете несколько мажорных версий за раз), то хорошо бы разбить файл на чанки — по 50 запросов в 1 чанке.

🔹 Делаем миграцию с рестартами и оборачиваем запросы в транзакции. Обязательно добавьте логирование, чтобы потом можно было поработать с ошибками.

Финальный шаг

Когда вы всё обновили, зафиксили, подготовили миграцию и запушили в гит, проверьте всё еще раз. Тут рекомендуем проверить работу миграции на чистой площадке с БД до обновления. Если всё ок, то можете планировать обновление stage/prod окружений.

И помните: у самурая нет цели, только путь! 😉

Фон — это не просто бэкграунд, а важная часть дизайна, которая задает стиль и влияет на восприятие сайта. Делимся классной подборкой эффектов для фона на CSS — целых 40 вариантов: https://prismic.io/blog/css-background-effects.

В подборке куча категорий:

- кастомные фоны на CSS;
- градиенты;
- эффекты скролла;
- узоры и текстуры;
- SVG-эффекты;
- и другие крутые решения.

Еще отдельно выделены генераторы и разные библиотеки.

Можно взять готовый эффект или вдохновиться идеями для своих проектов. В общем, загляните!

Ссылочка: [тык]

Семь ключевых ошибок тимлида (и как их не допускать): https://habr.com/ru/companies/agima/articles/884270/

Все тимлиды на заре карьеры встают на одни и те же грабли: кто-то начинает делать задачи вместо команды, кто-то ставит ТЗ как попало, а кто-то напрочь игнорирует техдолг.

Чтобы не допускать подобных ошибок, тимлид нашего отдела PHP Артем Валевич составил для себя что-то вроде кодекса, в котором перечислил самые вредные установки руководителя.

Всего получилось семь пунктов — простых, но в то же время важных. Разбираем и обсуждаем их на Хабре. Приходите почитать и поделиться опытом в комментариях.

💧NiFi Registry а-ля Git

Если вы работаете с Apache NiFi, то, скорее всего, сталкивались с проблемой контроля версий потоков данных. Здесь на помощь приходит NiFi Registry — инструмент для хранения, восстановления и управления версиями потоков. А с недавних пор появился способ контроля версий через Git. Давайте разберемся, как с ним работать и какие альтернативы есть у разработчиков.

Настройка родного реестра NiFi Registry

Для хранения версий потоков используется отдельный сервис реестра. Устанавливаем его рядом с NiFi, например, в контейнере (можно найти на просторах DockerHub с инструкцией установки и параметрами), открываем его Web UI по адресу http://localhost:18080/nifi-registry и создаем в настройках бакет — основную единицу для хранения и управления версиями.

Далее в NiFi настраиваем клиент реестра: Controller Settings -> Registry Clients, выбираем NifiRegistryFlowRegistryClient и устанавливаем настройку URL с адресом, прописанным до Web UI реестра: http://localhost:18080/nifi-registry. Теперь можно подключать процессорные группы к реестру через Version Control, выбирая бакет и имя версии. После коммита в реестр появится JSON-файл, а в интерфейсе NiFi — зеленая галочка, подтверждающая сохранение версии. Если внести изменения, можно откатиться к предыдущей версии или продолжить разработку.

Это похоже на Git с коммитами, пулами и возможностью клонировать потоки из реестра — разница в том, что в NiFi Registry можно подтянуть конкретную группу процессоров, а не весь проект целиком.

GitLab как хранилище потоков

Альтернативный подход — хранить версии не в родном реестре, а в Git-репозитории (например, GitLab). В этом случае вместо NiFi Registry используется контроллер GitLabFlowRegistryClient. Настройки схожи: указываем URL репозитория, access token, ветку и путь к папке с бакетами.

Важно: NiFi не умеет создавать бакеты в GitLab, поэтому их нужно завести вручную — в виде папок в репозитории. JSON-файлы потоков загружаем через git commit - push. Затем можно клонировать их на рабочий холст в NiFi и использовать.


Как выглядит процесс работы:
1. Разработчик клонирует репозиторий, настраивает GitLabFlowRegistryClient.
2. Создает ветку, разрабатывает поток, экспортирует JSON в репозиторий (bucket2/flow.json).
3. Коммитит, пушит и создает merge request.
4. Ревьюеры клонируют поток, проверяют, вливают изменения в main.
5. На боевом NiFi можно подтянуть обновленный поток из мастера.

Этот же процесс работает и с GitHub.

Продвинутый вариант: родной реестр + GitLab

Можно настроить NiFi Registry для работы с GitLab. В конфиге nifi-registry.properties подключаем GitLabFlowRegistryClient, а в самом NiFi — стандартный NifiRegistryFlowRegistryClient. Тогда реестр сам разберется, где хранить и откуда забирать версии.

В итоге, у вас есть два варианта: использовать родной NiFi Registry или хранить версии в GitLab. Оба решения удобны, а выбор зависит от архитектуры проекта и команды. Какой подход вам ближе?

Незаменимых нет: про бас-фактор, или Что делать, если Вася Пупкин уйдет

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

С первого дня работы нового специалиста мы думаем не только о его задачах, но и о передаче знаний. Документация, резервные точки, дублирующие компетенции — всё это помогает избежать ситуации, когда «без Васи вообще ничего не работает».

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

Но мы реалисты и понимаем, что идеальная система возможна не всегда. Иногда человек уходит неожиданно, и тогда мы стараемся договориться о плавном переходе, чтобы он успел передать максимум знаний. Такие случаи довольно редки, но если происходят, важно не пытаться удержать человека любой ценой, а грамотно организовать передачу его компетенций. Мы ценим профессионализм и стараемся расставаться по-доброму, ведь наш рынок узкий: хороший специалист может вернуться, порекомендовать нас другим или стать нашим клиентом в будущем.

Поэтому бас-фактор — это не паранойя, а здравый смысл. Он позволяет бизнесу быть гибким, команде — уверенной в завтрашнем дне, а руководителям — спать спокойно.

А как устроено у вас? Думаете наперед или надеетесь, что ключевой человек вечно будет на своем месте?