Преимущества использования фреймворка сборки

Непрерывная интеграция (CI) и/или непрерывная доставка (CD) является нормой в программных проектах в наши дни. Существует множество серверов сборки, таких как Azure DevOps, TeamCity, Jenkins и Cruise Control.Net. Большинство из этих серверов используют проприетарные языки для определения шагов сборки. Но является ли кодификация ваших шагов сборки в проприетарном языке хорошей идеей?

Некоторые приложения просты, с несколькими шагами сборки, другие более сложны с множеством шагов сборки. Когда вы определяете шаги сборки в проприетарном языке, чем сложнее шаги сборки (по сложности или по количеству), тем более привязанными к платформе сборки вы становитесь. Это становится проблемой, когда вы хотите переключиться на другую платформу сборки. Например, вы используете TeamCity от JetBrains в своем локальном дата-центре, но компания решает перейти в облако. Теперь вы должны переписать свои скрипты сборки, потому что TeamCity не поддерживается в новой облачной платформе.

Вместо написания скриптов сборки на проприетарном языке, рассмотрите возможность использования фреймворка сборки.

Фреймворки сборки имеют два преимущества:

1. Обеспечение переносимости между платформами сборки.
2. Позволяют версионировать ваши скрипты сборки вместе с кодом приложения.

Переносимость между платформами дает вам гибкость перехода между платформами сборки с минимальными усилиями. На новой платформе сборки всегда будет некоторая конфигурация, но фреймворки сборки сохраняют усилия на низком уровне.

По моему мнению, самым большим преимуществом фреймворков сборки является возможность зафиксировать и версионировать ваши скрипты сборки вместе с кодом приложения. Возможность извлечь код из любой точки в истории вашей системы контроля версий и собрать этот код стоит любых недостатков фреймворка сборки.

В пространстве .Net есть два популярных фреймворка: Cake и Nuke Build. Оба фреймворка существуют уже некоторое время. Я использовал Nuke Build и мне нравится. Я слышал отличные отзывы о Cake и призываю вас изучить его, прежде чем решить, какой фреймворк лучше всего подходит для вашего проекта.

Поэтому в следующий раз, когда вы будете создавать новое определение сборки для своего приложения, рассмотрите возможность использования фреймворка сборки и его фиксации в системе контроля версий вместе с вашим приложением.