Я недавно взялся за задачу упрощения и автоматизации процессов в нашем конвейере разработки, и я ищу предложения / советы других о том, что было сделано для подобных проблем.
В настоящее время мы используем TFS 2019 / Azure Devops и стратегия ветвления:
Master
└ Major Version 1 QA
└ Major Version 1 Release
└ Major Version 2 QA
└ Major Version 2 Release
Мы используем рабочие элементы в TFS и связываем их, чтобы изменить наборы на ветви выше. Как правило, вся работа выполняется в Master и выборочно объединяется с QA в одной или обеих версиях по одной.
После тестирования / проверки изменения обычно объединяются массово с Release, когда они проходят go в другом раунде тестирования перед тем, как отправиться в публикацию c.
Эти слияния не всегда массовые, иногда они выполняются один за другим, иногда изменения объединяются из Main> QA> Release в одном shot (три регистрации для одной цели ...).
Кроме того, у нас есть отдельная система отслеживания ошибок, которая используется для сбора отчетов об ошибках из CSR, и эта система предоставляет статус внешним участникам (людям без TFS). доступ). Для этой настройки требуется, чтобы человек дублировал данные из TFS во внешнюю систему (и наоборот), что является серьезной неэффективностью, которую я пытаюсь решить.
В настоящее время рабочий элемент TFS содержит все примечания и обеспечивает связь чтобы указать c изменения кода. Я хотел бы переместить все в TFS и отбросить внешнюю систему, которая представляет следующие проблемы и вопросы:
- Как я могу предоставить доступное для чтения представление только для чтения данных рабочих элементов внешним не-разработчикам ? Кроме того, у TFS есть простая роль "сообщить об ошибке"? Я чувствую, что нечто подобное уже должно существовать, но, похоже, мне нужно будет создать или идентифицировать что-то, что интегрируется с TFS.
- При массовом объединении изменений индивидуальная ассоциация рабочего элемента с изменением кода теряется. Похоже, что это давняя жалоба на TFS, и я думаю, что мне нужно было бы написать сценарий слияния индивидуально для достижения автоматизации. Существуют ли другие способы?
- . Принимая во внимание приведенную выше стратегию ветвления, любое изменение в файле требует, как минимум, 3 повторных проверок, чтобы он появился в мире. Это хорошая стратегия? Идея заключается в том, что работа может непрерывно добавляться, пока ветки Release заморожены.
Дополнительная информация:
Мы небольшая команда из 5 разработчиков и 5 QA с Внешняя инфраструктура с соотношением сторон 20: 1 построена вокруг наших продуктов, поэтому я стремлюсь автоматизировать.
Спасибо за ваши советы / предложения!