Пытаюсь нати среди open-source репозиториев, такой который умеет:1. Commit с цифровими подписями, тех кто коммитит.
2. Проверка при commit качества исходного кода - автопрогон тест кейсов, проверка стиля кода принятому, проверка comments на соответсвие стилю javadoc. Если код не надлежащего качества, не коммитить.
3. Работает поверх ssh, http(очень желательно, чтобы без apache, а с помощью lighttpd, nginx)Я понимаю, что одним репозиторием кода, сдесь не обойтись, так как репозитории отвязаны от языка програмирования, а мои задачи специфические для каждого языка. Сейчас меня интересует проверка качества кода C++ и Python.
Чтобы такое кто-либо делал в инете я не нашел. Так что, кто-нибудь знает возможли на open-source посторить такое?
>2. Проверка при commit качества исходного кода - автопрогон тест кейсов, проверка
>стиля кода принятому, проверка comments на соответсвие стилю javadoc. Если код
>не надлежащего качества, не коммитить.Я, как разработчик, никогда бы не согласился работать с такой системой. Не потому что у меня нет стиля или я не следую стилю, принятому в проекте. А потому что эта система или будет иметь искусственный интеллект, или откажется принимать 20-50% любого кода нормальной сложности.
>>2. Проверка при commit качества исходного кода - автопрогон тест кейсов, проверка
>>стиля кода принятому, проверка comments на соответсвие стилю javadoc. Если код
>>не надлежащего качества, не коммитить.
>
>Я, как разработчик, никогда бы не согласился работать с такой системой.
>Не потому что у меня нет стиля или я не следую
>стилю, принятому в проекте. А потому что эта система или
>будет иметь искусственный интеллект, или откажется принимать 20-50% любого кода нормальной
>сложности.Я тоже разработчик и поработав в крупной зарубежной компании именно с такой системой, понял как все таки это повышает качество кода, при условии что все правильно сделано и количество ложных срабатываний с ведено к минимуму. Вот поэтому и пытаюсь сейчас у себя поднять подобный аналог.
>Я тоже разработчик и поработав в крупной зарубежной компании именно с такой
>системой, понял как все таки это повышает качество кода, при условии
>что все правильно сделано и количество ложных срабатываний с ведено к
>минимуму. Вот поэтому и пытаюсь сейчас у себя поднять подобный аналог.Хм... видимо, Вы работали с системой, надстроенной над ClearCase или прямым аналогом.
В которой у каждого разработчика есть свой "садок", где он может делать что угодно,
а готовый код сливается в "мегасадок", за которым следит специальный манагер.
Труд указанного манагера и автоматизируется описанным Вами способом.Такой вариант организации групповой разработки вполне возможен, но отнюдь не
является заведомо самым лучшим на все случаи жизни. Поскольку побочные затраты
на эксплуатацию такой формалистической системы контроля качества очень велики.Отвечая по существу на исходный вопрос - среди открытых систем управления кодом
аналога описанной Вами системе не найти. Системы управления кодом обычно делаются
"под себя", а разработчики открытых систем не особенно склонны к столь жесткой
формализации мелких деталей процесса. Проще ограничить круг людей, имеющих право
вносить изменения, теми, кто следует принятым стандартам качества, чем навязывать
эти стандарты механическим способом.
>Хм... видимо, Вы работали с системой, надстроенной над ClearCase или прямым аналогом.Правильно угадали :)
>Отвечая по существу на исходный вопрос - среди открытых систем управления кодом
>
>аналога описанной Вами системе не найти. Системы управления кодом обычно делаются
>"под себя", а разработчики открытых систем не особенно склонны к столь жесткой
>
>формализации мелких деталей процесса. Проще ограничить круг людей, имеющих право
>вносить изменения, теми, кто следует принятым стандартам качества, чем навязывать
>эти стандарты механическим способом.Да когда я ещё гуглил, понял что такого готового open-source решения мне не найти. Поэтому я ищу такой open source репозиторий, в котором есть достаточно развитий механизм hooks & triggers, на который я бы мог довесить самописные проверялки кода. Нужно чтобы можно было сделать, например такое, на все файли с расширением .py запустить проверялки (pyflakes, pychecker, pylint, которые настроены ловить конкретные баги (syntax errors, unused imports, unused variables), а не все подряд).
Также согласен, что каждому разработчику понадобится как минимум одна собсвенная ветка кода, в котором таких проверок не будет. Поэтому, я так понимаю это должен быть distributed репозиторий, который ориентированн на большое кол-во branches. Получается три основных кандидата (git, marcurial, bazaar), хотя может быть есть рояль в кустах.
>три основных кандидата (git, marcurial, bazaar), хотя может быть есть рояль
>в кустах.IMHO расрпределенность не обязательна. Так что основной кандидат - subversion.
>1. Commit с цифровими подписями, тех кто коммитит.Не понятно зачем это нужно :)
Если аутентификация нормально работает, то это лишнее, системы контроля версий и так пишут в журнал кто внёс изменения. Подписи нужны для обмена патчами по незащищённым каналам.
>2. Проверка при commit качества исходного кодаВ subversion есть триггеры, можно на внесение изменений поставить скрипт проверяющий всё что вам угодно.
>3. Работает поверх ssh
Это зачем? Чем это лучше ssl или шифрованных туннелей? Все сетевые работают через ssh, главное форвард настроить :)
>http(очень желательно, чтобы без apache, а с помощью
>lighttpd, nginx)По http можно только получать документы. Для передачи используются всякие полустандартные методы. Так что только CGI как альтернатива, ибо для этих серверов модули писать сложно, они однопоточные и не должны блокироватся (ждать). Я считаю не стоит на этом заморачиватся. А там где обязательно http - не грех и apache'м воспользоватся.
>>1. Commit с цифровими подписями, тех кто коммитит.
>
>Не понятно зачем это нужно :)
>Если аутентификация нормально работает, то это лишнее, системы контроля версий и так
>пишут в журнал кто внёс изменения. Подписи нужны для обмена патчами
>по незащищённым каналам.Кстати, да. Если хацкер сумел спереть пароль, то он сопрет и ключ.
>>2. Проверка при commit качества исходного кода
>
>В subversion есть триггеры, можно на внесение изменений поставить скрипт проверяющий
>всё что вам угодно.Угу. Посмотрел бы я на программу, которая автоматически сумеет проверить качество кода.
Есть, конечно, всякие flaw-finder'ы, но основная польза от них в том, что они надежно
обнаруживают тупые баги в большом объеме старого кода. А так по жизни без code reviews
и команды тестировщиков не обойтись.>>http(очень желательно, чтобы без apache, а с помощью
>>lighttpd, nginx)Интересно, почему без apache? Такая система в любом случае будет сущий монстр, и
наличие apache в ее составе мало что меняет.