CruiseControl.NET должен использоваться для справлений с задачами, которые не связаны с созданием источника?
Странный вопрос, возможно. У нас есть много простых утилит, записанных внутренний, который должен быть выполнен на автоматизированной основе. Это не задания сборки. Просто вещи как выполнение SendOutHourlyEmailAlarms.exe, KeepFoldersInSynch.exe и такой. Я обычно настраивал бы эти вещи как простые запланированные команды ЗАДАЧ/В (или служба Windows, если более тонкая настройка необходима по планированию), но коллега настроил много этих задач, как разрабатывают проекты на сервере CruiseControl.NET. Я спросил его, почему он установил их, этот путь и его ответ состояли в том, что выполнение (и их журналы, возвращаемые значения, вызванные исключительные ситуации) было все прослежено и зарегистрировано и что эта информация была доступна через организованный интерфейс на веб-сайте сервера сборки. Я не мог спорить с этим.
Но это просто имеет запах, который я не могу вполне определить. Действительно ли это - надлежащее использование CruiseControl.NET? В противном случае, каковы опасности? Даже если это может отвечать всем требованиям, не там другие продукты, которым лучше удовлетворяют для этого типа вещи?
3 ответа
У нас есть всевозможные задачи, не связанные со сборкой, по той же причине, что и у вашего коллеги: я хочу, чтобы в одном месте можно было найти все задания, которые мне нужно выполнить.
Некоторые примеры наших проектов CC.NET:
FTP-установщики для удаленного контроля качества
Создание документации по исходному коду
Создание виртуальных машин с помощью установщиков устанавливается для QA утром
Архивные установщики
Практически все, что мне приходится делать вручную более одного раза, становится проектом. ИМХО, это намного лучше, чем запланированное задание, еще по одной причине. Наши файлы конфигурации находятся в системе контроля версий, поэтому у нас есть одно место для внесения изменений. Нам не нужно входить на несколько серверов и вносить изменения или задаваться вопросом, какой сервер это сделал.
Тот факт, что инструмент предназначен для решения конкретной проблемы, не означает, что у него не будет равных возможностей для решения аналогичных проблем, выходящих за рамки, изначально задуманные создателем инструмента. Если CruiseControl.NET хорошо решает эти проблемы, то это абсолютно подходящий инструмент.
Думаю, ваш коллега привел хороший аргумент. Если эти задачи связаны с процессом разработки, то размещение их в CruesControl.Net в качестве проекта кажется приемлемым. Я бы хотел подвести черту в использовании сервера разработки для запуска производственных процессов. Хотя верно то, что «если единственный инструмент, который у вас есть, - это молоток, вы склонны рассматривать каждую проблему как гвоздь», это не означает, что молоток не способен решить множество проблем!