Для начала, это не амбициозная цель, это обычное явление с хорошо поддерживаемыми инструментами. Так что вы на правильном пути, и вам хорошо, что вы четко определили свои приоритеты.
Scripting
Во-первых, не надо, если вы можете помочь, используйте файлы летучих мышей. Язык сценариев для летучих мышей ужасен. В нем отсутствует множество языковых конструкций, и сложно вообще что-либо усложнить. Эксперты могут многое сделать с помощью bat, но мой опыт работы со скриптами bat в системах сборки заключается в том, что они универсально не поддерживаются.
Вы захотите написать ряд сценариев уровня ОС, чтобы собрать все это вместе, но вам нужен солидный язык программирования для этого. Рекомендации включают в себя:
- Powershell
- Python
- Bash (то есть cygwin)
nAnt - прекрасный инструмент для управления вашими этапами сборки. Тот факт, что конфиг xml проверяется, разветвляется, объединяется, распространяется со всеми остальными, является огромным преимуществом.
Make и Scons также являются хорошими инструментами.
Несколько замечаний об этих скриптах. Они должны иметь чистый вывод и хорошие сообщения об ошибках. Я имею в виду отличные сообщения об ошибках. Вы не можете тратить слишком много времени на написание скриптов сборки, которые выдают хорошие сообщения об ошибках. Шутки в сторону. Кроме того, тщательно управляйте кодами ошибок своей ОС и убедитесь, что каждая команда сборки вызывает код ошибки в случае сбоя. Все серверы CI будут использовать это, чтобы пометить неудачную сборку. Если вы не смогли выполнить шаг 2, но не вызывали код ошибки до шага 10, отладку будет очень сложно.
Юнит-тесты
Да, они должны быть частью вашей сборки. В настоящее время существует основа модульного тестирования для каждого языка программирования под солнцем, и все они запускаются из командной строки. Так что выбирайте, какой из них выглядит лучше, и вы уже в пути.
Непрерывная интеграция
Как только вы доведите процесс сборки до точки, в которой вы можете сесть за командную оболочку и получить полную сборку, от Soup до Nuts (то есть от исходного кода до отправляемого), тогда пришло время взглянуть на то, что они называют инструмент непрерывной интеграции / сервер. Дженкинс хороший, как и Круиз-контроль и Buildbot. Я использовал их все, они в порядке, выберите один и пойдите с этим. Как только вы начинаете, их не так сложно выучить, и они управляют большим количеством уведомлений, о которых вы просили. Главное, что нужно иметь в виду, это то, что все они предназначены для выполнения и сообщения аргументов командной строки (более или менее)
Когда вы структурируете процесс сборки, помните, что он состоит из четырех основных шагов:
- Получение кода из репозитория
- Pre-сборка; обновление номеров версий и т. д.
- Компиляция / здание
- после сборки; упаковка; архивирование продуктов сборки, создание изображений .iso и т. п.
- Публикация: перемещение продуктов сборки в такое место, где их могут найти люди (в вашем случае веб-сервер)
Файлы конфигурации
Если у вас есть управление конфигурацией до одного файла, поклонитесь. Это принесет вам большие дивиденды. Вы говорите, что не хотите поддерживать три разных файла. Можете ли вы определить набор правил, которые преобразуют один базовый файл в три файла для публикации? Если это так, то вы можете написать скрипт, который преобразует вас на этапе упаковки. Помните, когда я сказал: «Не используйте летучие мыши? Это то, с чем ужасно сталкиваются файлы bat, и такие задачи всегда находят свое отражение в системах сборки.
Заключение
Наконец, помните, что смысл всего этого:
а. Убедитесь, что нет никаких ручных шагов между отправкой кода и доставкой продукта. Люди такие ужасные. Они делают ошибки, они не работают по выходным все время, все в таком духе.
б. Дайте разработчикам быстрый и полный конкретный отзыв о том, что то, что они представили, будет работать.
Удачи!