Предложения развертывания

Question

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

• У нас есть три копии коды в раздельных Mercurial репозитории: Dev, PP (Pre -Производство) и Live. Изменения внесены в Dev, нажаты на PP для тестирования приема пользователей, а затем нажаты на Live, как только они будут приняты.
• Сборка с использованием TeamCity для создания предварительно скомпилированной версии, изменения не производятся вручную (все должно идти в исходное управление). Сборки предоставляются как zip-архивы как артефакты в TeamCity. Библиотеки классов строятся по требованию и привязаны к основной сборке как зависимости, файлы Bin хранятся только в контроле источника, где у нас нет исходного кода.
• Строки копируются в живую среду вручную с помощью RemoteDesktop и распаковываются. Файлы web.config хранятся от сборки до сборки и редактирования вручную при необходимости (живые пароли и т. д. не хранятся в контроле источника)

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

Answer 1

Вы можете сконденсировать это с одним экземпляром элемента управления с TFS и разветвить свой код для релизов.

Оттуда сборка может быть автоматизирована для запуска, тестирования и развертывания для «тестирования» каждую ночь/неделю. Ваша команда контроля качества (Quality Assurance) проведет проверку сборки (дальнейший тест поверх автоматизированных тестов) и либо одобрит, либо отклонит сборку.

Если качество сборки подходит, команда QA может установить качество сборки через визуальную студию или приложение панели уведомлений о сборке или непосредственно в портал tfs.

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

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

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

нижняя сторона ... бит сложный и неудобный для настройки, если вы не уверены в msbuild, но это не массивная кривая обучения, если вы привыкли к окружению MS dev.

...

Разработчики обычно имеют свои собственные «копия» работает на их компьютере решения, если решение является чрезвычайно сложным и в этом случае полностью виртуализированных среду разработки на отдельном домене, что ссылки на главную domainssource возможно, управляющий сервер.

зависит от сложности решения.