Тестирование Python / интеграция с TeamCity / разумное управление пакетами

Мои коллеги и я в настоящее время предпринимаем небольшие шаги для автоматизации тестирования эмбриональной кодовой базы Python, но столкнулись с некоторыми проблемами, связанными с настройкой среды и управлением пакетами. Любая помощь приветствуется, так как мы не делали этого раньше с Python (и это выглядит немного... сломана).

Требования:

  • Тесты запускаются с помощью скрипта (Nose выглядит неплохо)
  • Он работает на машинах Windows
  • Его можно запустить через TeamCity, а также на стандартных компьютерах разработчиков. Хорошая отчетность/интеграция TeamCity будет бонусом.
  • Мы должны иметь возможность вызывать сценарии и получать правильные повторяемые результаты на нескольких машинах.
  • Все требования к зависимостям/пакетам выполняются простым повторяемым образом (мы делаем это с нашей основной кодовой базой, используя ruby ​​и упаковщик, и изо всех сил пытаемся повторить трюк с python). Если людям придется вручную устанавливать яйца / использовать easy_install и т. Д., Это будет ад. Вы должны просто иметь возможность вызывать скрипт, который говорит: «Пожалуйста, убедитесь, что эти зависимости учтены, а затем запустите наши тесты».

В идеале рабочий процесс должен работать так (на данный момент игнорируя то, как мы устанавливаем/получаем python):

  • Windows-машина синхронизируется с нашим SCM
  • Машина запускает скрипт, чтобы убедиться, что все зависимости Python (Shapely и т. д.) учтены
  • Машина может вызывать скрипт, который запускает нос или какой-либо другой тестовый бегун.
  • Сценарий возвращает значение, указывающее, не удалось ли выполнить сборку.

Вопрос о бонусных баллах:

Мы готовы установить python на каждую машину разработки/агента сборки, а не регистрировать его в системе управления версиями, хотя было бы неплохо, если бы мы могли просто зарегистрировать его и забыть об этом. На данный момент лучше всего на этом фронте просто проверить каталог установки python в SCM вместе с pythonxx.dll, найденным в Windows/System32, но я не уверен, что это ошибочный подход.

Мы заметили Movable Python и Портативный Python. Любая идея, что лучший подход? Как я уже сказал, мы готовы просто стиснуть зубы и установить Python на каждую машину с помощью .msi, если это нецелесообразно.

Ваше здоровье!


person Mark Simpson    schedule 10.05.2012    source источник


Ответы (1)


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

В итоге мы:

  • В SCM добавлен PortablePython 2.7. Это просто работает (тм).
  • В SCM добавлен curl.
  • Создал файл Windows .bat, который вызывает завиток, вытаскивает и устанавливает инструменты установки Python. Затем мы устанавливаем pip с помощью инструментов настройки (метаупаковка). Затем Pip запускается для файла требований. Файл требований pip содержит, среди прочего, Nose (средство запуска тестов Python) и teamcity-nose (интеграция TeamCity CI для Nose).

Затем мы вызываем средство запуска тестов, которое автоматически волшебным образом просматривает наши тесты без каких-либо хлопот. Неплохо!

Также собираюсь проверить virtualenv в будущем.

Изменить (через N лет):

Pip входит в стандартную комплектацию Python 2.7.9 и более поздних версий. Самый простой способ сделать что-то в наши дни (imo) - это что-то вроде:

  1. использовать pip из коробки
  2. установить виртуалэнв
  3. создайте виртуальную среду для проекта и активируйте ее
  4. установить зависимости с помощью pip (иногда, к сожалению, приходится возвращаться к easy_install)
  5. дискотека.

Кроме того, не используйте портативный python, если он вам действительно не нужен. Очень жаль, что мы не согласились на это.

person Mark Simpson    schedule 10.05.2012