В Островке GitLab давно стал центральной точкой разработки. Со временем вокруг основного процесса накопилась ручная рутина — множество мелких действий, которые не связаны напрямую с кодом, но в сумме заметно влияют на работу.
Пока людей немного, всё обычно держится на договорённостях и внимательности отдельных участников. С ростом это начинает работать хуже: прозрачность снижается, поддерживать привычный порядок становится всё сложнее.
В ответ на это у нас появился отдельный сервис автоматизации. Он живёт рядом с GitLab и берёт на себя вспомогательные процессы: поддерживает актуальные статусы задач, помогает с ревью и дежурствами и вовремя сигнализирует о накопившихся релизах.
Об опыте, который начался с пары автоматизаций и закончился отдельным сервисом, рассказываем под катом.
Привет, Хабр! Меня зовут Алёна Тямейкина, я Python-разработчик в Островке. Сегодня расскажу историю о том, как обычные «ну потом подвину статус» и «кто-нибудь посмотрит ревью» со временем превратились в отдельный сервис автоматизации процессов разработки.
Если коротко, у нас были GitLab, задачи в трекере и команда из трёх разработчиков и тимлида. А ещё — множество мелких ручных действий вокруг разработки. Каждое из них само по себе занимает минуту, но именно такие «минуты» чаще всего откладываются и всплывают в самый неудобный момент — когда нужно быстро разобраться, где зависла фича и почему релиз снова разросся.
Триггер был максимально приземлённый. Code review периодически затягивался (и да, иногда по моей вине тоже), а тимлид всё чаще сталкивался с тем, что задачи в трекере живут отдельной жизнью. Работа уже идёт, merge request в ревью, что-то смержено — а статусы при этом не отражают реальность. Это не катастрофа, но прозрачности процессу точно не добавляет.
В какой-то момент наши интересы совпали: мне хотелось убрать рутину, тимлиду — вернуть предсказуемость. Так и началась история автоматизации.
Никаких долгих обсуждений, воркшопов и брейнштормов у нас не было. Все проблемы лежали на поверхности, так что список сложился почти сам собой:
задачи слишком долго зависали в code review;
они не всегда находились в актуальном статусе — особенно в моменты, когда работа уже шла полным ходом;
в merge request’ах часто не выставлялись лейблы, которые сильно упрощают ревью и помогают понять, что именно скрыто внутри;
регулярно возникала ситуация «много запросов к команде — нужен кто-то ответственный»;
к релизу накапливалось слишком много задач, из-за чего выкатка превращалась в отдельное приключение.
Типичные вещи, с которыми сталкиваются почти все команды по мере роста.
Почему нельзя было просто взять и автоматизировать
Конечно, существуют сторонние инструменты, которые можно купить или скопировать, настроить под себя и жить дальше. Но на старте думать о них даже не приходилось по нескольким причинам.
Во-первых, команда была небольшой — и хотелось сделать решение максимально под себя, без лишней универсальности.
Во-вторых, почти сразу стало понятно, что потребуется много настроек: разные команды по-разному смотрят на процессы, и жёсткие правила здесь не работают.
И наконец, хотя о масштабировании я тогда думала скорее на уровне мечт, уже было понятно, что решение должно максимально аккуратно встраиваться в существующий рабочий порядок — особенно если к нему когда-нибудь подключатся другие команды. Добавление ещё одного инструмента означало бы лишнюю сложность для всех участников.
Важный момент: мы сознательно избегали решений, которые требуют от разработчиков дополнительных действий. Никаких «нажмите кнопку», «заполните поле» или «теперь делаем по-другому». Хорошая автоматизация реагирует на то, что люди и так делают каждый день.
Зачем понадобился отдельный сервис
После того как я обозначила проблемы и ограничения, стало очевидно: разбираться с ними по отдельности — плохая идея. Даже если каждая автоматизация сама по себе выглядит простой, без общей точки сборки они быстро превращаются в плохо управляемый набор решений.
Так у нас появился отдельный сервис автоматизации — внешнее приложение, которое живёт рядом с GitLab и таск-трекером. Этот сервис:
выполняет фоновые проверки по расписанию;
взаимодействует с GitLab API и API таск-трекера;
хранит запускаемые файлы для CI/CD (упакованные в джобы);
и отправляет уведомления в корпоративный мессенджер.
По сути сервис стал единым слоем логики между GitLab, трекером и командами разработки. Все дальнейшие автоматизации выросли именно из этого слоя: они использовали общие механизмы обработки событий, хранения настроек и фоновых задач.
Уточню важный момент: сервис я написала с нуля. Однако в компании уже существовал небольшой внутренний инструмент, который когда-то решал узкую задачу — автоматически менял статусы задач. Он был написан на Go, работал без реляционной базы и без полноценных периодических задач, при этом активно использовал webhooks и был интегрирован с GitLab.
Со временем мы переехали на другой таск-трекер, часть логики устарела, и проект перестал развиваться. Когда я вернулась к идее автоматизации процессов вокруг GitLab, показалось разумным сначала внести минимальные правки в существующее решение, чтобы закрыть базовую потребность, а уже затем спроектировать новый сервис, в котором изначально будут учтены недостающие инструменты.
В итоге новый сервис не стал продолжением старого кода — он опирался только на накопленный опыт. Архитектуру я собирала исходя из того, чего раньше не хватало: нормального хранения состояния и настроек, а также поддержки периодических задач.
Дальше оставалось определиться, на чём сервис будет жить технически. Я выбрала то, с чем мне было проще всего быстро и безопасно двигаться дальше:
Python — поскольку я заядлый питонист;
Django 5 — дал админку «из коробки», чтобы не городить фронт в нулевой итерации (хотя потом он всё равно начал появляться);
Django-ninja — удобные схемы и документация;
arq — лёгкий инструмент для периодических задач;
Postgres — для хранения состояния и настроек;
Redis — для очередей и временных данных.
За состоянием и логами слежу через Grafana. А «мониторинг без мониторинга» устроен так: задачи и проблемы довольно быстро проявляют себя уведомлениями в мессенджер. Если уведомления внезапно перестали приходить — у меня есть отдельный канал поддержки, и после обращений туда я иду смотреть логи.
Автоматизация №1. Статусы задач, которые больше не нужно помнить
Первая вещь, которую я сделала, — автоматическое обновление статусов задач. Потому что именно это напрямую влияло на прозрачность работы команды: если статус не соответствует реальности, дальше начинает плыть всё — от планирования до релизов.
Тут мне снова повезло: в компании уже был процесс привязки задач к merge request’ам. При создании ветки и MR мы обязательно указываем ID задачи в начале названия. Благодаря этому сервису не нужно угадывать, к какой задаче относится MR — связь определяется однозначно.
Дальше я просто сформулировала правило: какое действие в GitLab означает, что задаче пора перейти в другой статус. Получилась вполне понятная цепочка:
MR создан → задача в работе (In Progress)MR выведен из Draft → можно ревьюить (Code Review)есть комментарии и нужны серьёзные правки → возвращаем в доработку (Reopen)MR аппрувнут → можно отдавать дальше (Ready for testing)MR смёржен → ждём релиза (Waiting for release)выехало на прод → закрываем (Closed)
Названия статусов тут условные — у каждой команды может быть своя модель. Важна сама идея: в GitLab уже происходят события, которые довольно честно отражают стадию работы.
Технически всё свелось к обработчикам: прилетает webhook, мы парсим событие, достаём ID задачи из ветки/MR, смотрим настройки команды и вызываем API трекера, чтобы обновить статус.
Почти всё работает на webhooks — кроме закрытия задач после релиза: это пришлось делать по крону, потому что «задача выехала на прод» не всегда выражается одним простым событием на стороне MR.
Нюансы, которые всплыли сразу
Быстро выяснилось, что команды по-разному понимают «когда именно» надо двигать статус. Поэтому переходы пришлось делать настраиваемыми, вплоть до включения флагов вида is_reopen_enabled=True и похожих вещей. И тут же возник следующий вопрос: где хранить конфиги.
В текущем подходе мы храним такие настройки в CI/CD variables, а сервис забирает их из GitLab по API и применяет. Это оказалось удобным компромиссом: настройки рядом с проектом, редактируются привычным способом и не требуют отдельного интерфейса на старте.
Отдельной темой стала безопасность. Как только появляется бот с токеном, который умеет ходить в GitLab и трекер, он потенциально может делать многое. Это не «стоп-фактор», но требует аккуратного обращения с секретами и правами: минимально необходимые доступы, нормальное хранение токенов и осознание того, что сервис теперь часть доверенной зоны.
После того как статусы начали обновляться автоматически, стало видно, что подход работает. Тимлиду стало проще понимать реальное состояние задач, а разработчикам — меньше держать в голове «что я забыла подвигать». И вот с этого момента мы действительно вошли во вкус.
Автоматизация №2. Лейблы, ревью и неожиданный поворот с авторством
Когда статусы задач начали обновляться автоматически, открылся следующий узкий момент — само code review. Даже когда MR наконец-то попадал в ревью, всё равно приходилось тратить время на первичное погружение: что внутри, насколько большой объём изменений, есть ли тесты, трогали ли интеграции.
В GitLab мы активно используем лейблы — как быстрые маркеры контекста. Они не заменяют ревью, но позволяют ещё до открытия кода понять, чего от MR ожидать: большой ли это рефакторинг, фича или просто обновление зависимостей, писал ли автор тесты и проверял ли изменения локально.
Проблема была в том, что лейблы регулярно забывали выставлять. А значит — их тоже нужно было автоматизировать. И начала я с них.
Первая попытка: автосоздание merge request’ов
На первом этапе решение выглядело логичным и даже элегантным. Раз происходит push в ветку — почему бы сразу не создать merge request автоматически? Сервис и так знает проект, ветку и связанную задачу. Можно сразу назначить assignee, навесить нужные лейблы и получить «идеально оформленный» MR без лишних действий со стороны разработчика.
Технически это оказалось довольно просто реализовать через GitLab API. А потом выяснилось, что у подхода есть один неприятный побочный эффект.
Все такие merge request’ы создавались от имени бота. Это логично: доступ к GitLab у сервиса осуществляется через сервисный токен. Но на практике это означало, что мы потеряли авторство изменений.
Формально автором MR становился бот. А дальше начинались странные эффекты: сложно понять, кто именно отвечает за код, кого пинговать с вопросами, и кому в итоге «принадлежит» этот кусок изменений. Ещё пропадал привычный социальный механизм: возможность ткнуть пальцем и сказать «это твой код, иди смотри».
Конечно, экономия пары кликов не стоит размывания ответственности. Поэтому мы отказались от автосоздания MR и оставили этот процесс за разработчиками.
Вторая итерация: автоматизируем всё, кроме создания MR
В итоге я остановилась на более консервативном варианте. Merge request по-прежнему создаётся вручную — чтобы авторство оставалось за человеком. А вот дальше сервис уже подключается автоматически: навешивает лейблы, проверяет контекст и подготавливает MR к ревью.
Это решение оказалось гораздо лучше с точки зрения командной динамики. Автоматизация не мешает привычному процессу, но при этом снимает рутину там, где она действительно мешает.
Здесь я поняла, что можно пойти ещё дальше.
Распределение ревьюеров: простой round-robin
Даже с аккуратно оформленными MR и понятными лейблами проблема никуда не исчезла: merge request’ы всё равно могли подолгу висеть в Code Review. Причина оказалась банальной — отсутствие явной ответственности.
Когда ревью «общее», оно на самом деле ничьё. В команде несколько разработчиков, у каждого свои задачи, и каждый думает, что ревью сделает кто-то другой. В итоге все немного виноваты и никто конкретно не отвечает.
Тогда появилась мысль: а что если назначать ревьюеров автоматически?
Для начала я выбрала самый простой и понятный подход — round-robin. Каждый новый merge request получает конкретного ревьюера, и дальше уже нет вопросов, кто именно должен посмотреть код.
Поскольку изначально я хотела, чтобы эта фича могла использоваться не только одной командой, пришлось немного усложнить модель. Появились данные о командах, проектах и связях между ними, а также информация о том, кто из сотрудников может ревьюить какой проект. Это оказалось полезно, например, для онбординга: сначала человек ревьюит один проект, потом постепенно подключается к следующим.
Чтобы round-robin работал честно и предсказуемо, сервису понадобилось хранить состояния. В частности:
ID проекта в GitLab,
название команды,
ID сотрудников в GitLab и ID сотрудников в корпоративном мессенджере,
информацию о том, кто и сколько раз был ревьюером.
Без этого алгоритм быстро начал бы «жульничать», постоянно назначая одних и тех же людей.
После того как эти данные легли в базу, сам алгоритм оказался довольно прямолинейным: берём следующего подходящего человека и назначаем его ревьюером.
Напоминания и неизбежные минусы
Назначить ревьюера — это только половина дела. Вторая половина — напомнить, что ревью всё-таки ждут. Поэтому поверх распределения ревьюеров я добавила периодические напоминания. Расписание можно было настраивать через админку: например, раз в три часа в рабочее время.
Оповещения отправлялись в корпоративный мессенджер и продолжали приходить, пока ревью не будет сделано. В одной из команд это выглядело особенно бодро — напоминания шли каждые три часа с десяти утра до пяти вечера.
Чтобы работать с системой, людям сначала нужно было получить доступ в админку — зарегистрироваться и получить права. Делать это вручную каждый раз быстро надоело, поэтому со временем я добавила крон-таску, которая раз в минуту подхватывает новые аккаунты и автоматически выдаёт базовые права, снижая порог входа.
Интересный момент: распределение ревьюеров не сделало ревью быстрее. Зато оно сделало процесс прозрачнее. Теперь было понятно, кто именно отвечает за конкретный MR, и это уже само по себе сильно меняло поведение.
На этом этапе сервис перестал быть «про статусы» и стал по-настоящему про процессы. Следующей логичной задачей стало то, что происходит вне GitLab, но напрямую влияет на команду каждый день — дежурства и ответственность за входящие запросы.
Автоматизация №3. Дежурства: когда «кто-нибудь ответит» перестаёт работать
Когда вопросы внутри команды или от соседних команд начинают сыпаться регулярно, формула «кто свободен — тот и отвечает» работает слабо. В чате постоянно мелькают одни и те же вопросы, люди отвлекаются от основной работы, а в итоге всё равно не всегда понятно, кто именно сейчас отвечает за входящие запросы. Формально вроде бы отвечают все, а по факту — никто.
Раньше мы пытались решать это вручную. Кто-то делал табличку, кто-то писал в чат, кто-то просто держал всё в голове. Проблема была даже не в самой ротации, а в том, что реальная жизнь постоянно вмешивается в эти планы: люди имеют наглость внезапно уходить в отпуск, брать выходные и даже болеть. А значит, всё это нужно как-то учитывать.
И раз уж я автоматизирую процессы вокруг разработки, казалось логичным автоматизировать и дежурства.
На первый взгляд задача выглядела простой: взять список людей и крутить его по кругу. Но одного списка, конечно, оказалось недостаточно. Нужно понимать, кто вообще может быть дежурным, кто ещё новичок и пока не готов, кто сейчас отсутствует, какое расписание у конкретной команды и в какой чат нужно писать уведомления.
Все эти вещи оказались не «особыми случаями», а нормальным состоянием системы. Поэтому без хранения данных в базе тут было не обойтись. Помимо уже существующих сущностей, сервису понадобилась дополнительная информация:
название общего чата команды, чтобы оповещать всех её участников о том, кто и когда дежурит;
ID специального тега для дежурных в корпоративном мессенджере (он всегда один и тот же, но внутри него находится только текущий дежурный);
имя и фамилия каждого сотрудника;
признак того, что человек уже не новичок и может выходить на дежурство;
несколько полей для хранения периодов отсутствия — отпусков, больничных и т.д.;
данные о расписании смены дежурного.
Логика выбора человека на дежурство в итоге получилась вполне прямолинейной. При первом запуске система ещё ничего не знает о том, кто и когда дежурил раньше, поэтому берёт список сотрудников команды, которые в принципе могут быть назначены на дежурство. Из этого списка сразу исключаются те, кто в данный момент отсутствует.
Дальше всё работает по кругу: первый дежурит, за ним следующий и так далее. Если становится известно, что у кого-то намечается отсутствие, система автоматически сдвигает очередь — кто-то временно исключается из ротации и возвращается обратно после окончания отпуска или больничного.
Самое приятное в этом подходе то, что он практически убрал необходимость договариваться вручную. Не нужно писать «а можешь за меня подежурить?» — система сама перестраивает график, учитывая текущие данные.
Но одного алгоритма недостаточно. Людям хотелось видеть будущее: кто будет дежурить завтра, через неделю или через месяц. Особенно это оказалось важно при планировании отпусков.
Так в сервисе появился график с прогнозом дежурств и отдельная страница под него. Реализована она была без изысков — на Django templates, с использованием готовых Python-библиотек для построения графиков (plotly и pandas). Этого оказалось более чем достаточно.
Заодно график стал отличным способом проверки логики. Если прогноз выглядит странно — значит, где-то ошибка в данных или в алгоритме.
Естественно, поверх всего этого появились уведомления. В общий чат команды приходит сообщение о том, кто и в какие даты дежурит, а сам дежурный получает отдельное уведомление. Плюс — возможность задать кастомное сообщение для каждой команды, чтобы сразу написать, что именно от дежурного ожидается в этом конкретном случае.
Очевидный минус здесь — настройка расписаний. Cron-выражения с пятью звёздочками пугали людей, поэтому я добавила несколько популярных вариантов (пресетов) и оставила возможность указать своё расписание — куда ж без кастомизации.
Дальше начались бесконечные итерации по улучшению алгоритма: корректно учитывать отсутствия, правильно тасовать дежурных, не ломать график прогнозов. Если с выбором дежурного было относительно просто, то заставить корректно работать прогноз — то ещё удовольствие.
И последнее, но важное: ручные действия всё равно остаются. Если кому-то нужно экстренно убежать, полностью автоматизировать это невозможно. В таких случаях дежурного приходится менять вручную. Для этого я добавила отдельный API-эндпойнт, но сам факт остаётся фактом — иногда к автоматизации всё равно приходится прикасаться руками.
Автоматизация №4. Релизы: когда «пора выкатываться» становится очевидным
Следующей проблемой оказалось накопление задач к релизу. Подходов к релизам существует много: кто-то выкатывается по расписанию — например, каждый вторник, кто-то копит изменения до определённого момента, а потом делает один большой релиз.
В нашем случае использовался как раз второй подход. Мы накапливали задачи и в какой-то момент ловили себя на мысли: «что-то у нас давно релиза не было». После этого шли и выкатывали всё разом.
Проблема была в том, что вместе с мелкими правками в релиз уезжали и достаточно важные задачи, функциональность которых была готова и протестирована уже давно. Они просто ждали момента, когда о них кто-то вспомнит.
Решение снова нашлось на стороне GitLab — точнее, в его довольно обширном API. Оно не всегда работает идеально, но умеет многое. В частности, GitLab позволяет получить список коммитов, которые составляют разницу между двумя состояниями приложения — через механизм repository compare.
Именно на этом механизме я построила логику оповещений. Сервис периодически проверяет, сколько веток с фичами было влито в основную ветку, но так и не доехало до прода. Проще говоря — сколько готовых изменений уже ждут релиза.
Проверка не завязана на конкретные события. Вопрос «пора ли выкатываться» не возникает в момент мержа — он возникает со временем. Поэтому логика работает по расписанию.
Дальше встал вопрос гибкости. У всех было разное мнение о том, как часто стоит делать релизы и какого размера они должны быть. Вместо того чтобы навязывать один «правильный» подход, я просто добавила настройки.
Для каждой команды можно задать порог — количество веток (или фич), которое считается критическим. Если разница между основной веткой и продом превышает этот порог, сервис отправляет оповещение. Плюс, по уже привычной схеме, настраивается расписание запуска проверки — всё это хранится в базе данных.
Дополнительно понадобилось хранить описание окружений — URL’ы сервисов в деве и проде, чтобы корректно сравнивать состояния и понимать, что именно считается задеплоенным.
Оповещения, конечно же, отправляются в чаты команд. При этом я сознательно сделала сообщения агрегированными: одно сообщение на команду со списком проектов, где накопилось слишком много изменений, вместо формата «один проект — одно сообщение». Так чат не превращается в спам, но при этом сразу понятно, где именно пора что-то делать.
После этого оповещения просто начали приходить — и внезапно оказалось, что релизы стали происходить чаще и спокойнее. Не потому что кто-то кого-то заставил, а потому что состояние системы стало видимым.
Нюансы в случае с этим подходом были связаны, в основном, с безопасностью: теперь сервису требовался расширенный доступ не только к GitLab, но и к корпоративному таск-трекеру. Это добавило ответственности и требований к аккуратной работе с токенами, но критичных проблем за этим не последовало.
Бонус: статистика по задачам
Последней фичей из первой волны автоматизаций стала, пожалуй, самая любимая у менеджеров — сбор статистики по задачам.
Здесь я пошла уже проторенной дорожкой: периодическая задача по расписанию, сбор данных по задачам в выбранных проектах и возможность выбрать, за какими статусами хочется наблюдать. Самое важное — видеть, сколько времени задача проводит в каждом из этих статусов.
Оповещения, как и в остальных случаях, отправлялись в корпоративный мессенджер — в общий чат команды, на всеобщее обозрение.
При этом хранить эти данные в базе я не стала. Сервис просто проходит по задачам конкретной команды в корпоративном таск-трекере, «на лету» формирует сообщение и отправляет его. Никакой истории, никаких отчётов — только актуальный срез. Этого оказалось более чем достаточно, чтобы сделать менеджеров чуть-чуть счастливее.
Как и ожидалось, без ограничений не обошлось. В первую очередь — настройка самих сообщений. Всем хочется свою разбивку, больше вложенности и больше кастомизации. Но каждая новая «хотелка» довольно быстро превращает код в космолёт.
Поэтому я сознательно ограничила вложенность двумя уровнями (статус → кастомный разделитель) и зафиксировала это решение, добавив чуть больше информации прямо в строки оповещений. Иногда действительно лучше остановиться вовремя.
Как внутренняя автоматизация стала общим инструментом
Какое-то время все эти фичи использовались только в моей команде. Потом я решила выйти на новый уровень и рассказать об инструменте знакомым лидам из других команд.
Люди начали пробовать автоматизации, к приложению появился интерес, а вместе с ним — идеи для улучшений. Я отбирала их довольно аккуратно и внедряла только те, которые действительно ложились в общую концепцию.
Так появились:
оповещения о необходимости заполнить секцию для QA с важными направлениями для тестирования (периодическая таска);
оповещения о том, что изменения в сабмодуле могут ломать другие проекты, которые его используют (джоба с проверкой);
оповещения о потенциальных проблемах с интеграциями из-за изменений In/Out схем в API (ещё одна джоба).
Через некоторое время я представила приложение на общей инженерной встрече внутри компании. И вот тут пришёл настоящий успех: интерес вырос, запросов стало больше, начали всплывать баги — и мне даже пришлось создать отдельный канал поддержки проекта.
Немного цифр
На протяжении примерно полугода я наблюдала за проектом, дополняла его, меняла и донастраивала. В итоге получилось собрать некоторую статистику.
Больше половины команд разработки начали пользоваться этими автоматизациями — около 51%.
Самой популярной фичей стало назначение дежурных — её использовали 36% команд с подключёнными автоматизациями.
Менеджерам понравилось, что задачи находятся в актуальных статусах, а у разработчиков исчезла головная боль «не забыть подвигать задачу».
Распределение ревьюеров никак не повлияло на скорость ревью, зато теперь всегда было понятно, кто именно «редиска».
Компания в итоге получила собственный внутренний инструмент для поддержки процессов разработки — бесплатный, гибкий и воплощающий практически любые идеи.
За это время количество пользователей автоматизации выросло примерно в 26 раз — с трёх человек в начале до 80 на момент сбора статистики. К проекту подключились не только разработчики, но и тестировщики с техподдержкой.
Конечно, по ходу дела было много вопросов. Зачем вообще нужны эти автоматизации, если всё можно сделать руками? Почему бы не купить готовое решение? Не проще ли просто «растить ответственность в команде»?
Отвечу на это мемом.
Если серьёзно, одной из принципиальных целей, как я уже писала выше, было не менять поведение разработчиков. Все автоматизации строились вокруг уже существующих действий: создания merge request’ов, аппрувов, мержей, комментариев. Если для работы системы требовалось бы дополнительное действие от разработчика — это была бы плохая автоматизация.
Мораль тут простая: автоматизация не всегда про экономию времени. Часто она про удобство и отсутствие фоновой головной боли.
Моя команда настолько вошла во вкус, что теперь любые неудобные или «ленивые» вещи мы оцениваем ещё и с точки зрения: а стоит ли это автоматизировать?
P.S. А что дальше?
Сбор статистики оказался полезен не только для менеджеров, но и для меня самой. Анализ данных помог понять, куда развивать сервис дальше. Оказалось (абсолютно внезапно), что всё это время я покрывала автоматизациями процессы разработки, которые уже много раз были описаны и формализованы до меня.
Когда я разложила фичи по процессам, стало видно, что автоматизациями покрыто около 80% всех процессов разработки — с учётом того, что ручные операции всё равно остаются в отдельных случаях.
И вот тут для проекта открылись новые горизонты.
Идеи по покрытию оставшихся 20% уже есть. Некоторые из них даже начинают воплощаться в жизнь, пока я пишу этот текст. Параллельно продолжается развитие текущих фичей — там тоже есть куда расти.
Так что проект живёт, развивается, обрастает пользователями, а я продолжаю получать от этого удовольствие. Чего и вам желаю.
Всем автоматизация!
