Автоматизована платформа побудови портфеля .NET - найкращий вибір? [зачинено]

Я займаюся підтримкою досить великого асортименту додатків .NET. Також у портфоліо є застарілі програми, побудовані поверх інших платформ - рідного C ++, ECLIPS Forms тощо.

Зараз у мене є складна структура побудови поверх NAnt, яка керує складами для всіх цих додатків. Рамка збирання використовує NAnt для виконання кількох різних речей:

• Витягніть код із Subversion, а також створіть теги в Subversion
• Створіть код, використовуючи MSBuild для .NET або інші компілятори для інших платформ
• Загляньте у файли AssemblyInfo, щоб збільшити номери версій
• Виконайте видалення певних файлів, які не повинні включатись у збірки / випуски
• Випускає код до папок розгортання
• Кодування Zip-файлів для резервного копіювання
• Розгорнути служби Windows; запустити і зупинити їх
• І т.д.

Більшість із цих речей можна виконати лише NAnt самостійно, але ми створили пару завдань для розширення, щоб NAnt робив якісь конкретні для нашого середовища умови. Крім того, більшість цих процесів, описаних вище, генерізовані та повторно використовуються у багатьох наших різних сценаріях побудови додатків, щоб ми не повторювали логіку. Отже, це не простий код NAnt, а не прості сценарії побудови. Є десятки файлів NAnt, які збираються для виконання збірки.

Останнім часом я був незадоволений NAnt з кількох причин: (1) його синтаксис просто жахливий - мови програмування поверх XML насправді жахливо підтримувати, (2) проект, здається, загинув на лозі; останнім часом не було тонни оновлень, і, схоже, ніхто не справді за кермом. Спроба налагодити роботу з .NET 4 викликає деякі больові точки через відсутність активності.

Отже, з урахуванням всього цього, ось моє запитання. З огляду на деякі речі, які я хочу виконати на основі цього списку вище, і враховуючи, що я передусім в магазині .NET, але мені також потрібно будувати проекти, які не є .NET, чи є альтернатива NAnt, яку я повинен розглянути перехід на?

Мої радари включають Powershell (з psake або без ), MSBuild сам по собі та граблі . У всіх цих плюсів і мінусів. Наприклад, чи достатньо потужний MSBuild? Я пам’ятаю, що використовував його багато років тому, і, здавалося, він не мав такої сили, як NAnt. Чи справді я хочу, щоб моя команда вчила Рубі просто робити будівель за допомогою граблів? Чи psake дійсно достатньо зрілий для проекту, щоб закріпити мій портфель? Чи є Powershell "занадто близьким до металу", і мені в кінцевому підсумку доведеться написати власну бібліотеку побудови, схожу на psake, щоб використовувати її самостійно?

Чи є інші інструменти, які я повинен розглянути? Якщо ви брали участь у підтримці .NET портфоліо значної складності, який інструмент побудови ви б шукали? Чим зараз користується ваша команда?

Якщо ви вже використовуєте TeamCity, ви повинні мати можливість використовувати його наявні функції для більшості того, що вам потрібно. Він в основному підтримує створення файлів .sln Visual Studio, і якщо вам потрібні додаткові матеріали для всіх ваших проектів, ви можете змінити .targets файли .NET Framework на ваших машинах побудови, тому вам не доведеться змінювати окремі файли csproj.

Це автоматично перевіряє з Subversion, поштових артефактів, дозволить вам контролювати, які файли вважаються артефактами, що розгортаються. Нова версія (6.0) також дозволяє кілька кроків збирання, тому є можливість для xcopy розгортання артефактів на загальну долю.

Ви також можете писати власні програми / завдання, які можна виконувати як частину збірки (за допомогою бігунка командного рядка), і робити все, що завгодно (наприклад, запуск / зупинка процесів Windows).

Ми підходимо до речей як до трьох різних видів діяльності: збирання, розміщення та встановлення. Ми використовуємо TFS для сервера збірки з декількома додатками до Powershell. Потім ми використовуємо Powershell, щоб виконати всі деталі розгортання та встановлення, які є досить складними та на різних серверах, як локальних, так і хмарних. Я був дуже задоволений навчанням Powershell через MSBuild чи якийсь інший інструмент. Я також мав хороший досвід роботи з Visual Build в минулому.

