Все это хорошо и даже замечательно, вот только у меня на кафедре по дисциплине «Метрология и сертификация» были не «проблемы оценки метрических характеристик качества ПО», а метрология и сертификация… измерительных приборов! А что поделать, когда завкаф — старая дура?
Вполне возможно, что «проблемы оценки метрических характеристик качества ПО» не входят в учебный план, предусмотренный по дисциплине «Метрология и сертификация». Особенно касается тех специальностей, которые направленные, например, «Метрология и сертификация (в машиностроении)/(в металлургии)/и т.п.»
Как раз моя специальность — это и есть 220400 — «Программное обеспечение вычислительной техники и автоматизированных систем» по направлению 654600 «Информатика и вычислительная техника». Вот только, как я уже сказал, завкаф — старая дура и думает, что программист.
К счастью, я уже выпустился, и этот бардак, который называется «образование» меня больше не касается.
плюсую. инструменты полезные. не всеми пока довелось попользоваться, но когда пишешь крупный проект, за всем уследить становится труднее и нужны дополнительные средства. Особенно когда работаешь один и проект тянется больше года.
Открою секрет сами по себе инструменты эти не особо полезны, так как в основном предоставляют отчеты в xml форме, но после интеграции с другими продуктами могут сделать разработку более комфортной.
Нужно будет попробовать обязательно. Что мне в нем особенно кажется примечательным — это возможность не принимать коммит в репозиторий если провалились какие-то тесты или инспекции. Так чтобы никто не мог передать в репозиторий сбойный код. В bamboo этого нет.
И к тому же для приложений которые поставляются как есть, такое будет наверное больше вредить нежели помогать, а вот если это контроллер к искусственной почке тогда да.
Да, наверное так и есть — но у нас после удачного билда идет автоматический деплоймент на рабочие серверы, поэтому без тестов никак. А если тесты провалились, то нафиг такой код в репозиторий принимать. Можно послать автору коммита сообщение и пускай поправит свой код. Так что почти как контроллер от почки получается ))
Кстати все эти желанные функции становятся все менее актуальны с переходом на репозитории Git вместо Subversion. Некоторое время назад поддержки Git в TeamCity не было, не знаю как сейчас. Возможно уже сделали?
Да, конечно — прежде всего это непрерывная обратная связь, автоматическое развертывание и апдейты проекта. Также очень полезен автоматический сбор всех метрик и инспекции, генерация документации. Причем в сценарии построения можно встроить не только генерацию api-документации но и пользовательской документации, если например писать ее в докбуке и компилировать во вемя билда через phd.
Вобщем преимуществ масса и многие из них зависят индивидуально от вашего проекта и как вы адаптируете автоматизацию к своему процессу разработки. Главное тут поменьше ручного труда ))
То есть для проекта есть три вида билдов: 1. быстрый билд (при каждом коммите в репозиторий) 2. полный билд (каждое утро — все проверки, инспекции и генерация документации) 3. деплоймент-билд (вручную — все проверки + обновление рабочих серверов)
Я тоже сейчас думаю что такая структура для каждого проекта оптимальна, так как полный билд занимает на текущий момент около 2 часов и это только сбор статистической информации без запуска единого теста.
Обеспечение качества программного продукта