Надкусил собаку, при настройке CI на базе jenkins. Проглотить мешают постоянные всякие мелочи. Например из последнего: плагин Virtualenv Builder [Shiningpanda], с помощью которого можно более лучше развертывать виртуальные окружения python, принимает настройку "name". По документации, настройка соответствует названию virtualenv окружения. Изменение этой опции не влияет на фактическое название окружения (по факту получается что-то вроде c934fdf).
При всем этом, Shiningpanda реально экономит время при создании CI для python проекта.
Сборка:
[Virtualenv Builder]
pip install pytest pytest-cov
$PYTHON_EXE setup.py install
py.test --junitxml junit.xml --cov-report xml --cov src tests.py
Постсборка:
[Cobertura coverage]
coverage.xml
[juint]
result.xml
И далее в постсборке запускает выкатка библиотеки и/или обновление девелоперского-стейджа.
А как в ваших компаниях реализован CI?
4 комментария:
У нас тот же Jenkins, ну и Travis для открытых проектов на github.
А как у вас деплой устроен? Не собираете deb/rpm-пакеты с помощью Jenkins?
Был jenkins пока был админ и тестировщик, я его поддерживать не стал, вырубил. Изменился контекст задач и ресурс, изменились инструменты. Тесты (остались только модульные) и покрытие каждый смотрит сам, деплой - через fabric (для своего сервера) и стандартные инструменты AWS-EB. Из опыта возни со всем этим вынес несколько выводов (сугубо ИМХО, на истину в последней инстанции не претендую):
1. Автодеплой - зло, даже если код прошел тесты, это еще не значит что его можно не глядя деплоить. Все действия с боевым сервером должны осуществляться явно.
2. Нельзя ограничивать выкатку, если тесты не проходят. Срочные форсмажоры никто не отменял.
3. Любой левый инструмент может сломаться (привет, django-jenkins) или обновляться вечность, лучше обходиться минимумом.
4. Иногда все что надо от jenkins может уместиться в 3 строках git-hook.
deb пакеты пока не собираем, т.к. оверхед по этой работе при текущем кол-ве админов и серверов больше, чем польза. Но конечно хочется в перспективе порядка, и чтоб все было как у взрослых ).
Дима, согласен с каждым словом. В нашем проекте мы словили очень много лулзов, когда выяснили что проект под высокой нагрузкой с кол-вом записей в таблицах до миллиона - это принципиально не тоже самое, что с миллионом записей. Уверен, что про взрослые CI среды есть смысл говорить только в контексте сложных окружений или централизованного отслеживания результатов.
Радоваться хорошему покрытию кода и отсутствию багов приятно вместе ;), а не по одиночке.
Автодеплой продакшена - не просто зло, а зло абсолютное, а вот стейджу для разработчиков лучше всегда быть в актуальном состоянии, т.к. это здорово влияет на скорость приема изменений.
Короче, сколько проектов, столько и пониманий о том как можно сделать лучше. Чем меньше неопределенностей, тем больше порядка. Добавить человека в команду с jenkins'ом можно легче и быстрей, чем в команду с тестами только на стороне разработчиков.
Отправить комментарий