Погляньте на Хадсон та MSBuild як на пару. Потужність забезпечується потужними можливостями MSBuild та плагінами Хадсона .

Наприклад, ви можете використовувати Hudson і запускати сценарії NAnt, поки не перейдете до MSBuild, і тоді він також може запустити ваші сценарії MSBuild.

Конкретно вирішення питань:

• Підрив і мітка
• MSBuild
• Зазирнути до АсамблеїІнфо просили вас , але рішення може бути не на ваш смак
• MSBuild може легко видаляти файли
• "Код звільнення до папок розгортання" - ви можете змусити систему складання пропустити цей крок і розгорнути його автоматично, використовуючи ряд методів. Або ви можете FTP, якщо хочете.
• MSBuild може поштовувати
• Служби Windows, знову MSBuild - ваш друг тут.

Я використовую Automated Build Studio . Я хочу позбутися цього.

Єдина причина, чому я не переходжу на 100% MS Build або Team Foundation Build - це вартість, яку вона потребує, щоб відновити сценарії, які ідеально працюють сьогодні. Сценарії не сильно змінюються ...

Однак для наступного продукту це буде Team Foundation Build без вагань з основних наступних причин (їх набагато більше):

• Його легко розгортати (остання версія: 2010)
• Він повністю інтегрований з Visual Studio і Team Foundation Server
• Це стає таким стандартом, як MS Build
• Це безкоштовно з Bizspark (для стартапів)

Оскільки ви також перебуваєте в .NET, я рекомендую вам використовувати TFB.

Якщо ви не можете подати заявку на Bizspark або не можете дозволити придбати ліцензію, ви можете перейти до CruiseControl.NET + MS Build та декілька скриптів підтримки. У великій комунальній компанії, в якій я працював, ми використовували CruiseControl.NET для створення, тестування, розгортання та звітування про всі наші проекти. Він включав автоматичне розгортання веб-служб.

FinalBuilder може виконати всі ваші запитувані елементи, приємний графічний інтерфейс та додаток для сервера для будівельників.

Зараз я роблю те, що ви робите (тобто від збирання до упаковки до розгортання), використовуючи MSBuild (> 3000 рядків сценаріїв). CI використовує CruiseControl.Net і, сподіваюся, я зможу перейти до TeamBuild в майбутньому. MSBuild є громіздким (програмування в XML), але він є досить потужним, спеціально для пакетної обробки та відстеження залежностей. Він активно підтримується і вдосконалюється в нових версіях .Net і є основою системи побудови в Visual Studio і TFS. Також файли проектів візуальної студії - це фактично проекти MSBuild, і я можу підключитися до різних точок розширення. Пакет розширень MSBuildмає багато додаткових завдань, і створити власні завдання програмно неважливо. Я пропоную серйозно подумати про MSBuild. Останнім часом я також вивчаю програму «powerhell» і легко знаходжу певні завдання, особливо на етапі розгортання, наприклад, встановлення та налаштування сертифікатів, IIS тощо.

Редагуйте проект MSBuild у VisualStudio, оскільки він розуміє синтаксис та дає вам інтеліссенс. Ось деякі інші хороші утиліти, які допоможуть у MSBuild.
MSBuild Launch Pad - для розширень оболонок
MSBuild SideKicks - Графічне редагування, виконання та налагодження сценаріїв.

Можливо, ви запитуєте занадто багато свого сценарію збирання і недостатньо вашого сервера збирання - з командним містом ви можете легко мати прості сценарії, які виконують кожну з ваших куль, будь-якою мовою чи стеком, що має сенс і використовувати завдання TeamCity для створення завдань ланцюжок речей разом, як це доречно.

Я настійно рекомендую TeamCity, його легко налаштувати та налаштувати. MSBuild є кращим над NAnt з простої причини, що всі файли проекту / рішення у vs2008 / 2010 є файлами MSBuild технічно, але ви можете налаштувати TeamCity за допомогою MSBuild або NAnt.

Звичайно, TeamCity обійдеться вам. Я особисто дав вибір, вважаю за краще граблі, просто тому, що тертя з інструментами Ruby порівняно з іншими, хоча psake також є хорошим кандидатом.

Ви розглядали Гудсона ? Це може бути непростим, оскільки для запуску потрібен сервер додатків Java, але я думаю, що це може дозволити вам використовувати ваш поточний сценарій NAnt та будувати поверх цього за допомогою інших інструментів.