Есть ли баг-трекинг?

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

У нас, например, для всего серьёзного стоит JIRA. Ну, эта мартышлюшка, конечно, иногда тормозит так, что терпения ноль ебать, но зато в ней можно настроить рабочие процессы (workflows), привязать задачи к коммитам в гите, доски скрамовые или канбанные — овердохуища возможностей. Для мелочёвки или своих внутренних инструментов хватает GitLab Issues или GitHub Issues — удобно, потому что всё прямо в репозитории, под рукой.

Но самое вкусное — это когда всё само заводит задачи. Подозрение ебать чувствую, что без автоматизации ты просто вручную будешь создавать тикеты, пока не сойдёшь с ума. Мы настраиваем так, чтобы при падении пайплайна в CI/CD или при поступлении ошибки в Sentry — хуяк! — и задача уже создалась в JIRA сама через веб-хуки.

Вот, смотри, упрощённый пример на PHP, если в логах через Monolog ловим какую-нибудь жуткую ошибку:

// Упрощенный пример отправки ошибки в JIRA
$issueData = [
    'fields' => [
        'project' => ['key' => 'PROJ'],
        'summary' => 'API Error: Database connection failed',
        'description' => 'Stack trace and context here...',
        'issuetype' => ['name' => 'Bug']
    ]
];

$client = new GuzzleHttpClient();
$response = $client->post('https://your-domain.atlassian.net/rest/api/2/issue', [
    'auth' => ['user', 'api_token'],
    'json' => $issueData
]);

Короче, без нормального баг-трекинга управление разработкой превращается в такой хаос, что хоть святых выноси. Это как пытаться построить дом без чертежа — в итоге получится пизда с ушами, а не продукт.