Веб-служба: однострочный параметр или параметры сложного типа
У нас есть неплохой набор модульных тестов для нашего кода, и эти модульные тесты выполняются менее чем за 2 минуты. Мы также используем TeamCity для выполнения сборки и запуска тестов после каждой регистрации. Однако у нас по-прежнему возникают проблемы, когда разработчик «забывает» запускать все тесты перед фиксацией, что приводит к сбою TeamCity, который, если эта проверка была выполнена в 18:00. может остаться сломанным в течение ночи.
«Забывает» - это общий термин, есть пара других распространенных причин, почему даже незапланированное выполнение тестов может привести к сбою TeamCity. Такие как.
-> Разработчик регистрирует только некоторые измененные файлы в своем рабочем пространстве.
у нас по-прежнему возникают проблемы, когда разработчик «забывает» запускать все тесты перед фиксацией, что приводит к сбою TeamCity, который, если эта регистрация была сделана в 18:00, может остаться неработающим в течение ночи.
«Забывает» - это общий термин, есть пара других распространенных причин, почему даже незапланированное выполнение тестов может привести к сбою TeamCity. Такие как.
-> Разработчик регистрирует только некоторые измененные файлы в своем рабочем пространстве.
у нас по-прежнему возникают проблемы, когда разработчик «забывает» запускать все тесты перед фиксацией, что приводит к сбою TeamCity, который, если эта регистрация была сделана в 18:00, может остаться неработающим в течение ночи.
«Забывает» - это общий термин, есть пара других распространенных причин, почему даже незапланированное выполнение тестов может привести к сбою TeamCity. Такие как.
-> Разработчик регистрирует только некоторые измененные файлы в своем рабочем пространстве.
-> Файл был изменен за пределами затмения, так что перспектива синхронизации команды eclipse не определяет его как грязный.
Как вы справляетесь с этим в вашей организации?
Мы думаем о введении «процедуры регистрации» для разработчиков, которая будет автоматизированным инструментом, который будет автоматически запускать все модульные тесты и затем фиксировать все «грязные» файлы в вашем рабочем пространстве. Был ли у вас опыт такого процесса? Вам известны какие-либо инструменты, которые могут облегчить этот процесс? Наша среда разработки - это Python, использующий плагин Eclipse PyDev.
4 ответа
Для Mercurial вы можете использовать перехватчики, которые будут запускать тесты и разрешать отправку только в случае успеха. Но для этого может потребоваться много времени (но разработчик все равно должен запустить эти тесты).
Или вы можете просто иметь собственный набор сценариев bash, которые будут запускать тест и только затем запускать команду фиксации. Например, для django и svn commit это может выглядеть так просто:
./manage.py test && svn commit $@
Или есть другой способ: если кто-то фиксирует код, который не проходит проверку, он платит некоторую сумму. Скоро люди вспомнят о тестировании, потому что им не понравится идея платить деньги; -)
В одной из команд я работал до того, как мы договорились, что любой, кто нарушит тесты, на следующее утро покупает бутерброды с беконом для всей команды. Это экстремально, но работает отлично!
TeamCity имеет некоторую поддержку предварительно протестированной фиксации ; если ваша команда разработчиков использует поддерживаемую среду IDE, вы можете изучить это.
В моей компании мы не особо об этом беспокоимся - наш паттерн выглядит примерно так.
(a) у каждого разработчика есть собственная конфигурация проекта в TeamCity, корни которой указывают на его собственную песочницу. Здесь им разрешено делать все, что им заблагорассудится.
(b) у команды разработчиков есть «песочница» интеграции, куда доставляются все изменения. Проект инкапсулирует конфигурации, которые контролируют эту ветвь в системе управления версиями. Руководители разработчиков могут устанавливать здесь правила, но это правило почти всегда гласит: «Он должен оставаться зеленым». Я должен был бы посмотреть на точный процент чистых сборок - это не идеальный показатель, но он достаточно высок, чтобы у меня никогда не возникало соблазна настаивать на том, чтобы разработчики были более дисциплинированными при проведении тестов.
(c) фактическая доставка происходит из основного потока, который должен оставаться зеленым (tm). Руководитель разработки отвечает за предоставление чистого снимка интеграции с основным потоком по четко определенному графику. Этот проект - тот, который фактически генерирует установщики, которые доставляются для тестирования, биты, которые отправляются на условное депонирование, и т. Д.
Одна из причин, по которой вы можете добиться более агрессивной политики, чем мы, заключается в том, что наш цикл сборки медленный - порядка четырех часов. Если бы мы были на порядок меньше и с малым успехом, я мог бы привести другой случай.
Я думаю, что это скорее социальная проблема, чем недостаток автоматизированных систем.
Да, вы можете улучшить существующие системы, но они не подойдут для тех, кто думает о последствиях своего коммита и тестирует его до того, как он совершит коммит.