Круиз-контроль .NET по сравнению с [закрытой] сборкой основы команды
db.collection.find({"createdDate":{$gte:new ISODate("2017-04-14T23:59:59Z"),$lte:new ISODate("2017-04-15T23:59:59Z")}}).count();
Замените collection именем коллекции, которую хотите выполнить запрос
5 ответов
Я использовал обоих. Я предполагаю, что это зависит от того, что оценивает Ваша организация.
, Так как Вы знакомы с Сетью CC, я не буду говорить очень с этим. Вы уже знаете то, что заставляет его охладиться.
Вот то, что мне нравится приблизительно Сборка Основы Команды:
- Агенты Сборки. Очень просто превратить любое поле в машину сборки и выполнить сборку на нем. MSFT разобралась в этом.
- Создание отчетов. Все соответствующие результаты сборки (включенный тест) хранят в базе данных SQL и сообщают относительно через SQL Server Reporting Services. Это - очень мощный инструмент для построения диаграммы сборки и результатов испытаний со временем. Сети CC не встроили это.
- можно сделать подобные настройки с помощью MSBUILD. Это - в основном то же, поскольку использующий NAnt с Сетью CC
Вот то, что управляет мной стена о Сборке Основы Команды:
- , Чтобы создать C++ / проекты CLI (или выполнить модульные тесты...?) агент сборки должен иметь VSTS Dev или установленный Комплект Команды. Это, друзья, просто batsh*t сумасшедшее.
- Это должно быть подключено к TFS Mothership
, Если Вы находитесь в большом org с большим количеством боссов, которые имеют огромные бюджеты и любят отчеты (и не понимайте меня превратно, это имеет огромное значение), ИЛИ необходимо увеличиться к ферме сборки мультимашины, я предпочел бы Сборку Основы Команды.
, Если Вы - более минимизированный магазин, палка с Сетью CC и выращиваете Ваши собственные решения для создания отчетов. Это - то, что мы сделали.
, Пока мы не были получены. И получил TFS: P
Я предполагаю что, поскольку Вы владеете TFS, Вы будете использовать его для управления версиями. В этом случае я склонился бы к Сборке Основы Команды. Однако я в значительной степени соглашаюсь с Nick.
я записал интеграция CruiseControl.NET для TFS. Это хорошо работает и дает Вам те же возможности сборки, к которым Вы привыкли. Мне основное преимущество CC.NET состоит в том, что это абсолютно расширяемо и имеет интеграцию со всем главным SCM и системами сборки под солнцем. Главная причина, которую я записал интеграции CC.NET с TFS, которым случается так, что в TFS2005 система сборки не имела-поля поддержкой CI. Однако версия TFS2008 очень улучшена, и команды продолжают очень, активно улучшают его для будущих выпусков TFS.
главная причина для переключения на Сборку TFS состояла бы в том так, чтобы это автоматически сообщило информацию о сборке в TFS, который помогает завершить изображение разработки программного обеспечения с точки зрения создания отчетов. Это также интегрируется приятно со стороной отслеживания объекта работы TFS и в IDE (и в Visual Studio и в Eclipse).
Однако если у Вас есть большие инвестиции в сценарии Nant, которые действительно больше, чем просто компилируют и тестируют Ваш код или у Вас уже есть варившее домом решение для создания отчетов, которое Вы могли бы хотеть продолжить работать с тем, что Вы имеете.
Действительное значение в Сборке Основы Команды - то, что она связывает changesets и объекты работы со сборками.
Это включает несколько полезных сценариев:
- можно посмотреть на объект работы и узнать то, что создает его, включен в
- , можно посмотреть на сборку и видеть, какой код изменяется (и объекты работы), он включает
Тогда, конечно, существуют отчеты, созданные сверх этой информации. Но даже эти ссылки собой полезны для рядовых типов.
Взглянули на www.tfsbuild.com для "рецептов" на различных Конфигурациях сборки Команды.
Мы использовали CruiseControl.net с июня '07, и он работал отлично для нас. Большая часть, это интегрируется к SVN легко, который является намного превосходящим поставщиком управления исходным кодом.
, Таким образом, наша установка:
- Круиз-контроль. Сеть
- SVN
- Trac - для отчетов об ошибках и управления проектами (интегрируется отлично с SVN)
- nunit - для поблочного тестирования
у Нас были некоторое основное параллельное движение разработки и ветвление, и слияние опыта было захватывающим. Если бы у Вас есть выбор, я пошел бы с установкой выше!
SVN - неплохой инструмент, далеко не правдоподобный, SVN против TFS похож на пикап Ford против Mercedes 500, он выполняет свою работу, но он не симпатичен и не удобен, слияние имеет желать лучшего. Я предпочитаю инструмент слияния TFS, так как кажется, что разветвленный разработчик работает с вами, насколько он умен. Наш внутренний SVN, похоже, сильно испортился, поэтому мы отказались от него и пошли в TFS, не оглядываясь назад. Стеллажи с наборами изменений отлично подходят для гибкой мастерской разработки, в которой в настоящее время более 270 инженеров TFS без проблем или проблем, SVN просто не был способен справиться с такой нагрузкой без проблем.
Я предпочитаю CC.NET просто из-за инструментов, которые мы разработали для расширения функциональности отчетности и администрирования.