Метка «release management»

в 7:58, , рубрики: release management, tfs 2013, Visual Studio, Блог компании Microsoft, управление проектами, метки: ,

Управление релизами в Visual Studio 2013Если вы разрабатываете сложные системы, то наверняка задумывались об автоматизации шагов, связанных с релизом. Представим, что вы создаете сложный многокомпонентный веб-сайт, инфраструктура которого разделена на несколько серверов.
Весьма заманчивым является сценарий, когда ваш процесс непрерывной интеграции и создания билдов продолжается автоматическим развертыванием этого сайта. При этом соблюдаются некоторые условия и критерии, например, требуется чтобы билд который готов к развертыванию в эксплуатационной среде проходил все тесты, и утверждался ответственными людьми из команды. Неизбежно возникает ряд моментов, которые усложняют процесс сборки, приходится создавать скрипты развертывания. Если учесть еще и процесс утверждения, то становится понятно, что такая автоматизация может быть достаточно трудоемким делом. К счастью в Team Foundation Server 2013 входит ряд инструментов, которые позволят значительно упростить управление релизами.

Кстати, 6 февраля пройдет конференция ALM Summit Russia в рамках которой мы подробно расскажем о возможностях Team Foundation Server 2013 по управлению релизами, и у читателей хабрахабра есть возможность воспользоваться скидкой 50%, для этого достаточно использовать промокод alm14_VS.
Читать полностью »

в 8:25, , рубрики: Git, git workflow, release management, Системы управления версиями, метки: , ,

Вливание legacy истории в дерево: нахождение оптимальной точки ответвленияПо долгу службы мне досталась в наследство некая система, имеющая ~15 лет истории и порядка нескольких десятков инсталляций в разных организациях. Сама по себе системы относительно небольшая (~25K строчек кода, ~1K коммитов), но проблема была в release management:

  • было основное дерево в subversion (изначально в cvs, разумеется), где проводился «основной курс партии» — делались какие-то масштабные изменения, добавлялись новые возможности, исправлялись глобальные ошибки и т.п.
  • конкретные инсталляции делались путем:
    • в лучшем случае — svn checkout, который потом обновлялся через svn update; почти во всех инсталляциях делались локальные доработки «на живую» (как минимум — правились конфигурационные файлы) и эти изменения никуда не коммитились; если при очередном svn update изменения в upstream создавали конфликт — конфликт ресолвился «на месте» тем программистом, который делал update, опять же, без какого-либо трекинга изменений
    • в худшем случае — svn export, который потом, понятно, не обновлялся совсем, оставаясь раз и навсегда (или по крайней мере пока начальство не одумается) на уровне развития даты экспорта; в особо запущенных случаях (из конца 1990-х — начала 2000-х) так делали еще и потому, что просто не было физической возможности сделать checkout — в организации не было доступа в интернет, архив просто приносили на дискетке и разворачивали единожды на месте

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

Читать полностью »

Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js