Comments 12
Хорошо ложка к обеду, осталось написать статью на Хабр с плюсов и минусов
github.com/lesstif/php-jira-rest-client
github.com/lesstif/php-jira-rest-client
Я натыкался на него перед публикацией, да. Использовать не довелось, так что могу провести только поверхностную оценку. Для нормального сравнения всё-таки стоит попользоваться обоими клиентами в реальных условиях.
Насколько я вижу из документации к клиенту — lesstif/php-jira-rest-client это только та часть нашего клиента, которая в \Badoo\Jira\REST\Client. Хотя lesstif/php-jira-rest-client покрывает API JIRA интерейсами лучше нас. Например, для того, чтобы создать новый проект через API, у нас придётся пользоваться \Badoo\Jira\REST\ClientRaw, а в клиенте lesstif есть для этого удобная обвязка.
Но помимо самого клиента к API мы предоставляем набор ActiveRecord классов, которые умеют прозрачно догружать данные из API при необходимости и обновлять их в JIRA. + каждое кастомное поле в JIRA можно представить отдельным классом и создавать такие классы с помощью генератора PHP-кода, так же поставляемого с клиентом.
Повторюсь, это поверхностная оценка, т.к. я не использовал lesstif/php-jira-rest-client, но пока мне кажется, что опубликованный нами клиент — это часть lesstif/php-jira-rest-client + куча дополнительных обвязок, которых в lesstif нету и которые делают использование API сильно удобнее.
Насколько я вижу из документации к клиенту — lesstif/php-jira-rest-client это только та часть нашего клиента, которая в \Badoo\Jira\REST\Client. Хотя lesstif/php-jira-rest-client покрывает API JIRA интерейсами лучше нас. Например, для того, чтобы создать новый проект через API, у нас придётся пользоваться \Badoo\Jira\REST\ClientRaw, а в клиенте lesstif есть для этого удобная обвязка.
Но помимо самого клиента к API мы предоставляем набор ActiveRecord классов, которые умеют прозрачно догружать данные из API при необходимости и обновлять их в JIRA. + каждое кастомное поле в JIRA можно представить отдельным классом и создавать такие классы с помощью генератора PHP-кода, так же поставляемого с клиентом.
Повторюсь, это поверхностная оценка, т.к. я не использовал lesstif/php-jira-rest-client, но пока мне кажется, что опубликованный нами клиент — это часть lesstif/php-jira-rest-client + куча дополнительных обвязок, которых в lesstif нету и которые делают использование API сильно удобнее.
Спасибо, задумались о том, чтобы активно начать использовать вашу либу.
Скажите, а как в итоге справились с авторизацией, у нас периодически наши костыли перестают работать, потому что JIRA начинает требовать введение капчи, есть какой-то рецепт?
И ещё, вы плагины свои для JIRA не пишите?
Скажите, а как в итоге справились с авторизацией, у нас периодически наши костыли перестают работать, потому что JIRA начинает требовать введение капчи, есть какой-то рецепт?
И ещё, вы плагины свои для JIRA не пишите?
Лично мне плагины писать не довелось, хотя возможно кто-то этим в компании и занимался, так что не готов однозначно ответить. В большинстве случаев нам хватает Adaptavist ScriptRunner'а (он очень много плюшек даёт), WebHook'ов, настроек переходов Workflow и кастомных полей.
Про капчу — мы сами от этого периодически страдаем, так что я нормального способа не знаю :(
К сожалению JIRA не даёт возможность сказать про пользователя «да, это робот, я знаю, пусти!». Последний раз когда я проверял информацию про настройки капчи — её можно было либо выключить совсем для всех, либо для всех использовать. Мы предпочли её оставить.
Так что на капчу мы наступаем при каждом рестарте nginx, который живёт над нашей JIRA: соединения между nginx и JIRA рвутся и та вспоминает что AIDA — робот.
Единственное решение, которое мы для этого нашли — адекватно ругаться в exception о том, что мы схлопотали капчу:
Это позволяет быстрее понять, почему именно отваливаются скрипты, зайти в JIRA и ввести капчу ручками, чтобы разблокировать пользователя.
P.S.: если вы ходите в JIRA напрямую, то возможно добавив nginx между вашим клиентом и JIRA вы уменьшите количество показываний капчи. Судя по тому что мы наблюдаем, JIRA не трогает роботов, если они ходят через уже существующие соединения. Так что nginx с keepalive-соединениями к upstream'ам могжет сильно облегчить боль. По сути, мимо nginx'а-то мы никогда и не ходили, так что возможно причина не в этом. Но то, что мы ловим капчу при каждом рестарте nginx'а заставляет меня думать что всё именно так работает.
Про капчу — мы сами от этого периодически страдаем, так что я нормального способа не знаю :(
К сожалению JIRA не даёт возможность сказать про пользователя «да, это робот, я знаю, пусти!». Последний раз когда я проверял информацию про настройки капчи — её можно было либо выключить совсем для всех, либо для всех использовать. Мы предпочли её оставить.
Так что на капчу мы наступаем при каждом рестарте nginx, который живёт над нашей JIRA: соединения между nginx и JIRA рвутся и та вспоминает что AIDA — робот.
Единственное решение, которое мы для этого нашли — адекватно ругаться в exception о том, что мы схлопотали капчу:
throw new \Badoo\Jira\REST\Exception\Authorization(
"Access to the API method is forbidden. You either have not enough privileges or the capcha shown to your user"
);
Это позволяет быстрее понять, почему именно отваливаются скрипты, зайти в JIRA и ввести капчу ручками, чтобы разблокировать пользователя.
P.S.: если вы ходите в JIRA напрямую, то возможно добавив nginx между вашим клиентом и JIRA вы уменьшите количество показываний капчи. Судя по тому что мы наблюдаем, JIRA не трогает роботов, если они ходят через уже существующие соединения. Так что nginx с keepalive-соединениями к upstream'ам могжет сильно облегчить боль. По сути, мимо nginx'а-то мы никогда и не ходили, так что возможно причина не в этом. Но то, что мы ловим капчу при каждом рестарте nginx'а заставляет меня думать что всё именно так работает.
Ясно, жалко, видимо пока мы все продолжим страдать с этой капчей, как вариант, сделаем отправку уведомления в Slack при получение такой ошибки, чтобы фиксить проблему оперативней.
За совет с ScriptRunner'ом тоже спасибо.
За совет с ScriptRunner'ом тоже спасибо.
Плагин для авторизации, например через какие нибудь токены пишется за час. Просто генерируется что то в формате JWT для юзера, в дополнение можно проверять IP если хочется больше секурности, все веселее чем гонять пароля туда сюда.
Если вы знакомы с Java, со стеком JIRA, то да, пишется за час. А если на Java никогда не писал, сейчас работаешь PM'ом и в последний раз коммерческий код писал полтора года назад на PHP…
В общем-то да, солидарен тут.
Даже если опыт разработки актуальный (пишешь код сейчас), но он на другом языке и с внутренностями JIRA ты при этом не знаком — плагин это сложно.
По рабочим задачам мне приходилось писать JAVA-код для работы с задачами JIRA из ScriptRunner'а. До этого я с JAVA в роли разработчика не сталкивался. Всё в комплексе — знакомство и с JAVA и с JIRA JAVA SDK — это так себе удовольствие для человека «со стороны»: документация, на мой взгляд, скудная, при этом структура JIRA JAVA SDK ещё хуже чем её REST — для выполнения простых действий приходится делать кучу сложных телодвижений: фабрики всякие, контроллеры и пр. При этом есть большое количество deprecated-методов и те подходы что были каноническими 3-4 года назад сейчас уже «фу-фу» и «не надо так!».
На то, чтобы обновить значение кастомного поля в задаче и подвинуть её статус, мне пришлось гуглить и экспериментировать минут 30.
Разработка ещё осложняется тем, что быстро из коробки получить нормальную локальную среду с autocomplete'ом и подсказками по коду без знания «что качать», «откуда взять библиотеку классов JIRA» и «куда её в этой среде подпихнуть чтобы она подхватилась» не получается. И в итоге ты как слепой котенок — рыскаешь рецепты в сети, пробуешь, спотыкаешься и понимаешь, что рецепт уже не актуален т.к. методы deprecated или выпилены и идёшь на новый круг.
Когда вы знакомы с разработкой плагинов, эта библиотека знаний о том, как и что использовать — она у вас в голове, и о многих вопросах, с которыми сталкиваются новички, вы даже не задумываетесь.
Процесс погружения в JAVA/JIRA достаточно трудоёмкий, и если само написание плагина действительно может занимать час-два, то вместе со знакомством с языком, с доступной библиотекой классов, с инструментами, с процессом отладки и подготовкой окружения это может растянуться на неделю.
Даже если опыт разработки актуальный (пишешь код сейчас), но он на другом языке и с внутренностями JIRA ты при этом не знаком — плагин это сложно.
По рабочим задачам мне приходилось писать JAVA-код для работы с задачами JIRA из ScriptRunner'а. До этого я с JAVA в роли разработчика не сталкивался. Всё в комплексе — знакомство и с JAVA и с JIRA JAVA SDK — это так себе удовольствие для человека «со стороны»: документация, на мой взгляд, скудная, при этом структура JIRA JAVA SDK ещё хуже чем её REST — для выполнения простых действий приходится делать кучу сложных телодвижений: фабрики всякие, контроллеры и пр. При этом есть большое количество deprecated-методов и те подходы что были каноническими 3-4 года назад сейчас уже «фу-фу» и «не надо так!».
На то, чтобы обновить значение кастомного поля в задаче и подвинуть её статус, мне пришлось гуглить и экспериментировать минут 30.
Разработка ещё осложняется тем, что быстро из коробки получить нормальную локальную среду с autocomplete'ом и подсказками по коду без знания «что качать», «откуда взять библиотеку классов JIRA» и «куда её в этой среде подпихнуть чтобы она подхватилась» не получается. И в итоге ты как слепой котенок — рыскаешь рецепты в сети, пробуешь, спотыкаешься и понимаешь, что рецепт уже не актуален т.к. методы deprecated или выпилены и идёшь на новый круг.
Когда вы знакомы с разработкой плагинов, эта библиотека знаний о том, как и что использовать — она у вас в голове, и о многих вопросах, с которыми сталкиваются новички, вы даже не задумываетесь.
Процесс погружения в JAVA/JIRA достаточно трудоёмкий, и если само написание плагина действительно может занимать час-два, то вместе со знакомством с языком, с доступной библиотекой классов, с инструментами, с процессом отладки и подготовкой окружения это может растянуться на неделю.
Ну вот да, у нас сейчас есть целый пул не стандартных задач по JIRA которые не сделать только через её настройки. И пока путь:
— Выстрелить WebHook'ом в наш сервис по работе с JIRA
— Обработать запрос
— Сделать необходимые изменения используя JIRA REST API
Кажется значительно проще, чем напрягать коллег пишущих на Java сделать вводную в язык, потом неделю разворачивать локальное окружение, потом напрягать DevOps'ов делать полноценный DevStage с CI/CD (вместо просто поднятия копии из бэкапа)…
— Выстрелить WebHook'ом в наш сервис по работе с JIRA
— Обработать запрос
— Сделать необходимые изменения используя JIRA REST API
Кажется значительно проще, чем напрягать коллег пишущих на Java сделать вводную в язык, потом неделю разворачивать локальное окружение, потом напрягать DevOps'ов делать полноценный DevStage с CI/CD (вместо просто поднятия копии из бэкапа)…
Мы в Badoo ровно по этому пути и пошли.
99% задач этот flow покрывает, но увы, не все. Некоторые узкоспециальные вещи через REST API сделать нельзя. Поэтому лезть внутрь нам, хоть и крайне редко, но всё-таки приходится.
Будьте к этому морально готовы :)
У нас для экспериментов с JIRA есть staging-версия, которая раз в сутки синхронизируется с продом.
Эта staging-версия используется админами для накатывания обновлений, чтобы случайно не ушатать прод при переходе на новую версию JIRA или обновлении плагина. Её же мы (релизеры) используем для обкатки наших скриптов: вебхуков, запросов к API, правок workflow и пр.
Синхронизация с продом удобна тем, что у тебя для экспериментов всегда есть актуальное состояние JIRA и ты можешь безопасно поиграть с «настоящими» проектами и тикетами, не рискуя при этом поломать что-то работающим сейчас коллегам.
99% задач этот flow покрывает, но увы, не все. Некоторые узкоспециальные вещи через REST API сделать нельзя. Поэтому лезть внутрь нам, хоть и крайне редко, но всё-таки приходится.
Будьте к этому морально готовы :)
У нас для экспериментов с JIRA есть staging-версия, которая раз в сутки синхронизируется с продом.
Эта staging-версия используется админами для накатывания обновлений, чтобы случайно не ушатать прод при переходе на новую версию JIRA или обновлении плагина. Её же мы (релизеры) используем для обкатки наших скриптов: вебхуков, запросов к API, правок workflow и пр.
Синхронизация с продом удобна тем, что у тебя для экспериментов всегда есть актуальное состояние JIRA и ты можешь безопасно поиграть с «настоящими» проектами и тикетами, не рискуя при этом поломать что-то работающим сейчас коллегам.
Не так страшен черт, как его малюют. Для быстрого старта вам нужен JDK и SDK атлежена (если у вас линукс то это 5 минут, если windows то минут 15). Документация у них и вправду хромает, (JIRA еще ничего, а вот bitbucket) но вот SDK у них самодостаточный, две команды:
И у вас поднят чистый инстанс в дебаге, чего достаточно для разработки 80% плагинов на старте. Плюс там спринг, у нас джун с явой на уровне университета справлялся с первой простой задачей за пару дней.
В компании в которой я работаю, использовался описаный выше подход довольного долго, в какой то момент размазанная логика просто убивает перформанс команды разработки, вместо написание бизнес-логики, разработчики начинали искать всякие обходные пути через REST, скриптраннер и тп, вместо простого плагина. В итоге мы взяли и за полгода выкинули всю php`шную обвязку, за исключением внешних сервисов.
По поводу вашей конкретной проблемы с авторизацией, это можно сделать и на скрипт раннере, правда вам придется вешать авторизацию на отдельный роут и потом таскать за собой куки, что в принципе не сложно с вашим клиентом, но выглядит уже не настолько красиво.
atlas-create-jira-plugin
atlas-debug
И у вас поднят чистый инстанс в дебаге, чего достаточно для разработки 80% плагинов на старте. Плюс там спринг, у нас джун с явой на уровне университета справлялся с первой простой задачей за пару дней.
В компании в которой я работаю, использовался описаный выше подход довольного долго, в какой то момент размазанная логика просто убивает перформанс команды разработки, вместо написание бизнес-логики, разработчики начинали искать всякие обходные пути через REST, скриптраннер и тп, вместо простого плагина. В итоге мы взяли и за полгода выкинули всю php`шную обвязку, за исключением внешних сервисов.
По поводу вашей конкретной проблемы с авторизацией, это можно сделать и на скрипт раннере, правда вам придется вешать авторизацию на отдельный роут и потом таскать за собой куки, что в принципе не сложно с вашим клиентом, но выглядит уже не настолько красиво.
Спасибо за совет.
Похоже, это хорошее решение задачи, над которым лично я даже не задумывался. Мне почему-то не пришло в голову, что авторизацией в JIRA можно управлять через плагины и аналог того, что в Cloud версии JIRA называется токенами авторизации (которые используются вместо паролей для доступа к API) можно самому собрать на коленке.
Мы, правда, не очень искали решение проблемы, т.к. из-за наличия «вечно живого» nginx над JIRA проблема с капчей у нас всплывала раз в пару месяцев, а иногда не проявлялась и по полгода. Так что капча — это, конечно, грабли, но били они не настолько больно, чтобы заморачиваться со сложным решением.
Похоже, это хорошее решение задачи, над которым лично я даже не задумывался. Мне почему-то не пришло в голову, что авторизацией в JIRA можно управлять через плагины и аналог того, что в Cloud версии JIRA называется токенами авторизации (которые используются вместо паролей для доступа к API) можно самому собрать на коленке.
Мы, правда, не очень искали решение проблемы, т.к. из-за наличия «вечно живого» nginx над JIRA проблема с капчей у нас всплывала раз в пару месяцев, а иногда не проявлялась и по полгода. Так что капча — это, конечно, грабли, но били они не настолько больно, чтобы заморачиваться со сложным решением.
Sign up to leave a comment.
Badoo Jira API Client: магия в Jira на PHP