Каковы преимущества интеграции исходного кода для системы отслеживания ошибок?

Jira вместе с FishEye (браузер SCM) может, если вы зафиксируете набор изменений с сообщениями журнала, содержащими ключ проблемы Jira, например" PROJ-123 ", вставьте ссылку в соответствующую проблему Jira, и Jira отобразит ссылку в PROJ-123 на набор изменений, в котором упоминается эта проблема.

Jira также может интегрироваться с Hudson, так что при выполнении сборки, включающей исправление (т. Е. Набор изменений), Проблема Jira, упомянутая в сообщении журнала этого коммита, получит комментарий о статусе сборки.

Поскольку средство отслеживания проблем используется для отслеживания проблем с исходным кодом, существует множество функций, которые можно представить в интегрированной системе управления проблемами / исходным кодом.

Я сделал это с помощью Visual Studio Team Foundation Server, который не только интегрируется с системой управления версиями, но также интегрируется с хранилищем данных. Это позволяет отслеживать, например, какие ошибки были вызваны какими фрагментами кода, показывая, какие фрагменты кода нуждаются в дополнительном контроле качества. Предстоящие функции в версии 2010 еще более привлекательны.

Основным преимуществом является то, что вы можете выдвигать ошибки в отношении определенных версий исходного кода. Это просто помогает определить состояние кодовой базы, когда ошибка была замечена. Я думаю, что популярным продуктом в этой области является Trac, который интегрируется с SVN.

Что ж, я бы сказал, что здесь есть одна большая причина, и это то, что вы можете работать с ориентацией на задачу / проблему.

Я имею в виду:

• каждое изменение кода, которое вы делаете (все, от небольшого быстрого исправления до большой новой функции) будет проблемой в Jira или Rally или Bugzilla, Trac, Mantis, который вам нравится.

• Это означает, что система отслеживания проблем / задач должна быть простой в использовании, быстрой, простой и т. Д., Иначе разработчики возненавидят ее.

• Затем свяжите каждое изменение с проблемой, и все готово. Вы получаете полную отслеживаемость (отлично подходит для отладки различий, вы пропустите ее, если у вас ее нет), лучшее отслеживание проекта, лучшее управление выпусками и так далее.

Вы можете связать каждый набор изменений / фиксацию (в зависимости от вашего жаргона scm) с задачей или, если ваш scm может это сделать, создать ветку для каждого исправления, что еще лучше.

По сути, вы получаете просто: каждое изменение будет задокументировано или, по крайней мере, связано с нужной проблемой / задачей.

Если вы используете ветки, вы можете продвигать такие вещи, как: всегда работать со стабильными базовыми показателями, уменьшать коррупцию основной ветки (или делать ее нетронутой, если хотите), решать, какие задачи интегрировать, а какие держать до следующего выпуска, индивидуально запускать тесты на изменения перед слияние и так далее.

Github, по сути, наоборот: это не столько система отслеживания ошибок / проблем с включенным контролем версий исходного кода, сколько скорее, контроль версий исходного кода с добавлением некоторого отслеживания ошибок / проблем. Я не могу поверить, что никто не упомянул об этом здесь, потому что в наши дни это более распространено.

Но он очень мощный, вы можете ссылаться на все, что предлагает git, также в задачах: коммиты, ветки, запросы на вытягивание. Github даже установил некоторую «автомагию», объединение PR с контентом типа «устраняет проблему № 23» автоматически закрывает проблему № 23.

Github также очень удобен, потому что большая часть программного обеспечения с открытым исходным кодом, которое используется в настоящее время, также размещена там, и вы также можете ссылаться на все эти библиотеки в своих собственных задачах / запросах на перенос и т. Д. Также большая часть типичной современной коммерческой инфраструктуры, связанной с разработкой программного обеспечения, также будет интегрирована с Github: Travis или Codeship расскажет, как идут дела у ваших сборок, и даже развернет их автоматически, Hound или Rubocop расскажет, как выглядит ваш код, и Usersnap или Trackduck будет помещайте отчеты об ошибках в свои проблемы на Github, если вы не хотите использовать их программное обеспечение.

Trac, упомянутый в ответах здесь, кажется действительно старым, если сравнить его с Github.