Заметки консультанта

Шамрай Александр Владимирович

Posts Tagged ‘release management’

Динамическое изменение свойств веб приложений при развертывании релизов Visual Studio Team Services

Posted by Shamrai Alexander на Июнь 29, 2018

При развертывании веб-приложений можно использовать различные Web.config или appsettings.json, чтобы применять различные строки подключении к базам, служебные логины и пароли и т.д. для различных сред, на которых веб приложение будет выполняться. Но, если хранить такие данные для среды разработки и тестовых стендов еще можно, то такие данные для промышленных сред желательно убрать от общих глаз. Одним из элементов, который позволяет упростить ситуацию с хранением учетных данных, строк подключения и т.д., является трансформация элементов конфигурации. Т.е. есть возможность динамически и прозрачно для разработчиков и поддержки устанавливать необходимые конфигурации в зависимости от среды развертывания. Данный элемент настраивается на шаге развертывания веб приложения в Azure или IIS. Пример для указания какие фалы изменять показан ниже:

А в свойствах определения релиза уже указываются: какие свойства необходимо заменить на какие значения, при этом конфиденциальные данные могут быть скрыты:

Реклама

Posted in Microsoft, Team Foundation Server, Visual Studio, visual studio team services | Отмечено: , , , , | Leave a Comment »

Как установить порог качества для развертывания релиза в TFS и VSTS

Posted by Shamrai Alexander на Май 15, 2018

Возможности TFS/VSTS Release Management позволяют обеспечить «врата качества» не только на основе утверждения от какого-то участника команды разработки, когда он в ручном режиме «дает добро» на развертывание релиза на необходимом стенде, но и на основе привязки к запросам по рабочим элементам. Это позволяет обеспечить следующие правила проверки для развертывания на стенде:

  1. Не превысили ли мы порог количества высоко приоритетных или важных ошибок на релиз или продукт.
  2. Все ли требования для данного релиза покрыты тестами.
  3. Все ли тесты для релиза закрыты после проверки.
  4. И т.д.

Приведем небольшой пример: на момент выкатки релиза не должно быть ошибок с критической важностью. Для этого нужно выполнить следующие шаги:

  • Предварительно необходимо подготовить запрос по рабочим элементам, который отберет необходимые ошибки:

  • Далее перейти на страницу редактирования релиза:

  • Перейти на свойства предварительных условий для развертывания в необходимой среде:

  • Выбрать в разделе Gates пункт Query Work Items

  • Указать наименование для проверки в секции Display Name и в выпадающем списке указываем запрос, который содержит выборку необходимых рабочих элементов, в секции Query. Также в можно указать максимальный и минимальный порог для количества отбираемых рабочих элементов.

  • Сохраняем и запускаем новый релиз. Разворачиваем результаты сборки на стенде, который имеет настроенную проверку.

  • Если указанный в настройках запрос не содержит никаких рабочих элементов, то развертывание запуститься сразу. В противном случае развертывание не будет происходить и будет показана следующая подсказка:

  • При просмотре журнала развертывания можно увидеть примерно следующий результат:

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

Posted in Microsoft, Release Management FAQ, Team Foundation Server FAQ | Отмечено: , , , , | Leave a Comment »

 
%d такие блоггеры, как: