Комментарии 17
Мы завели сервисную учётку в Jira, сделав бота, который работает с API, избавляя нас от большого количества ручной работы. С помощью скрипта на Python мы решили несколько задач:
- дважды в день в определённое время проходить по всем созданным JIT-задачам в нашем капасити;
- проверять прилинкованные Jira-тикеты, считать их и обновлять их количество в JIT-задаче;
оставлять комментарии;- проверять правильность связи между JIT-задачей и Jira-тикетами.
Что-то вы всё усложняете. Зачем всё это делать, а потом всё это автоматизировать? Не проще ли упростить рабочий процесс (workflow) и выкинуть из него всё лишнее, что не приносит ценности? Всегда надо помнить, что чем проще, тем лучше.
Зачем проверять связи между JIT-задачей и Jira-тикетами и исправлять их, если можно потратить время на анализ и определить причину проблемы, почему такие связи могут отсутствовать, быть некорректными и прочее, чтобы уже затем эти проблемы исправить, а не делать автоматизацию, которая применяет workaround.
Зачем проверять связи между JIT-задачей и Jira-тикетами и исправлять их, если можно потратить время на анализ и определить причину проблемы
Все как раз таки очень просто - проверка связи в первую очередь это средство контроля, потому что ошибки при простановке связи чаще всего человеческий фактор, сейчас уже не испытываем этих проблем, но решили о них сказать.
Никогда не делай, то, что можно сделать за 2 минуты, если это можно автоматизировать за 6 часов
request = requests.post(url=url, data=payload, headers=headers, auth=auth)
auth не объявлен
return request, error
Дважды return, надо ли? :)
batchs = []
batchs.append(x)
batchs.append(y)
batchslist.append(batchs)
Я бы заменил на: batchslist.append([x, y])
Коллеги, спасибо за хорошую статью.
Единственное, вот это гляньте
https://www.psycopg.org/docs/usage.html#the-problem-with-the-query-parameters
Вот так лучше не делать, а использовать параметры у execute
get_rule_condition = f"SELECT rule_conditions from rule where id = {int(id)}" cur.execute(get_rule_condition)
Коллеги, спасибо за статью. Выглядит так, что вы достаточно много используете скриптов, скорее всего под каждую задачу пишете новый / обновляете старый и так далее - как организуете их "хранение" и шеринг между сотрудниками? В git'е держите исходники или в общем хранилище где-то? Или каждый сам у себя держит папочку с самым нужным?
А если, например, для какой-то задачи писали скрипт, и через месяц потребуется провести аналогичную работу - где этот скрипт найти?
у нас есть несколько типов скриптов, одни которые используются ежедневно в рамках рутинных задач, другие пишутся для определённых целей и используются более редко. Но все они лежат на гите - поэтому там все это можно найти. Самое главное, что если кто-то пишет новый скрипт, обязательный пункт - пройти код-ревью, а также придерживаться описанной в наших доках стилистике написания и оформления скриптов. Ну и чаще всего, скрипт рождается из задач, где нужны, например, массовые изменения - изначально ставится отдельная задача на аналитику, описанию алгоритма и так далее, обычно мной как тимлидом команды, либо более опытным коллегой, знающим более углубленно необходимый продукт.
А если запрос упадет по таймауту, скрипт упадет?
Точно валидно с принтами работать?
Спасибо за статью
Отличная статья, спасибо за полезные приёмы
В поле url мы указываем строку запроса
Может эндпоинт с параметрами?
Статья хорошая, но прочитав ее, стало интересно, для чего вы ходите в кафку и что туда складывание? Для чего ходите в базу и так далее?
Ну и по сути, если вы делаете много всяких "запросов", "фиксов" и так далее, то становится немного страшно: а все ли ок у озона? Ибо в компании в которой я работаю, если ребята из тех поддержки приходят с подобными запросами, то значит у нас где-то баг и нужно его фиксить, ну или это запрос новой функциональности.
Статья хорошая
спасибо!
для чего вы ходите в кафку
На самом деле очень редкий кейс, сейчас уже не помню когда мы что-то с ней делали
Ну и по сути, если вы делаете много всяких "запросов", "фиксов" и так далее, то становится немного страшно: а все ли ок у озона? Ибо в компании в которой я работаю, если ребята из тех поддержки приходят с подобными запросами, то значит у нас где-то баг и нужно его фиксить, ну или это запрос новой функциональности.
С озоном все хорошо, если ты внимательно читал, я в итогах описывал почему это так и зачем) Глобально - все верно, ИТ-поддержка как раз и занимается тем, что приходит к разработке с найденными ошибками и они их исправляют, но описывать взаимодействие - отдельная тема для другой статьи, очень много разных процессов. Большая разница лишь в том, что разрабы чинят причину, поддержка последствия, тем самым мы экономим их время.
Боже, как я обожаю эту статью!
Сказ о том, как специалисты IT-поддержки скрипты писали…