Управление выпуском продуктов
Многие команды уже поверили и проверили эффективность непрерывной интеграции, механизма, позволяющего поставить качественный продукт пользователю в любой момент времени. Вместо длинных релизов, продукт может поставляться так часто, как это позволяет технологический процесс. Это значит, что пользователю не нужно ждать улучшения продукта в очередном релизе через 3 месяца, из-за того, что в нем разрабатывается фича для другого пользователя и все сломано или разобрано.
Цель непрерывной интеграции - как можно раньше собрать, проверить продукт и сообщить команде о его качестве. Для реализации непрерывной интеграции вы можете использовать, например, Jenkins, который соберет продукт, запустит модульные и функциональные автотесты, сообщит Devprom о наличии сборки, импортирует в Devprom отчеты по тестированию, а также сообщит какие доработки были реализованы и какие ошибки исправлены.
Команда разработки фокусируется на качественных сборках, разрабатывает автоматические тесты и старается не допускать длительного отсутствия качественных сборок.
Тестировщики используют непрерывную интеграцию, как способ получать качественные сборки продукта для проведения ручного тестирования и формирования финального решения о готовности сборки к поставке. Тестировщики не тратят время на проверку сломанных сборок и могут приступить к тестированию сразу, как в списке появится качественная сборка.
Платформа Devprom ALM не занимается сборкой и выкладкой приложений. Для этого есть специальные инструменты под названием серверы сборок (сборочные серверы, сборщики), например, Jenkins, TeamCity. Эти инструменты настраиваются на непрерывный цикл выпуска сборок и выполняют все необходимые для этого действия.
Devprom ALM позволяет визуализировать сборки и их статус: в процессе сборки, сборка сломалась, успешно развернута и т.п. В модуле "Сборки" описана команда, используемая для интеграции сборочного сервера и платформы. В дополнение к информации о статусе сборки, вы можете сообщать расположение сборки и выдержку их журнала сборки (или ссылку на журнал сборки).
При обновлении информации о сборке указывайте коммит (версию или номер). Система автоматически привяжет к этой сборке те задачи и требования, которые попали в этот коммит. Также система сможет показать список коммитов, которые вошли в каждую из сборок. Это существенно упрощает локализацию изменений, которые привели к поломке сборки или автоматических тестов.
Если вы собираете несколько приложений в рамках одного проекта, то используйте поле "Приложение", в котором можно сохранить его название.
В модуле "Сборки" отображаются все добавленный сборки, их статус, информация о тестах, реализованных требованиях и обнаруженных дефектах. Это основной информационный радиадор готовности продукта (или его сборок) к передачи для ознакомления тестировщикам, аналитикам, представителям заказчика или конечным пользователям.
Когда у вас накопится много сборок, используйте признак "Устарела", чтобы отметить устаревшие сборки. В выпадающих списках на формах будут отображаться только актуальные (неустаревшие) сборки.