Рутинная работа, наверное одно из самых демотивирующих явлений. Как подумаешь что прежде чем сесть за интересную задачу, которую руки чешутся решить, нужно сначала разгрести таск-трекер, так сразу настроение начинает идти вниз.
Думаю пора начать серию постов о своем опыте автоматизации рабочих процессов и не только рабочих. Эта серия зрела давно. В двух словах сказать все что набралось невозможно. Поэтому постараюсь по порядку осветить все то, с чем пришлось столкнуться и что получилось успешно решить с помощью автоматизации.
И начну пожалуй с самой частой проблемы, о которой немного сказал вначале. Проблемы рутины. Давным-давно, когда я еще занимался работой на аутсорсе с небольшой командой, столкнулся с проблемой актуальности статусов и другой информации о задаче в таск-трекере. Приходилось ежедневно вручную контролировать этот вопрос, что утомляло и занимало время. В команде использовался redmine и он поддерживал интеграцию с git из коробки. Если указать в названии коммита номер задачи и статус, то он сменится в задаче автоматически. Но как заставить разработчиков не забывать правильно оформлять сообщения коммитов? Даже если они ответственные люди, все равно не исключен человеческий фактор и нарушения форматов будут, а это значит, что надеяться на этот механизм нельзя и нужно продолжать контролировать вручную. Безнадега.
Изучив тему, решил попробовать воспользоваться pre-receive хуком, который запускается на стороны сервера до того, как изменения будут приняты в репозиторий. Написать этот хук можно на bash/pyton/php и других скриптовых языках. Мне было это проще сделать на php. Скрипт занимался тем, что проверял сообщения коммитов на четко заданный формат, примерно такой "#{task-id}-{status} | {message}". Список возможных значений для status был жестко ограничен, так как соответствовал статуса в redmine. Хук не пропускал коммиты с неправильными статусами или неверными форматами сообщений. Он просто не давал пушить. Первое время это частенько кого-нибудь выбешивало, когда забывал оформить по правилам. Приходилось даже делать rebase когда коммитов в пуше не один и просто ammend не мог помочь. Но скоро уже все привыкли, комиты оформлялись правильно на автоматизме и проблема исчезла. В дальнейшем этот хук стал также проверять и статус задачи, например, не давая пушить в закрытые задачи. Это было несложно доработать с помощью Redmine API и даже нашелся [готовый php-клиент](
https://github.com/kbsali/php-redmine-api).
Реализация заняла у меня часа 4-5 в сумме. Если не считать первых попыток на bash, которые не увенчались успехом в виду моих не достаточно глубоких познаний в этом инструменте. В итоге статусы в задачах стали меняться автоматически, в каждой задаче был список коммитов, на которые можно было перейти и посмотреть что именно мы меняли. В истории git была привязка к задачам, в рамках которых делались изменения, я этим кстати часто пользовался, чтобы посмотреть для чего делались те или иные правки, смотрел переписку по задаче. Также часто помогало поиском по истории собрать воедино все правки по проблеме когда коммиты разбросаны. Вообщем время это экономило массу и привнесло порядка. Ну и конечно же я перестал беспокоиться об актуальности статусов и просто начал ими пользоваться. Если стоит статус released значит задача в мастере, если ready for development - значит ни одного коммита еще не сделано и т.д.
Все в команде настолько к этому привыкли, что как-то раз, когда этот хук внезапно отвалился, это вызвало небольшую волну возмущений, "а почему статусы перестали проставляться". Хук конечно же быстро починили.
Но правда одно ограничение все же есть. Pre-receive срабатывает на стороне сервера. И если у вас облачный github/gitlab/bitbucket, то использовать эту возможность не получится. По крайней мере я не нашел способа. Если кто-то его знает, то за подсказку в личку буду благодарен.
