Мы уже использовали TeamCity (отличный инструмент непрерывной интеграции) для выполнения наших сборок, которые включали модульные тесты.Было упомянуто три больших улучшения:
1) Установочный комплект и развертывание UAT в один клик
Мы упаковали наше приложение как установочный комплект, используя NSIS (не MSI, который был гораздо более сложным и ненужным для наших нужд).Этот установочный комплект сделал все необходимое, например, остановил IIS, скопировал файлы, поместил файлы конфигурации в нужные места, перезапустил IIS и т. Д. Затем мы создали конфигурацию сборки TeamCity, которая запустила этот установочный комплект удаленно на тестовом сервере, используя psexec.
Это позволило нашим тестировщикам самим развертывать UAT, если они не содержали изменений в базе данных - но они были намного реже, чем изменения кода.
Производственные развертывания были,Конечно, они были более сложными, и мы не могли их так автоматизировать, но мы по-прежнему использовали тот же установочный комплект, который помог обеспечить согласованность между UAT и производством.Если что-то отсутствовало или не было скопировано в нужное место, оно обычно подбиралось в UAT.
2) Автоматизация развертывания базы данных
Развертывание изменений базы данных было большой проблемой, посколькуЧто ж.Мы уже писали все изменения в базе данных, но все еще были проблемы с определением того, какие сценарии уже были запущены, а какие еще нужно выполнить и в каком порядке.Мы рассмотрели несколько инструментов для этого, но в итоге получили свои собственные.
Сценарии БД были организованы в структуру каталогов по номеру выпуска.В дополнение к сценариям разработчики должны были добавить имя файла сценария в текстовый файл, по одному имени в строке, в котором указан правильный порядок.Мы написали инструмент командной строки, который обработал этот файл и выполнил сценарии для данной БД.Он также записал, какие сценарии он выполнял (и когда) в специальной таблице в БД, и в следующий раз он не запустил их снова.Это означает, что разработчик может просто добавить сценарий БД, добавить его имя в текстовый файл и запустить инструмент для БД UAT, не спрашивая других, какие сценарии они выполняли последними.Мы использовали один и тот же инструмент в работе, но, конечно, он запускался только один раз в каждом выпуске.
Дополнительный шаг, который действительно помог этой работе, - это запуск развертывания БД как части сборки.Наши модульные тесты работали с реальной БД (очень маленькой, с минимальными данными).Сценарий сборки восстановит резервную копию БД из предыдущего выпуска, а затем запустит все сценарии для текущего выпуска и создаст новую резервную копию.(На практике это было немного сложнее, потому что у нас также были выпуски исправлений, и резервное копирование делалось только для полных выпусков, но инструмент был достаточно умен, чтобы справиться с этим.) Это гарантировало, что сценарии БД были протестированы вместе при каждой сборке, и если разработчики вносят противоречивые изменения в схему, она будет быстро обнаружена.
Единственные ручные действия были во время выпуска: мы увеличивали номер выпуска на сервере сборки и копировали «текущую БД»резервное копирование, чтобы сделать его «последней версией» резервной копии.Кроме того, нам больше не нужно было беспокоиться о БД, используемой при сборке.Иногда необходимо было восстановить базу данных UAT из резервной копии (например, поскольку система не смогла отменить изменения для удаленного сценария БД), но это было довольно редко.
3) Ветвление дляrelease
Звучит просто и почти не стоит упоминать, но мы не занимались этим с самого начала.Объединение изменений может, конечно, быть болью, но не такой большой болью, как наличие единой кодовой базы для сегодняшнего выпуска и следующего месяца!Мы также заставили человека, который сделал большинство изменений в ветвях релиза, выполнить слияние, что напомнило всем о том, что их ветки релизов должны сохранять абсолютный минимум.