“Как-нибудь” продукт и шелл-скрипт соберет. А вот если надо “чтобы само” да еще и быстро — то тут начинается веселье:

  1. Надо скачать зависимости, разрешить конфликты (а это может быть большой граф), подключить их правильно (банально — фреймворк для тестов не должен протекать в продакшн-код) и т.п.
  2. Сборка должна быть быстрой, поэтому не надо каждый раз все собирать с нуля, а по максимуму переиспользовать предыдущие результаты — это инкрементальная компиляция (возможно со всякой черной магией, чтобы понять, были ли изменения бинарно совместимыми или нет) и/или корректный вызов компилятора, который, знаете ли, тоже тот еще комбайн. Это не очень тривиальная задача. А еще нужен кэш сборки (возможно удаленный).
  3. Как следствие, процесс сборки (а так же его части, та же компиляция) делится на мелкие кусочки (чем мельче куски, тем больше потенциально закэшируется), которые зависят друг от друга — получается граф выполнения задач. Причем там могут быть циклы (у какого-нибудь линковщика, например) — со всеми вытекающими приколами.
  4. Чтобы было еще быстрее, можно же параллельно выполнять независимые задачи.
  5. Кэшировать можно не только результаты сборки, но инструкции для нее. И тоже гранулярно.
  6. На мелкие кусочки можно делить не только процесс сборки, но и сами исходники — зачем вам каждый раз перекомпилировать форк библиотеки со своим фиксом, когда можно его изолировать от остального кода?
  7. Если вы разработчик библиотеки, то надо еще тестировать под миллион окружений, и не всем охота это делать в CI.
  8. А еще код на качество стоило бы как-нибудь проверить, желательно сразу при сборке.
  9. Если у вас завелся пользователь Windows, то уже просто shell-скрипт не напишешь, нужно что-то кроссплатформенное для всякой фигни типа копирования файлов или выполнения HTTP-запроса.
  10. Получается, что теперь нужна еще возможно писать какую-то кастомную логику и/или давать возможность расширять функциональность плагинами.
  11. Даже если стараться, то теперь у вас есть DSL, который с очень большой вероятностью Тьюринг-полный.
  12. Так что желательно, чтобы это все нормально интегрировалось с IDE.
  13. Все перечисленное выше еще должно быть плюс-минус воспроизводимым, чтобы везде был одинаковый результат.
  14. И животноводство! Какой только фигни не хотят “чтобы заодно” делал сборщик.